重复代码
描述：
相同/相似代码散落在项目各个地方。
痛点：
难以维护，一处修改，处处要同步修改，有时候还会有遗漏从而导致出问题。
解决方案：
提取公共代码，封装成公共方法
长函数
描述：
一个方法几百甚至上千行。
痛点：
阅读困难。必须看完几百行甚至上千行代码才能明白这个方法在干啥，效率很低，如果把这个方法中某些职责代码封装成方法，然后改成方法调用，就能大大减少方法的长度，阅读时看调用方法的名字或者注释就能明白要干嘛，而不用点进方法看具体逻辑，可以大大提高阅读效率，也便于理解。
解决方案：
抽取单一职责或功能的代码段，封装成方法。
过大的类
描述：
一个类做了太多事情，维护了太多功能，可读性变差。
痛点：
可读性变差；会使项目中的类依赖变得不合理。
解决方案：
按照单一职责原则拆分类，每个类的职责应该单一、清晰。
过长的参数列表
可读性差。
解决方案：将方法参数列表封装成类。
冗余类或重复类
描述：
是指有一些功能相似的类。
解决方案：
合并功能相似的类。
过度设计
尽量避免过度设计的代码。例如：只有一个if else，那就不需要班门弄斧使用多态。
无用代码
描述：
阅读代码时可能会碰到无用代码，会使人困惑，也潜在影响了阅读效率和代码可读性。
解决方案：
及时删除无用代码，否则越到后面越没人删、不敢删，会成为“僵尸代码”。
无用或不必要的注释
注释多是好事，但注释也会影响可读性，尽量减少无用或不必要的注释，多一点有效、重要的注释，可以把自己当做新人阅读这段代码，看看是否要加注释、注释要说什么。
不合理的命名
命名应该「见名知意」，降低理解成本，增加可读性。
魔法值泛滥
魔法值不好维护，要收敛到常量，容易维护。
混乱的代码层次调用
代码分层、职责要清晰。
