Java代码审查（三）：关于编程习惯的要求
这里是我个人的倡议，仅供参考。各项目应按照实际情况制定自己的操作规范，经常加强对新人的教育，以免把经文念得越来越歪。
新来者
- 主动了解项目有哪些开发规范。
- 如果实际操作与开发规范已经不符，要敢于提出质疑，纠正错误操作或调整过时规范。
- 仿写是快速学习的一种方法，但是，仿写时候要动脑子，不要完全照抄已有代码，更不要照搬垃圾代码。
- 除了完成任务，不要忘了界面美观、操作便利、性能高效、保证信息安全、代码规范清晰这类不会使自己涨工资但是能减少被诅咒次数的东西。
- 如果不能保质保量地完成任务，一定要尽早吱声。如果拖到最后也做不出来，或者做到最后挖的坑比正面贡献还多，后果好不了。
- 事后诸葛亮：不听取本文意见，最终结果可能是项目质量感人。
开发工作
准备工作
- 新功能和数据库表结构的设计都要通过评审。
- 搞清楚业务场景和业务逻辑再动手。
- 把数据量估计好，以免产生正式环境运行过慢、页面展示爆炸等特效。
书写新代码
- 避免直接copy-paste。就算抄也要自己写一遍，过一下脑子。
- 如果一段代码重复了两三遍甚至更多，那么应当改写成公共代码。
- 接上条，造新轮子之前，查一下有没有可以拿来用的现成的东西。
- 将Web（请求处理）、BO（业务逻辑）、DAO（数据持久）等层次与PO（持久对象）、VO（值对象）等领域区分好，例如不要在Web层或JSP页面写业务逻辑。
- 代码和页面风格都要规范统一。
修改既有代码
- 修改函数签名、函数实现、应用配置、接口签名等内容之前必须先检查引用情况。
- 修改公共方法和公共配置之前应仔细评估影响并加强测试。如果不清楚影响，那么要先咨询老员工再修改。
- 设计和修改公共组件（包括公共函数、标签、模板、Filter等），除了正确实现功能，还必须更加关注运行效率、资源占用、线程安全性等问题。
- 如果发现待修改的代码比较诡异，修改之前建议先问问老员工有没有什么历史原因或者坑。
- 即使是简单的修改也要进行测试，因为再有经验也有可能改出问题。
- 及时清理出于备份目的留下的注释，以免造成混淆。如果后续有可能恢复，那么应当用注释说清情况。
提交
- 提交代码之前完成功能自测。
- 提交之前对代码进行一下美化，例如自动缩进、移除无用import等（需要事先统一标准）。
- 提交之前必须检查待提交的Diff（差异）：
- 提交务必完整，不能出现编译错误，不能导致程序无法正常运行。
- 不能完整提交就不要提交。
- 不要有错别字、笔误和语病。
- 不要把本地调试代码（例如alert(val)、屏蔽校验规则、写死测试数据之类的）提交上去。
- 提交时书写提交说明，例如实现了什么功能或解决了什么问题。
- 注意提交频率，按活动一次性提交齐全，不要长期不提交，也不要改一个文件就提交一下。
代码细节
命名
- 除了循环ijk那种一望而知的情况，要用有意义的英文名，而且不要用拼音简写，更不要拼音英语混写。
- 保持命名一致，例如不要前面还在用“state”表示“状态”，后面就变成了用“status”表示状态。如果不知道如何一致，那么就看代码规范以及别人怎么写的。
- 如果确实需要借用名称或借用字段，要把情况写清楚，以免造成混淆。
SQL
- 书写SQL要实地执行一下。
- 要估计投入到生产环境之后会产生多少数据，以免效率过低甚至系统瘫痪。
- 查询和关联时要留意是否一定能查到数据。不确定的话要与熟悉业务的人或DBA交流。
- 书写复杂SQL要看执行计划，估算执行效率，必要时与DBA交流，以便在数据库层面进行优化调整。
- 如果顺便发现没有主键或索引，那么也要告诉DBA。
- 尽量以绑定变量形式书写SQL而非直接拼接，以提高语句解析效率。
- 对于改造升级类的系统，注意要兼容历史数据。
注释
- 在业务代码处简单地解释业务规则。
- 复杂逻辑、边界情况、HACK操作以及“装逼操作”要写注释说明。
- 需求变更、业务逻辑修改等情况务必在相关代码中写注释说明，而且要标出在什么时间、因什么原因而修改，以便事后追溯。
- 接上条，如果预计以后还会发生变动，建议各关联代码都用唯一且相同的代码进行标记（例如CHANGE20190101），这样以后再改代码的时候容易搜索。
- TODO的事情写上TODO四个字母并进行跟踪，已经完成以及不是TODO的事情不要写TODO。
其他
- 关于报错：给用户展示正常人类能看懂的文字，而且让用户和开发者都能知道大概是哪方面错误以及如何处理。
- 及时清理无效引用与变更。
- 及时维护文档。如果不能及时维护，建议强迫自己改完文档再编码。
本系列目录
- 代码审查问题
- 应用安全问题
- 关于编程习惯的要求
- 使用Phabricator进行人工代码审查
- 使用FindBugs和SonarQube等工具进行扫描
- ……