编写可维护软件的不朽代码随想-9

保持小规模代码库

控制代码库增长，主动减少系统的代码体积。

代码库是存储在一个仓库中的所有源代码的集合，可以独立地进行编译和部署，并且由一个团队进行维护。

以大型代码库为目标的项目更容易失败

项目体积和项目风险关系紧密，一个大型项目会导致大型团队、复杂的设计以及长时间的项目周期，会出现更复杂的沟通和协作，很难看清软件设计的整体情况，而且会出现大量的需求变更，这些都增加了质量下降、项目延期以及失败的可能性。

大型代码库更加难以维护

大型系统会出现更密集的缺陷

如何使用本原则

当其他条件都一样的时候，功能较少的系统其体积也会较小。要想保持一个较小的代码库体积。首先需要对系统功能进行限制，然后再注意限制编写的代码量。

功能层面的方法：

控制需求蔓延：开发过程中需求不断增加是一个常见现象，一些“看上去很好”的功能，不仅没有对业务或者用户增加什么价值，反而增加了系统的复杂度。你需要在额外功能的价值与项目延期或者更高的维护成本之间进行选择，避免一些随意的需求不断添加到项目中。

功能标准化：将功能统一标准化，可以在程序的行为和交互方面保持一致，可以避免在多个地方实现基本相同、但略有区别的功能。也有利于重用已有代码。

技术层面的方法：

目标是用更少的代码实现相同的功能。

不要复制粘贴代码。重构已有代码，重构涉及到重新梳理代码、简化结构、删除代码冗余、提高代码重用性。

使用第三方库和框架。

拆分大型系统，前提是这个系统可以从功能性、技术性、生命周期等角度，被划分成多个独立的部分。 

 

常见反对意见：

对生产率的评估会阻碍减小代码库体积：以增加代码量来评估开发效率是一个错误的实践。因为它会鼓励复制粘贴代码这样错误的习惯，相反，代码引用会更好。代码的增加数量可以帮助经理监控进度和预测时间点，生产率应该按照增加的价值来评估，而不是增加的代码行数。

编程语言会阻碍减小代码库体积：很有可能使用某些语言的确很难做到较小的代码库，即使是使用相同的语言，总是可以尝试去让代码库变得比现在更小，每个代码库都能够从体积缩小中得到收获。

系统复杂度导致了代码复制：难以理解已有代码，进而畏惧触碰代码，这是开发人员选择复制粘贴代码的通常理由。最好的方法是找最相似的功能，如果原有功能可以被分为多个部分，你应该能得到一段可以被新功能独立引用的代码，避免产生重复代码。

 

SIG评估代码库体积

要想达到4星评级，代码库的重建成本不能超过20人年，如果C#是系统的唯一语言，转换过来就是不能超过175000行代码。

代码库的总体积是转化成人月后总共的代码行数。人月是对代码量评估的标准单位，一个平均能力的开发人员在一个月内编写的代码总量。