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