我们的代码很烂。实际上，让我澄清一下。我们旧的代码很烂。它很难调试，并且充满了很少有人了解或甚至记得的抽象概念。就在昨天，我花了一个小时在我已经工作了一年多的某个区域进行调试，并发现自己想：“哇，这真的很痛苦。”这不是任何人的错——我相信最初所有东西都很完美合理。最糟糕的部分通常是它只是能够正常工作...只要你不让它做任何超出其舒适区域的事情。
我们的新代码还不错。我认为我们正在做很多好事情。它清晰、一致，而且（希望）易于维护。我们有一个Hudson服务器用于持续集成，并且我们已经开始编写单元测试套件。问题在于我们的管理层专注于编写新代码。没有时间给予旧代码（甚至是旧的新代码）必要的关注和维护。在任何时候，我们的Scrum待办事项列表（针对六名开发人员）大约有140个项目和大约十几个缺陷。而且这些数字几乎没有变化。我们正在尽可能快地添加新功能。
那么，我应该如何避免在旧代码的深处陷入马拉松式调试会话的头疼？每个迭代都充满了新开发和关键性缺陷。具体来说...
你的管理层可能会专注于将工作功能引入产品并保持其正常运行。在这种情况下，你需要为重构旧代码提出商业理由，即通过X时间和精力的投入，可以在Z期间内减少Y的必要维护时间。或者你的管理层可能根本无知（这种情况很少发生，但大多数开发人员似乎认为会经常发生），在这种情况下，你将永远得不到许可。
你需要了解商业角度。对最终用户来说，代码是丑陋还是优雅并不重要，只关心软件执行什么功能。糟糕代码的成本是潜在的不可靠性和更难以更改；它给程序员带来的情感困扰很少得到考虑。
如果你不能获得重构的许可，你总可以自己尝试一点点地进行修改。每当你修复一个错误时，可以稍微重写一些东西以使事情更清晰。这可能比最小可能的修复更快，特别是在验证代码现在起作用方面。即使不是这样，通常也可以在修复错误时多花一点时间而不会遇到麻烦。只是不要太过分。
如果你每次进去时都能留下一点更好的代码，你会感觉好很多。
我可能会去找我的机械师，我们早上有一个小型的站立式会议：
我告诉他我想要轮毂对齐、轮胎旋转和换油。我顺便提了一下： "顺便说一下，我开车过来时刹车感觉有点软，能不能检查一下？我需要什么时候拿回我的车，因为我需要回去工作。"
他把头伸到我的车底下，然后又抬起身来说道：“我的刹车正在漏油，快要失效了。他需要等一个备件，10:30am才能到货，他的员工在中午之前赶不完，但是1:30pm左右我应该可以拿回车子。他的预约已经排满了，所以今天不能做其他的事情，我必须再次预约。”
我问他是否可以做其他的事情，等制动器好了再回来。他告诉我，因为这些制动器可能会导致事故，所以他实在不能让我离开那里，但如果我想去找另外一个机械师，他可以叫人拖车。
由于车很快就会在午餐后完成，我问他的员工是否可以推迟午餐时间，这样我就可以提前一个小时拿回我的车。
他告诉我，他的员工早上8点钟进来，通常工作到晚上。他们赚得每一分休息时间，并且他的员工应该和其他人一起休息。
那些都不是我想要听到的。我希望听到的是，在半个小时内我可以开着我的车子出去，轮毂、轮胎和油都换好了。
我的机械师对我很直接和诚实。你对你的管理层也是这样直接和诚实吗？还是你避免告诉他们他们不想听到的事情？
我不会碰那些我不理解的代码行，也不会提交我没有彻底测试过的新代码。（至少是无意地）
你的问题似乎暗示了一个大量文档不好的代码库通过审核并没有进行任何单元测试。也许你参与了其中，也可能没有。每个人都需要承担责任，包括管理层。无论如何，已经发生了的事情就是这样。你无法回头去改变它。
然而，现在，当下，每个人都有责任停止导致问题的行为。你说你花了一年的时间在难以理解且没有单元测试的代码中工作。在那一年中，当你努力提高自己的理解时，你写了多少个单元测试来记录和验证这些理解呢？
在你艰苦地学习代码的过程中，你又添加了多少注释，以便下次不必再费力？
就我个人而言，我认为“Scrum backlog”这个术语是个错误用词。待办事项列表只是一个列表——如果你愿意，可以称之为购物清单。我去修车时有个清单。我与修车工人的站立会议实际上更像是一个冲刺计划会议。
一个冲刺计划会议是一次谈判。如果你的管理人员进行时间盒处理却没有这样的谈判，他们什么也没有管理。他们只是试图将10磅的粪便塞进5磅的袋子里，而你有责任告诉他们这一点。
当你参加一个冲刺计划会议时，你需要承诺完成一项工作，这是你的责任，也要为此做好准备。准备意味着对每个列表项完成所需的工作有一些想法——包括理解模糊代码所需的时间和编写单元测试所需的时间。
如果有人邀请你参加一个你没有时间做准备的计划会议，请拒绝并建议何时重新安排以便你有时间准备。
如果你有一组没有单元测试的现有代码，并且某个功能可能会影响该代码的操作，那么你需要为可能受到影响的旧代码编写单元测试。当你承诺编写该功能时，你就承诺要做这项工作。如果这使你没有足够的时间去承诺其他功能，只需说出来。不要承诺其他功能。
当你承诺修复错误时，你承诺测试你的工作。显然，这意味着为缺陷编写单元测试。但是，如果它涉及没有单元测试的旧代码，这也意味着编写单元测试以防止因你的更改而导致的潜在问题。否则，你该如何测试修复？
如果你由于承诺了太多功能而未能编写这些单元测试，那么责任是谁的呢？
当你重构代码时，你必须测试所有代码，这意味着为所有代码编写单元测试。如果你有一大堆没有单元测试的代码，那么在重构之前，你必须先编写所有这些单元测试。
我建议你等到这些单元测试就位后再进行重构。同时，如果你坚持将单元测试纳入你承诺的工作估计中，最终所有这些单元测试都将到位。然后你就可以进行重构了。
唯一的例外是为了可测试性而进行的重构。你可能会发现，有些代码没有设计用于测试，你必须先进行重构，例如依赖注入等操作，然后才能创建你的单元测试。当你承诺编写需要单元测试的功能时，你就承诺使代码可测试。在承诺该功能时，请包括此内容在内。
你说你无权无助。当你承担责任并承诺做必要的事情时，我认为你会发现你拥有所需的所有权力。
附言：如果有人抱怨在修复单个缺陷时编写多个单元测试浪费时间，请向他们展示这个视频中的80:20规则并将“缺陷簇”深入他们的脑海。
但与此同时，我被所要完成的任务量和时间所压垮。我的待办事项列表中的每一项都必须存在于那里。这很疯狂，但同时我非常清楚自己曾经走过的路、需要前往的地方以及为什么道路变得更加艰难。
退后一步，清空思维，弄清自己曾经所处的位置和目标的相同之处。因为如果你知道了这些，它就不是那么显而易见了。如果你无法向同事传达任何他们能理解的内容，那么你在商业管理方面会有多少进展呢？
旧代码总是不行的。可能会有某些罕见的例外，由像Kernighan或Thompson这样的人编写，但对于典型的“办公室编写的代码”，随着时间的推移，它们会变得越来越糟糕。开发人员变得更加有经验。新的实践，例如持续集成，改变了游戏规则。有些东西会被遗忘。新维护者无法理解设计并希望重写。所以最好把这看作是正常现象。
以下是一些可能有用的随机建议...
总的来说，在这种情况下取得胜利的方式与编码技能关系较小，而与明智的选择和处理人为因素有关。
希望这些有所帮助。
我建议你跟踪一下有多少错误和代码更改涉及到你的“旧代码”，并在下次团队会议上向经理或其他开发人员展示这些情况。拿着这些报告，你应该能够很容易地说服他们，需要对你的“旧代码”进行重构，使其与你的“新代码”保持同步。
此外，还应该明智地记录下最难理解的“旧代码”部分。一旦得到批准，那么你应该首先对这些部分进行重构。
尝试一些事情：将你的班级分成最差的10％，最好的10％和其余部分。将这些列表交给你的管理层，并说：“我预测在接下来的一个季度中，大多数错误将在第一组中发现。”根据长度，圈复杂度，测试覆盖率 - 无论使用什么工具都方便和舒适。然后坐下来观察 - 并且是正确的。现在你有了一些信誉，当你说：“我想投资一些资源来改善我们的糟糕代码，以减少错误和维护成本 - 我知道在哪里投资那种能量，看到了吗？”
与您的产品负责人交流！解释一下，投入时间进行旧代码的重构将为他带来更高的团队速度，一旦这个障碍被消除，就可以在新功能上获得更多的好处。
除了上述提到的好方法，您还可以尝试以下方法：
为保持未来代码的清洁
用于清理旧代码：
您还可以考虑让产品负责人和Scrum Master捕获旧代码与新代码的不同速度，并相应地使用它们。
