常见代码问题

• 空值

  防御式编程，判空处理，有胜于无

• 未捕获潜在的异常

  API返回做判断；切忌默默吞掉异常；防御式编程

• 低性能

  批量调用接口或访问DB;处理超时；降维多重循环；复用大对象

• 影响范围过大

  谨慎修改公共函数、基础函数、基类等；充分测试；评估影响范围

• 单测间题

  重要业务逻辑必有单测；单测全部通过；代码BUG或变更单测覆盖；增加异常单测

• 与原有业务逐辑不兼容

  充分理解已有逻辑及设计；

• 缺乏必要日志

  重要而关键的实例状态、代码路径及API调用，INFO日志；异常捕获并Error日志

• 错误码不符合规范

  错误码集中在一个类管理，切忌分散在代码中；遵循团队规范

• 参数检测缺乏或不足

  参数值类型；参数业务类型；契约式编程；

• API参数传递错误

  参数类型具体化；避免相同类型参数相邻

• 引用错误

  有多个重名类时仔细核对类的全名；源加新类时先搜索重名类引用

• 细节错误

  • 数组越界、JSON解析出错、函数参数传递出错、API版本不对；

  • 使用网上拷贝的未经测试的代码、不成熟的算法、传值与传引用、相等性比较

• 多重条件

  拆分为有业务语义的单个条件的组合

• 文不符实

  查询接口中有更新/新增甚至删除操作，引发故障的定时炸弹

• 跨语言或跨系统交互

  空值、JSON、数组的不同解析；接口与交互约定；联调确认

可维护性问题

• 硬编码

  “魔数”(枚举替代);写死的配置(配置项);临时加的逆辊和文案(抽离管理)

• 重复代码

  抽离通用的部分，定制差异；事实一致性；

• 通用逻辑与业务逻辑耦合

  通用处理流程抽离，业务逻辑以回调函数传入；复用而非混杂

• 直接在原方法里加逻辑

  新增一个函数，然后在原方法中调用并说明原因

• 多业务耦合

  先划分业务边界，定义好接口设计和服务依赖关系，再着手开发

• 代码层次不合理

  代码的放置位置不符合当前架构设计约定；Control调用Control;

• 不用多余的代码

  后续维护时会造成困惑；确认不用及时删除

• 使用全局变量

  破坏函数的复用性；排查和调试问题

• 缺乏必要的注释

  重要和关键点的代码；特殊处理缺乏说明

轻微问题

• 命名不贴切

  取贴切的名字

• 声明时未初始化

  赋予默认初始值

• 风格与整体有不一致

  调整为整体一致风格

• 类型转换错误

  转换前判断类型；避免类型转换报错

• 否定式风格

  使用肯定句式

• 容器遍历的结构变更

  使用迭代器遍历和变更

• 单行调用括号过多

  拆解为多行

• 修改方法签名

  扫描和修改所有调用者

• 打印日志太多

  仅保留必需日志

• 多级数据结构

  确保父级结构的数据存在

• 作用域过大

  仅在需要时定义和使用

复杂问题

• 并发

  • 多线程访问缺乏同步保护；死锁
  • 缺乏控制的手动线程或动态创建的线程池

• 缺乏事务控制

  识别原子操作集并添加事务

• 大数据量的SQL低效

  • 合适的素引、查询条件与顺序
  • 避免Join,子查询

• 安全问题

  • 输入；清除敏感私密信息；加密存储；
  • 角色、权限、操作、数据访问分级和控制

• 设计问题

  • 性能问题

  • 扩展性问题

  • 缺乏幂等处理

（完）