code review不可见代码（常见CodeReview代码走查）
code review不可见代码（常见CodeReview代码走查）既然发现了问题，我们又该如何把握好节奏来重构我们的代码呢？下面推荐几比较好的重构时机：添加功能时重构、修补错误时重构 、复审代码时重构、时间空余时重构 。编码风格比较个性，读起来晦涩难懂，对融入团队是个障碍。编码质量问题：何时实施代码重构：
软件环境：Spring MVC MyBatis
主要体现在两个方面，一个是编码习惯问题，另一个是编码质量的问题。编码习惯主要有日志编写、代码注释以及编码风格的问题，而编码质量则与很多方面相关，比如轮子的使用、数据交互、逻辑精简程度等等。下面展开来说
编码习惯问题：
- 方法体偏长，不易管理维护，可逐步抽取成小方法来减少代码长度。
- 缺少注释或注释与实现不符，这对后期维护人员是个伤害。
- 硬编码，随手写的代码或测试时的死数据或常见的公共常量未维护，一旦发生变更，维护的代码量较大
- 日志缺失或缺少或输出意义不大，一旦发生问题，线上排查难度较大
编码风格比较个性，读起来晦涩难懂，对融入团队是个障碍。
编码质量问题：
- 重复造轮子的问题，常见工具类使用不到位，经常自己写方法实现。比如Apache commons，Google Guava等。另一个是共用的业务代码，未能提交协商好，造成多个版本实现，后期维护成本上升。
- 公共数据使用不充分，存在重复调用的情况，而不是一次调用，多次使用，这种情况在与第三方交互的场景中对效率损伤更大。
- 参数过多时，可转化为对象传参，否则一个方法的参数要加大代码的可维护性。
- 采用MBG产生的单表的关联查询，但在业务中适合多表关联查的情况下，可多表联查，提高效率。【涉及NDB Cluster存储引擎，跨库Join问题】
- 代码命名，未能见名知意，这也是一个老生常谈的问题，起个优雅的名字是多么的重要。
- 代码逻辑不顺畅，存在走弯路的倾向，能精简的代码要反复的重构以达到最优目标。
- 多余代码，并无实际意义。如有些情况下，先查询，再更新，典型的hibernate的思路，完全可以采用以主键选择更新的方法。
- 需要异步处理的情况就不要同步处理，以免影响主业务流程效率。比如流程过程中产生的短信、推送通知等，以通知为主要目的的除外。
- 代码重复，针对功能类似的方法，可添加一个参数加以区分复用。
- 校验逻辑要提前，防止做无用功。
- 前后逻辑重复，Controller中作必输校验，Service无须再次校验。
- 虽标记了FIXME/TODO，却未实际修复，重构不能是一句空话。
何时实施代码重构：
既然发现了问题，我们又该如何把握好节奏来重构我们的代码呢？下面推荐几比较好的重构时机：添加功能时重构、修补错误时重构 、复审代码时重构、时间空余时重构 。
回头审视过去的代码，就像审视我们的过去的编码思路、技巧，要想有所提升成长，就需要反复来重构，以达到一个最优结果。如果只是写过，事后不做复盘重构，对个人成长没有促进作用。
