日常开发中开发思想、编程规范和小技巧

一、空异常

1.1 不可信原则

作为开发者，你都可以把自己作为方法调用者的第三方，不需要去关注方法的实现，只需要关注调用方法我应该得到什么结果；然而作为调用者第三方，你都需要认为实现者的方法都是不可信状态，只需要秉承不可信原则，基本上你就跟空异常没有缘分了.

1.2 ?. （null条件运算符）

先来看一下以下代码：

  [HttpGet]
   public async Task<DataResponse<bool>> GetTest()
   {
        var list = GetList();//获取List 列表
        if (list?.Count <= 0)
        {
            return DataResponse<bool>.AsError("没有获取到数据");
        }
        //TODO 更新操作
        return DataResponse<bool>.AsSuccess(true);
   }

 

上面代码很多人可能会这么写，实际上是存在问题的list?.Count <=0 实际上在list 为空的时候就成了null<=0 判断了，则也是false，不符合预期结果，正确的代码如下：

[HttpGet]
   public async Task<DataResponse<bool>> GetTest()
   {
        var list = GetList();//获取List 列表
        if ((list?.Count??0) <= 0)
        {
            return DataResponse<bool>.AsError("没有获取到数据");
        }
        //TODO 更新操作
        return DataResponse<bool>.AsSuccess(true);
   }

 

这里就引用了?? 运算符（空合并运算符）

1.3 ?? （空合并运算符）

MSDN上面的解释：?? 运算符称为 null 合并运算符，用于定义可以为 null 值的类型和引用类型的默认值。如果左操作数不为 null，则此返回左操作数；否则当左操作数为 null，返回右操作数。

1.4 如何远离空异常？

秉承原则：不可信原则，什么是不可信原则呢？你调用方法都任务改方法是不可信的，包括自己写的方法；这在敏捷快速开发中更明显，特别是调用团队中别人开发的微服务api ，你不需要关注方法的实现，只需要关注方法的结果即可，但是也不能太过于相信它；所有的返回结果你都需要判断是否是null 的结果数据，多结合?. 和?? 运算符进行合理的逻辑处理，可以让你的项目从此远离空异常。

二、If else 解套

2.1 取反原则

对于上面的if else 嵌套业务大家是不是经常遇到，看到这种代码会非常的头疼，难于维护，影响开发效率，同时也容易出现bug。
有经验的开发者必定会对上面这段代码进行优化，我的经验是取反原则。
什么是取反原则呢？把不符合的条件先 return 下去，到最后留下符合条件的逻辑，这就是取反原则，一眼看下来就只有一层嵌套，不会存在多层嵌套。
我们来看下我遇到的实际场景代码，源代码大体如下：

if (condition)
{
    if (condition1)
    {
        if(condition2)
        {
            if (condition3)
            {
                if (condition4)
                {
                    // do something
                }
                else
                {
                    // do something
                }
            }
            else
            {
                // do something
            }
        }
        else
        {
            // do something
        }
    }
    else
    {
        // do something
    }
}
else
{
    // do something
}

 

取反原则优化后的代码如下：

 if (!condition)
  {
     // do someting
      return;
  }
  if (!condition1)
  {
     // do someting
      return;
  }
  if (!condition2)
  {
     // do someting
      return;
  }
  if(!condition3)
  {
     // do someting
      return;
  }
  if(!condition4)
  {
     // do someting
      return;
  }
  // do someting

 

三、必要的设计模式
开发过程中不要一个链路写到底，需要把某块业务先想好，定位明确，该业务是应该属于哪一块，哪一类业务，后续可能会出现哪些方面的业务变动，适当的引入设计模式，那么多的设计模式，总有一个适合你当时开发的场景；
设计模式的选取需要对该模块的作用及定义清晰，多思考，多归类，自然而然心中就有了合适的设计模式的考量。比如：把可能重复使用的方法，提取出来，减少冗余代码同时也方便维护，传不同参数应用到不同场景下

四、必要的单元测试
做到每个方法单元测试，最好是全路径覆盖到每一条分支的单元测试，先从小的方法单元测试，底层的方法单元测试通过后，再通过postman或者其他工具来进行对外API接口层面的测试，做到全路径覆盖的测试，往往开发人员有一个思维就是测试正常的业务流程，异常流程往往一概不考虑测试；然而出问题的都是那些异常的流程，单元测试需要遵守的原则如下：

• 尽可能的全路径覆盖测试
• 抛弃自己写的代码思维，当一个小白进行单元测试
• 关注异常路径的单元测试
• 摒弃依赖思想，不要依赖联调测试时间来进行测试，往往你开发只管开发，不管正确率，到后续测试联调时间那就的疯狂加班加点去赶进度了，还不能保证最佳的产品质量