
71
第 4 章
内部构造
到目前为止,我们已经从宏观角度讨论了模块化设计和
API
设计的关注点,
但还没有涉及深层的实现细节。与前面的章节不同,本章的主要内容是一
些建议和具体措施,可以利用它们来改善组件的实现质量。我们将会讨论
复杂性、降低复杂性的方法、状态的风险以及如何更好地利用数据结构。
4.1
内部复杂性
我们所写的每一段代码都是内部复杂性的源头,都有可能成为整个代码库
的一大痛点。也就是说,大多数代码与整个代码库比起来是相对无害的,
而试图证明我们的代码不具有复杂性,这种做法本身无疑会增加复杂性,
而且不会带来任何好处。问题是,如何在小问题发展成为严重威胁项目可
维护性的大问题之前识别它们?
有意识地跟踪一段时间内我们没有做过修改或者与之交互的代码,并确认
它们是否足够简单易懂,这种方法可以帮助我们决定是否应该对代码进行
重构。也许我们可以设置一个规则,即团队成员应该留意代码中复杂且不