防止代码库随着更多故事的实现而变成拼凑

Question

我的团队通常的工作流程如下所示:特性是由产品管理部门规划的，然后集体细分为业务需求。然后，开发人员开始一个接一个地处理这些需求，直到下一个特性出现。

我注意到的一个问题是，由于故事是以增量的方式实现的，关联的代码往往会被添加到现有代码上。最初，很容易确保新代码与旧代码相匹配。但随着时间的推移，代码库的各个部分开始出现分歧，整个过程变得杂乱无章。

我一直在考虑一个初步的设计故事来记录方法和测试存根，讨论接下来要遵循的开发策略等等，因为其余的故事可以帮助解决这个问题，尽管我不确定它到底会如何工作。

或者，在此基础上，我建议将我们的代码评审系统从单一的技术同行评审转变为一个共识系统，但我不确定，就每个人都会对其进行审查，我们将付出多少努力，我们将遵循什么样的标准，或者我将如何证明它会带来价值。

Answer 1

使用敏捷开发一片一片地构建应用程序意味着您没有构建您不需要的东西，但是您仍然需要为应用程序设计架构。

当我看到一个代码库变成一个杂乱无章的增强，几乎没有技术方向时，我看到了一些应该解决的问题：

• 团队缺乏技术领导(如“架构师”、“体系结构”和/或“系统设计”)
• 一个代码评审过程，它可能需要一些改进。
• 一个更关心今天最后期限的团队
• 团队成员之间普遍缺乏沟通

所有这些都是可以修复的。有些人需要得到管理层的授权才能提供技术上的领导。考虑到产品的高层次需求和基本路线图，担任此角色的人员应该能够选择合适的体系结构。他们需要与工程团队合作，确保增强适合于架构，方法是为每个增强使用UML图，在代码评审期间(在游戏中有点晚)或在开始一个新故事之前召开一个快速的设计会议。

代码评审过程可用于发现体系结构问题，并为指导团队进行适当的编码实践提供了一种方法。您提到的代码评审过程涉及一个单一的技术主管作为最终批准者。如果你的代码仍然不合格，我会质疑“技术领导”是否真的是技术领导(见上一段)。

最后，制作日期的要求可能是整个建筑物倒塌的地基裂缝。“技术领先”可能是在传递应该重构或重新设计的代码，因为管理层让整个团队以短跑运动员的速度跑马拉松，而他们只是想让自己的头浮在水面上。这也是技术领导发挥作用的地方。在某种程度上，技术领导需要站起来，与管理层沟通，在没有给工程团队设计软件系统的适当时间的情况下，永远追逐约会的成本。

这不应该导致一个人领导一群没有头脑的猴子用键盘。它是一种对话和团队的努力来设计应用程序，从一个人开始，协调工作并将团队指向正确的应用程序体系结构。从那时起，团队需要越来越多地负责应用程序设计，而技术带头人则引导他们走向正确的架构。

Answer 2

您所描述的是Martin所称的松弛性Scrum。

我同意的唯一解决方案是eXtreme编程实践：

• 测试驱动开发
• 无情重构
• 对编程
• 基于主干的开发
• 连续积分
• 进化设计

总的来说，要注重纪律和技术的精益求精。您必须承认，要使代码库达到标准，需要付出一定的努力(我猜大约占您开发工作的30%-20% )。

Answer 3

您应该应用开放/封闭原则和单一责任原则

这解决了在添加特性时代码的复杂性和耦合性增加的问题。

按照旧的方式，我们只需要再用一个用例来扩展适当的功能。这样做的时间足够长，您就会拥有包含许多用例的长函数，这些用例越来越难以测试，更改也越来越危险。

我发现在开始实现之前评估现有代码是否适合修改是很有用的。在SCRUM中，这将出现在对ready的定义中，重构现有代码的成本将在评估过程中被考虑在内。

如果重构不是一件小事，我喜欢创建一个单独的故事(enabler故事)，并标记它阻止实际的故事。

例如，我最近需要更改我们实例化数据库连接的方式。但是，大约有100个复制/粘贴代码实例创建了数据库连接。随着时间的推移，这段代码在没有疏忽的情况下增长，每个需要向数据库层添加类的人都会复制现有的类并添加自己的代码。我得出的结论是，代码不适合修改，并创建了一张票证，要求按照SRP/DRY原则创建数据库连接工厂。

我还想从SqlConnection重构到IDbConnection，以增加可测试性，但结果证明这需要大量的搅动。重要的是要记住，最重要的是把针头轻轻地移向正确的方向。我们不会在一夜之间清理15年来编写的代码。只要我们继续朝着正确的方向前进，情况就会继续改善。