什么是最有效的技术，以防止代码库变得难以维护，因为它的增长？

Question

我是一名10年的软件工程师，我想知道其他人在阻止代码库随着时间的推移而退化方面有什么效果。例如，我注意到的一些问题是：

• 巨额技术债务
• 公司因人事变动而丧失知识
• 复杂的升级和产品版本之间的迁移策略
• 具有不同价值观的多站点团队
• 了解产品和零部件的大量知识需求
• 由于多年来积累的开发，很难理解设计
• 大而多样的代码路径
• 混合技术，例如: oracle/sql server
• 具有不同级别和不同代码责任范围的不同部门

我感兴趣的主要领域是了解一个技术领导可以在一个新项目中采用什么策略来最大限度地减少代码库随时间的退化？

Answer 1

有什么最有效的技术来阻止代码库在成长过程中变得难以维护？

服从德米特定律。它告诉你，不仅对象中的值应该被封装，而且对象应该被他们的朋友封装。

巨额技术债务

从修复任何使其更大的东西开始。杀死鳄鱼是很有趣的，但排水沼泽是更有效的。

公司因人事变动而丧失知识

指导。交叉训练。如果你只有一次对决，是时候让他们训练另一个人了。

复杂的升级和产品版本之间的迁移策略

让开发人员做他们要求用户做的事情。开发人员擅长于自动化他们所关心的事情。让他们关心它。

具有不同价值观的多站点团队

拥有不同的价值观不是问题。不理解这些不同的价值观可能是。如果需要的话，可以访问这些网站。

大量的知识需求，以了解产品和零部件，由于多年的累积开发，难以理解设计。

你的要求在哪里？如果你和大多数人一样，他们就在密码里。如果您有您所信任的需求文档，您可以围绕您真正需要的内容进行简化。

因为它在代码中，所以现在最好添加的是回归测试，这些测试可以证明应用程序仍然在做您需要它做的事情。在测试就绪之后，您现在可以自由地简化、解耦和更新设计。

大而多样的代码路径

我提到德米特了吗？

混合技术，例如: oracle/sql server

如果您的设计需要您关心谁构建了您的DB，这也就不足为奇了。将您的DB踢出您的域，并将其视为一个插件。只有几件事应该直接与DB对话。我提到德米特了吗？

具有不同级别和不同代码责任范围的不同部门

...is是件好事。做一件事，做好它。不要和每个人打交道。只和你的朋友说话。提供有用的摘要，这样你的朋友就不用和你的其他朋友说话了。我提到德米特了吗？

Answer 2

• 巨额技术债务

技术债务通常以小幅度增加。由于客户需求的变化、模块的增长、特性在不该添加的地方添加，代码中出现了许多小的调整。这是因为我们目前还不知道我们采取的这些小捷径会在一段时间后把整个代码库打压下来。

根据我的经验，招致技术债务几乎是不可避免的。最后期限会给项目带来压力。新的开发人员可能不知道如何将一段代码最好地放入代码库中。架构师可能看不出他们原来的结构为什么不适合支持新特性。

我们所能做的，只有在管理层的正确态度下才能做到，那就是使技术债务能够应付。每隔一段时间重构一次代码，以保持所有内容的完整。我们必须还清债务。为了成功地重构，我们应该避免破坏事物，所以这只有在一个良好的单元测试环境下才有可能。这就是为什么我从一开始就主张做TDD。在必要的时候，它给了你重构的安全。

• 公司因人事变动而丧失知识

知识流失的唯一解药是保持知识的活力。文档，即使是最好的意图，也已经过时了。通常，专家们不知道某人需要知道什么，而这个问题还没有深入到他们的话题中。

您需要确保您的开发人员不会孤立地工作，他们需要作为一个团队工作，在这个团队中，如果主题的主开发发生意外，每个角色都可能被另一个开发人员接管。

为了让您的开发人员熟悉其他主题，他们需要积极地处理这些问题。不只是看着专家做他的事。对编程可以在这里工作。仅仅评论是不够的。

当然，文档也很重要。上面提到的单元测试用例也可以作为一个不那么陈旧的文档(因为它是可执行的并且始终是最新的)。因此，它们应该以一种您知道每个测试都在做什么的风格来编写。

• 复杂的升级和产品版本之间的迁移策略

你需要提前为移民做计划。如果您引入了一个新的版本控制工具，那么您需要考虑以后如何从它迁移出去。

• 由于多年来积累的开发，很难理解设计

对我来说，这和上面描述的技术债务是一样的。

• 具有不同级别和不同代码责任范围的不同部门

也许通过部门轮调能帮上忙。

Answer 3

我不知道什么是“最有效”，但我发现以下几点很有帮助。

抽象是关键，有多个维度和大小。抽象应该是有用和完整的，并允许使用者以它所需的域术语定义和实现另一个抽象。

技术债务意味着糟糕的抽象；抽象是难以使用的；抽象是不完整的，从而需要消费客户来弥补所需的差异，这样做最终会导致理解和依赖更多的底层实现，而不是期望的实现，这充其量只能导致更紧密的耦合，而在最坏的情况下，则是在意大利面和/或汤中！

按照大小的增加顺序，抽象可以是:一个常量、一个方法、一组方法、一个接口和/或类、一个接口和/或类、一个层。

分层是关于创建基于彼此的垂直抽象。当我们创建一个提供下一个程序员所需要的领域术语的抽象(以创建他们的层)时，它在隔离时是有效的。层是一组接口和/或类，提供一整套面向域的实体、关系和行为。分层允许分离关注点，这样就可以重新设计中间层，而不会干扰更高的层。

随着代码的发展创建和维护分层需要，需要不断了解消费客户端的域需求，认识到由于域需求不匹配而导致的层使用者的困难，以及定期重构以创建和保持层的有用性和完整性。

在大范围内，分层允许我们转换技术，如实现语言。

我们还需要能够识别我们何时跨越责任边界，例如组织、部门或业务边界。责任界限值得特别注意。我们在这些边界上设计了适当的面向域的抽象。在边界上，我们定义了水平抽象，允许人类和自动化系统的各种组织组装成一个更大的生态系统。

在某种程度上，随着我们努力的规模和范围的扩大，我们需要单独从代码中弹出，这样我们就可以有效地谈论我们的垂直层和水平边界。这是架构或架构抽象。体系结构帮助我们将需求和意图与设计选择和实现之间的点连接起来。

集中化对抗关注点的分离，这反过来又对抗良好的抽象。

一个用于所有持久性的单一共享数据库对于一个小规模的工作来说是很有吸引力的，但是持久性的共存使得具有不同所有权和责任的应用程序很容易直接访问对方的信息，而不是通过适当的水平边界。

一个单一的共享规则引擎类似地从逻辑上独立的关注点收集业务逻辑，并创建这些规则的相互依赖关系，这些规则以后很难分解。