开发中尽量避免犯错的方法总结

一、前言

开发过程中，由于对业务不熟，对技术掌握不深，粗心等等原因，可能会出现线上故障。

轻则出现小bug，重则罚款，绩效低，甚至走人。

如何养成良好的编程习惯，如果避免出现这些问题非常重要。

二、要考虑的地方

下面目录大致分类，可能个别不够合理，仅供参考。

2.0 需求！需求！需求

需求要彻底搞明白，搞不明白多和产品确认。

想好可行的技术方案后再动手写代码，避免低效，避免返工。

多做任务分解，拆分后可以评估每一个任务的耗时，并尽量预留一定机动的时间。

2.1 仔细！仔细！仔细

1. 写代码的时候要仔细，多和master代码比较，有时间自己多review一下自己的代码。
2. merge代码之后要检查merge的对不对，分支名是不是对，代码是不是对
3. 进行一些线上操作，尤其是修改数据的操作，要尽可能的慎重。
4. 提db修改尽可能的本地先测试好，多检查几遍。
5. 代码冲突解决要慎之又慎。
6. 操作之前看清是测试环境还是预发环境还是线上环境。
7. 为了自测硬编码到代码中的代码片段是否有线上不运行的机制？

等等

2.2 多看最佳实践

养成好的编程习惯和风格非常重要，好的编程习惯不仅更有逻辑，而且更易于修改，易于拓展，减少甚至预防不必要的BUG等。

推荐下面基本自己看过的并且认为非常有价值的几本书：

《阿里巴巴Java编程规范》、《重构-改善既有代码的设计》、《编写可读代码的艺术》、《代码整洁之道》、

《修改软件的艺术》、《修改代码的艺术》、《遗留系统重建实战》、《Effective Java》

可以参考我的这篇文章：https://blog.csdn.net/w605283073/article/details/89893440

2.3 Code Review

如果有条件，团队成员之间尽量相互cr彼此的代码，一方面熟悉团队的业务，两外一方面避免对方没考虑到的一些潜在的风险。

高质量的CR可能避免风险，提高团队的代码质量。

另外自己没事多和master对比一下代码。

强烈推荐一本电子书：

https://leanpub.com/whattolookforinacodereview

多读读upsource的博客

https://blog.jetbrains.com/upsource/

2.4 善用IDE

1. IDEA安装阿里巴巴的代码规范插件或者其他代码检查插件。这样写代码的时候，比如某个集合存入数据但是没有使用，某个变量没有用到等都会给出提示。
2. IDEA自带查看类继承体系，分析类之间关系的图形工具。
3. 安装FindBugs等静态代码检查插件。

等等

IDEA好用的插件，可以参考我的这篇文章：https://blog.csdn.net/w605283073/article/details/89163627

2.5 考虑各种风险

1. 数据量如果大了会怎样？性能会不会有问题？
2. 网络不稳定会怎样？重试？如果一直失败怎么办？
3. 接口调用失败会怎样？要不要重试？
4. 消息会不会重复消费？有没有做好幂等？
5. 会不会缓存穿透？如果会怎么办？
6. 代码修改影响面多大？
7. 高并发场景接口该考虑哪些问题？准备哪些方案？限流、熔断、降级

等等

2.6 数据方面的考虑

1. 数据库操作要不要开启事务？
2. 大表DDL会不会导致主从延迟？
3. 强实时性要求应该强制查主表。
4. 线上操作update和delete之前先开启事务，并且先select查出数据看看对不对。
5. 数据安全问题，是否需要加密？
6. 数据量大性能会不会有问题？

2.7 修改代码时的考虑

1. 技术角度和经验总结
2. 修改别人的代码之前一定要充分理解原有代码的逻辑
3. 删除代码要慎重！！
4. 能不修改api就不修改api
5. 尽量写注释和文档
6. 先评估好影响面，然后再确保改对
7. 移动代码未知不要复制忘了删除

2.8 提高意识

1. 重要操作两个人确认
2. 没有监控的服务不能上线
3. 先追求质量再追求速度
4. 多看故障的原因

2.9 积累技巧

1. 部分功能可以设置开关
2. 针对用户的接口要异常处理
3. 多验证，多自测
4. 新增方法时，参数多尽量用类封装，减少参数尽量新增方法等
5. 缓存是否需要设置有效期？多少合理？
6. 任务加上开关，出现异常立马关闭
7. 下线接口之前，原接口打日志多观察一段时间
8. 超时重试要设置时间间隔
9. 新任务上线要多观察标新
10. debug技巧，比如断点、修改变量值，切换调用栈，甚至回退等。

2.10 加强监控

• 线程池状态监控
  • 线程数量
  • 队列size
  • 定时任务
• 重视error日志

2.11 编码时

1. db交互时不要用基本类型，避免默认值导致诡异问题
2. 查询不到信息是否返回null??
3. 参数严格校验
4. 重要操作考虑幂等性问题
5. 重要功能强制要确认交互
6. 日志相关： 第三方调用要加日志，切面切到异常不要吞掉且打日志用error级别，线程池满了写日志发警告等
7. 代码重构
   • 逻辑变更
     • 结对review
       • 简明描述修改功能
       • 如果太复杂用新方法代替
   • 逻辑不变
     • 单元测试保证，要覆盖所有路径
8. 参数
   • 入参变更
     • 新增入参
       • 兼容性 null?
       • 合法性？
       • 日志打印新参数
     • 减少入参
       • 新增方法
     • 入参类型变更
       • 新增方法

2.12 测试！测试！测试！

• 单元测试:   覆盖率很重要、特殊逻辑要覆盖、正常和异常参数和case都要测试
• 功能测试： 正向校验、负向校验、新功能回归原需求、关联的功能测试、考虑没有覆盖的场景
• 其他：不符合预期的表现要彻查原因

   强烈推荐用mokito进行单元测试，mock接口去测逻辑对不对，并且注重代码覆盖率，效果非常好！

  不要只依赖功能测试，因为功能测试是黑盒测试，未必覆盖到所有情况。

如果觉得本文对你有帮助，欢迎点赞，欢迎关注我，如果有补充欢迎评论交流，我将努力创作更多更好的文章。