遗留代码最常见的问题是脆弱性。当一个团队想要修改一个脆弱的代码库时，必然伴随着巨大的痛苦。在我们在ThoughtWorks构建产品的10年里，我们吸取了一些惨痛的教训，因为我们试图年复一年地尽可能保持我们庞大的代码库的可扩展性。在本文中，我想分享我们从***挑战赛中吸取的教训。免责声明：写下这些想法，并不意味着我们已经解决了所有问题。我们仍然分担遗留代码的痛苦，并且像团队的其他成员一样，我们每天都努力让它变得更好一点。更新一切。要保持更新，您应该始终渴望更新依赖库和框架。好吧，也许这是现在的共识。但10年前很少有人这么想。有些团队明白升级是正确的工作，我只是想知道他们是否真的在优先考虑它。它总是需要你认真对待它，不要把它拖下地狱变成技术债。原因如下：如果一项任务很痛苦，则需要更频繁地完成它。总是升级的最明显原因之一是升级可能很困难。通常会有一组意想不到的、损坏的依赖项。工作量通常是未知的。经常这样做，这不会有问题。但是还有比简单地避免疼痛更重要的原因。升级依赖项的另一个驱动因素是修复安全漏洞。现在开发软件和10年前有很大的不同。我们的资源库、框架和应用程序的漏洞报告似乎从未间断过。修复错误几乎总是涉及升级一些依赖项。要快速修复错误，升级必须容易进行。不定期升级其操作的团队通常被标记为技术债务。尽管业界比10年前更愿意谈论技术债务，但说服项目经理偿还技术债务仍然是一场非常困难的对话。如果你的团队处于“一直升级一切模式”，你不需要沟通来升级技术债。单元测试遗留代码的主要痛点是进行更改需要多长时间。如果你打算让你的代码长期运行，你需要确保未来修改代码的程序员是完全高兴的。有一种方法具有优势：极快、彻底的单元测试套件。添加新功能，包括任何代码重构，每个周期大致描述为：编写失败的测试；写代码；显示绿色；完毕。如果这样做，您将能够始终运行大量单元测试，有时针对一组特定的测试，有时针对整个套件。如果测试不够快，开发周期就不会轻松。编写代码的经验不应该是：进行一些更改，然后坐等10或20分钟才能运行测试。这很糟糕。确保测试套件快速运行不仅仅与您的设计和代码有关。诚然，您可以做很多事情来加快测试速度，例如避免文件、数据库、套接字、大量对象图生成等。但还有另一个重要提示，即选择有助于加快测试速度的框架和语言。如果您发现自己更改框架以使测试更快，那么您需要考虑一个不同的框架。是的，当我在开发传统的多页面应用程序时，下次将无法在Rails中进行开发。还需要考虑应用程序的大小。当代码库达到一定规模时，需要规划切分方案。这也是您完全理解一段代码的唯一途径。找到拆分项目的切入点不同于学术工作。需要投入大量时间折腾代码，研究各个地方，重新设计，重构。拥有一个快速的测试套件来始终验证您的工作将使工作量级变得更容易。其实，“几个数量级”更像是一种夸张。如果您需要分割一个庞大的代码库并遭受痛苦、缓慢的单元测试套件的困扰，那么您可能会被卡住。我们正在以惨痛的方式吸取教训。因此，尽量确保单元测试速度快，并在开发机器上单线程运行。“抽象分支”应该不是跑了很久，经历过很多技术领导的产品。某些类型的技术领导者，一上任就抱怨现有产品的缺点，并立即想开发新产品。这是正确的。时髦的技术并不总是坏的。对于一个已经存在了很长时间的代码库，它需要新的活力来产生足够的能量来淘汰无能者。我想提出两个重要的观点。新的技术负责人在与团队合作两到三个月之前，不要轻易放弃任何技术。有太多场景无法理解。新的技术领导者需要学会站在团队和代码库的角度思考问题。团队和技术领导需要建立信任和节奏。短暂停留是为了更好的决定。利用抽象分支，是替换新技术的经典方法（除了长期分支的荒谬性）：在组件X前面放置一个抽象。引入组件Y作为X的替代品。抽象智能地路由到X或Y.X正在逐渐被弃用。X被删除；也许抽象也被删除了。有很多次我看不到这个过程顺利进行，因为删除***20%的旧组件的工作量太大了。你无法想象年复一年以多种方式完成这项工作是多么痛苦。它会减慢所有工作并使士气低落。抽象分支是一种极好的模式，它是我完成这种组件替换的唯一方法。然而，它需要团队的全力投入，即在给定的时间范围内逐步淘汰旧组件。技术债务会杀了你仅仅因为我们在这里过多地谈论技术债务并不能保证技术债务将得到偿还。有一件事是肯定的，允许技术债务堆积只会让它无法偿还。“先放一边吧，先处理其他急需的，记下来了，回头再处理。”这很容易说。同时，这可能算作一个明智的决定。但那些所谓的紧迫需求永远不会结束。紧急名单只会越来越长。事情会变得更糟。根据我的经验，当技术债务积压增长得太频繁时，团队会倾向于放弃还款，团队会感到失望，开发人员将无法实现周转，业务将无法获取新的价值。我对如何避免无法克服的技术债务进行了一些思考。一个好的开发团队不会一遍又一遍地以技术债务为借口。当团队意识到同一种技术债务反复出现时，就必须向前推进，并迅速将其纳入日常工作中。我的同事Badri建议团队必须就共同的技术债务达成一致。没有人有权让代码库变得更糟，然后让整个团队为此付出代价。更重要的是，技术领导和产品领导需要相互信任。任何一方都不应该玩“我做主”的游戏。优秀的技术领导者了解业务优先级，优秀的产品经理重视他们可以交付的价值。双方需要讨论风险、成本和收益。如果你不能交付，你的技术债务就会变成一个商业问题，损害每个人的利益。很明显，一个团队要写出长寿的代码还有很多工作要做：为会阅读它的人写代码，不要自作聪明，永远为你未来的同事着想。我很想听听你的想法。
