Java 工程师必读的避坑宝典

一、背景

但凡工作过的同学都会亲身经历过或者听过各种故障。
轻则受到批评，重则影响绩效，甚至被罚钱、开除。

这本书初看不难，但是开发中还会有很多同学违反其中的规范，导致出现一些BUG 和隐患，建议人手一本，反复阅读。

电子版下载地址： Java开发手册

2.2 多将开发分支和 master 分支比较

在开发过程中，多将当前分支和 master 分支进行对比。
以便能够：
（1）尽早发现误修改
（2）尽早发现 merge 错的代码
（3）自我代码审查

有时，我们多个功能一起开发，可能将项目 A 的改动放到了 项目 B 分支；有时，我们可能误删了某个文件、某行代码；有时，即使我们已经很小心翼翼，合并代码发生冲突时，很有可能合并错误。通过和 master 分支比较，很容易发现这些问题。

2.4 重视代码审查

插件能够检查出来的都是比较常见的问题，很多问题需要人工审查才能发现。

比如
（1）一些潜在的性能问题
（2）违反一些设计原则的问题，如违反高内聚，弱耦合原则；违反单一职责、违反开闭原则、违反迪米特法则、违反依赖倒置原则等。
（2）一些业务上未考虑全面的校验
（3）一些缺乏拓展性的设计

有些公司强制代码审查才可以合并到 master 分支，如果没有强制要求代码审查，建议主动和周围同事相互审查。

实际代码审查中我们的确也发现了很多问题，比如：
（1） for 循环中调用 RPC 接口 –> 使用批量接口提高性能
（2）敏感信息没有脱敏
（3）手动创建线程 –> 使用线程池
（4）没有关闭资源
（5）没有做好参数校验，可能存在安全性问题，可能存在潜在的空指针异常
（6）打印了很多非必要的日志，打印了大文本 -> 降低日志级别，精简日志内容等

关于代码审查，强烈推荐Jetbrains 公司出品的《What to Look for in a Code Review》 这本书。

其他参考文章：
《What to look for in a code review》
《Code Review Best Practices》

2.5 多看错误日志

有些功能由于在代码中加了一些降级逻辑、只有特殊情况下才会报错等原因，测试时看似符合预期，实际上会有一些报错。
有些功能偶发性报错，测试时可能很难注意到，还以为是网络问题。

我们在自测、前后端联调和提测阶段，都应该勤看错误日志，才能尽早发现问题，才能尽早修复问题。

比如一些重要的设计原则：
（1）高内聚、弱耦合
（2）降低复杂度（技术复杂度、业务复杂度等）
（3）设计模式的原则：单一职责原则、迪米特法则、里氏替换原则、接口隔离原则、开闭原则、依赖倒置原则
（4）面向失败编程 。如果某某接口调用超时怎么办否需要兜底否需要重试果某个参数不合法怎么办br> （5）为了更好地拓展，还可以做哪些优化br> （6）是否存在哪些安全性隐患br> （7）是否存在一些复杂度较高的代码br> （8）…

比如一些自己常见错误：
（1）使用线程池时，不要忘记传递 trace 上下文，导致出错时 traceId 丢失。
（2）调用批量接口时，一定要注意下游对参数集合的数量限制。
（3）…

虽然很多原则大多数人都知道，但是写代码时，还会出现很多违反上述原则的情况。
因此编码过程中或者编码后期我们可以对着检查清单来看自己的代码，进行优化，可以少趟不少坑。

2.7 多看依赖的服务源码

不仅要埋头前行，还要抬头看路。

如果开发工期并不是特别紧，强烈拉取下游服务的仓库代码，查看当前功能需要对接的服务的具体实现，做到心里有底。

掌握好常用中间件的源码和原理才不容易误用，掌握好才能在遇到报错时知道为什么，尽快解决问题。

部分图书推荐：
（1）Spring 推荐《从 0 开始深入学习 Spring》、《SpringBoot 源码解读与原理分析》
（2）Redis 推荐 《Redis 深度历险》
（3）ES 推荐看 《Elasticsearch 实战》
（4）Dubbo 推荐看 《深入理解 Apache Dubbo 与实践》
（5）HBase 推荐看 《HBase 不睡觉书》
（6）Kafka 推荐看 《深入理解Kafka核心设计与实践原理》
(7) …

相关参考：
《如何高效学习和阅读源码》
《如何读源码更有效–直播》

2.9 慎重选择不知名三方库

日常开发过程中难免会用到三方库，选择三方库是一定要慎重，尤其很多不知名的三方库可能隐藏很多 BUG。

建议选择知名开源项目的三方库。因为知名源项目用户比较多，很多问题都已经暴露和修复。知名开源项目单测非常充分，质量相对比较高。

很多常见问题在单测时就能够提前暴露。
有了单测，如果对某个方法进行了误修改，也能够尽早发现。

2.11 充分自测

我们自己要充分自测，避免前后端联调时出现很多问题，影响项目进度，避免前端、测试同学对自己能力产生质疑。

不仅要考虑正常场景，每个项目都要思考有哪些异常场景，才能尽量将问题暴露在自测阶段。

2.12 提前准备发布清单

我们应该花心思提前准备发布计划，而不是马上发布时匆匆准备，导致遗漏或者发布错乱。

有些项目很大，涉及的数据库、配置、消息队列等变更特别多。
我们可以养成一些好习惯，在编码阶段就准备一个发布清单草稿，将发布计划一定会涉及到的内容提前写到笔记中。

而不是等到发布的时候再去“回忆” 项目里哪些变动需要写到发布计划中。

这样准备发布计划就比较轻松。

2.13 符合三板斧

所谓三板斧，即 可灰度、可监控、可应急。

功能要可灰度，不断切流，降低问题的影响面。
要可监控，通过监控尽早发现问题，而不是对用户造成实际损失时等待用户反馈。
要可应急，出现问题时可以尽早应急。

这里提一个小技巧，很多同学会对开发的功能留一些动态配置（如 apollo ）的开关，当出现问题时快速切回老的逻辑。

2.14 复盘

并不是所有的项目问题都是技术问题，还有可能是规划问题、沟通问题等。
很多人做完项目并不会复盘，以前存在的问题以后还会存在，导致做了很多项目却没太大进步。

我们在做完每个大项目后都应该去复盘，避免下个项目还存在一样的问题。

我正在参加 CSDN 猿创征文：《弃文从工，从小白到蚂蚁工程师，我的 Java 成长之路》，讲述自弃理从文、弃文从工的经历，讲述自己的写作经验、求职经验和工作经验等。
欢迎阅读，也欢迎点赞、评论，为我打 Call ！！

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作91337 人正在系统学习中

来源：明明如月学长