新来的实习生竟然偷偷在代码里“下毒”...... 【51CTO.com原创稿件】写这个文

【51CTO.com原创稿件】写这个文章是因为前段时间确实因为公司的业务开发太忙太紧，所有开发都处在于加班赶项目，并且加入的新人较多造成了一系列代码不可控的质量问题。
文章插图
图片来自 Pexels
文章针对这段时间代码出现的各种各样的问题进行了一个概况和整理，主要集中在代码编码的问题，抽象化的问题，还有就是涉及到微服务中调用和编写接口的问题。
其实按道理来说，这些应该属于编程的基本功，貌似不太值得写一篇文章，不过倒是可以通过这些基本功的出发，去讨论一个代码编程系统构建的一个本质，所以还是比较值得去展开。
大概先铺垫下，会按照一个原则和建议来展开一个一个的进行讨论。
编码的问题
避免过多的 IF 嵌套
所谓的“箭头形”代码基本都是因为大量的 IF 嵌套导致，一方面形成一个深深的箭头形状，在阅读代码造成缩进夸张的语句块。
更要命的是过深的嵌套层次导致代码逻辑复杂度加深，当阅读到第 N 层嵌套时根本不清楚是什么逻辑才能进入，严重降低代码的可阅读性和可维护性。
文章插图
其实对应 IF-ELSE 过长的主要原因无非就是对当前状态进行检查并决定继续还是跳转。
①使用卫语句(Guard Clauses)提前返回，避免层层嵌套
先对 IF/ELSE 的逻辑结构进行一些分析，我们基本上有两种用法：
"优先考虑满足条件，进行处理流程" ，代码如下：
if(user.getId() == 10){//满足条件，执行}else{//不满足条件，退出} “优先考虑不满足条件，让其逻辑退出流程” ，代码如下：
if(user.getId() != 10){//不满足条件，退出}else{//满足条件，执行} 这是两个不同的逻辑结构，他们都可以写出同样的代码逻辑，但是在第一种中，如果代码量增大，嵌套增多，就很容易在条件中迷失了方向。
如果采用第二种方式把条件反过来写，尽早的能把退出型逻辑及早的退出，这样就可以把箭头型的代码解脱掉，如下图：
文章插图
②规划好判断条件和状态模型
代码如下图：
文章插图
如果是业务允许其实是可以将多个判断条件进行整合，这样可以避免箭头形代码的出现。
但是仅仅一段 IF 条件判断的语句又变得非常的臃肿一行都放不下，如果出现了非常复杂多状态判断和组合，可以使用“状态表” ，或者是状态机等设计模式来进行解耦。
③将 IF 中的业务细节进行抽象成函数
将 IF 中繁琐的业务细节抽成函数，一方面可以减少又长又臭的代码，更利于屏蔽细节，将不关流程的业务逻辑锁定在一个特定的区域。
也利于进行代码阅读，让阅读关注于业务的流程而不是业务实现的细节，要善于应用函数用于代码的封装和抽象。
文章插图
谨慎多层循环嵌套中的操作
有的时候，确实几层 for 循环的嵌套是业务实现的必须，但我们需要警惕的是经过几层循环的放大，最内层循环执行的数量是多层循环数量的乘积。
文章插图
例如，这段代码总共经历了 4 层的循环，如果循环是 10x10x10x10 ，那么最终的 DB 操作是要经历单独的开销 10000 次。
第一，这 10000 次开销如果是程序员在写代码已经明确知道的开销属于业务必须那倒无妨，只怕程序员在写代码的时候还无意识到这个点是会被随时放大。
第二，即使 10000 次开销是属于业务必须，那按照这个代码来看，还是存在可以优化的空间，可以在循环中将所有查询条件都进行拼凑，然后在进行一定程度的批量查询，可以较大程度降低 DB 的开销。
不要随意定义局部变量名
命名风格我们可以参考阿里的《Java开发手册》，这里主要指出来的是局部变量随意命名的现象比较严重，大家一般都会以为局部变量只是在本方法内使用，又不会对其他方法和其他人造成影响。
但殊不知局部变量名起得不好或随意也对开发者本身造成困扰甚至连自己到不知道的错误，以下是一个比较经典的随意起变量名的例子：