
3.2
CRUST
原则
|
61
只要你认为有必要,就可以采取这种方法 :如果能够从跨项目可重用的功
能中获益,就可以这样做,在此过程中还要添加测试和文档。请注意,过
度模块化带来的回报是递减的 ;越是把模块化做到极致,在文档和测试上
花费的时间就越多。如果你打算把开发的每一行代码都作为独立的有完备
文档和测试的包来部署,就会在与所开发的特性或所修复的
bug
没有直接
关系的任务上花费相当多的时间。还是那句话,要根据你自己的判断来决
定将代码模块化到什么程度。
如果一段代码不复杂而且相当简短时,通常不值得为其创建模块。最好把
这段代码放在模块的一个函数中以便调用,或者每次都将其内联。这样的
短代码片段往往会需要进行修改和扩展,在代码库的不同部分中其实现略
有不同。因为代码量非常小,所以几乎不值得花时间找出一种方法来总结
所有甚至只是大多数用例中的这种小代码段。否则,与一开始时只是内联
这段代码相比,我们很可能会遇到一些更复杂的问题。
当一段代码足够复杂,足以独立成模块时,并不意味着值得立即为其创建包。
外部模块通常需要做更多的维护,换来的好处是,外部模块可以跨代码库
重用,并提供更整洁的接口和周详的文档。考虑一下你需要花多少时间来
分离模块和撰写文档,以及这是否值得。如果模块要依赖其所属代码库中
的其他代码,那么分离模块就比较有挑战,因为该模块所依赖的部分也必
须被分离出来。通常,我们不需要为代码库的每个模块都撰写文档。然而,
如果模块是独立的包,则必须为其撰写文档,因为你不能指望其他潜在的
使用者在不知道该依赖包具体做什么或如何使用的情况下就能决定是否要 ...