代码质量、重构、可测试性、解耦杂谈

如何发现代码质量问题？

从大处着眼的话，看这段代码是否可读、可扩展、可维护、灵活、简洁、可复用、可测试等等，落实到具体细节，可以从以下几个方面来审视代码。

目录设置是否合理、模块划分是否清晰、代码结构是否满足“高内聚、松耦合”？是否遵循经典的设计原则和设计思想（SOLID、DRY、KISS、YAGNI、LOD 等）？设计模式是否应用得当？是否有过度设计？代码是否容易扩展？如果要添加新功能，是否容易实现？代码是否可以复用？是否可以复用已有的项目代码或类库？是否有重复造轮子？代码是否容易测试？单元测试是否全面覆盖了各种正常和异常的情况？代码是否易读？是否符合编码规范（比如命名和注释是否恰当、代码风格是否一致等）？

以上是一些通用的关注点，可以作为常规检查项套用在任何代码的重构上。除此之外，我们还要关注代码实现是否满足业务本身特有的功能和非功能需求。这里罗列了一些比较有共性的问题，如下所示。这份列表可能还不够全面，剩下的需要你针对具体的业务、具体的代码去具体分析。

代码是否实现了预期的业务需求？逻辑是否正确？是否处理了各种异常情况？日志打印是否得当？是否方便 debug 排查问题？接口是否易用？是否支持幂等、事务等？代码是否存在并发问题？是否线程安全？性能是否有优化空间，比如，SQL、算法是否可以优化？是否有安全漏洞？比如输入输出校验是否全面？

如何才能写出高质量的代码？

要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。

重构的目的：为什么重构（why）？

对于项目来言，重构可以保持代码质量持续处于一个可控状态，不至于腐化到无可救药的地步。对于个人而言，重构非常锻炼一个人的代码能力，并且是一件非常有成就感的事情。它是我们学习的经典设计思想、原则、模式、编程规范等理论知识的练兵场。

重构的对象：重构什么（what）？

按照重构的规模，我们可以将重构大致分为大规模高层次的重构和小规模低层次的重构。大规模高层次重构包括对代码分层、模块化、解耦、梳理类之间的交互关系、抽象复用组件等等。这部分工作利用的更多的是比较抽象、比较顶层的设计思想、原则、模式。小规模低层次的重构包括规范命名、注释、修正函数参数过多、消除超大类、提取重复代码等编程细节问题，主要是针对类、函数级别的重构。小规模低层次的重构更多的是利用编码规范这一理论知识。

重构的时机：什么时候重构（when）？

我反复强调，我们一定要建立持续重构意识，把重构作为开发必不可少的部分融入到开发中，而不是等到代码出现很大问题的时候，再大刀阔斧地重构。

重构的方法：如何重构（how）？

大规模高层次的重构难度比较大，需要有组织、有计划地进行，分阶段地小步快跑，时刻保持代码处于一个可运行的状态。而小规模低层次的重构，因为影响范围小，改动耗时短，所以，只要你愿意并且有时间，随时随地都可以去做。

什么是代码的可测试性？

粗略地讲，所谓代码的可测试性，就是针对代码编写单元测试的难易程度。对于一段代码，如果很难为其编写单元测试，或者单元测试写起来很费劲，需要依靠单元测试框架很高级的特性，那往往就意味着代码设计得不够合理，代码的可测试性不好。

编写可测试性代码的最有效手段

依赖注入是编写可测试性代码的最有效手段。通过依赖注入，我们在编写单元测试代码的时候，可以通过 mock 的方法将不可控的依赖变得可控，这也是我们在编写单元测试的过程中最有技术挑战的地方。除了 mock 方式，我们还可以利用二次封装来解决某些代码行为不可控的情况。

“解耦”为何如此重要？

过于复杂的代码往往在可读性、可维护性上都不友好。解耦，保证代码松耦合、高内聚，是控制代码复杂度的有效手段。如果代码高内聚、松耦合，也就是意味着，代码结构清晰、分层、模块化合理、依赖关系简单、模块或类之间的耦合小，那代码整体的质量就不会差。

代码是否需要“解耦”？

间接的衡量标准有很多，比如：改动一个模块或类的代码受影响的模块或类是否有很多、改动一个模块或者类的代码依赖的模块或者类是否需要改动、代码的可测试性是否好等等。直接的衡量标准是把模块与模块之间及其类与类之间的依赖关系画出来，根据依赖关系图的复杂性来判断是否需要解耦重构。

如何给代码“解耦”？

给代码解耦的方法有：封装与抽象、中间层、模块化，以及一些其他的设计思想与原则，比如：单一职责原则、基于接口而非实现编程、依赖注入、多用组合少用继承、迪米特法则。当然，还有一些设计模式，比如观察者模式。