软件重写

目录

介绍

在重写之路上

避免重写

考虑重写

管理重写

总结

---

介绍

一个大泥球继续造成痛苦，因为重写它是令人生畏的，因为重写失败的故事比比皆是。如果苦难到了每个人都无法忍受的程度，那么最终会出现是否重写软件的问题。本文讨论

• 如何降低最终不得不重写软件的风险；
• 如果您正在考虑重写，则着手进行重写的前提条件；和
• 一旦您决定重写，如何提高成功的机会。

本文的大部分内容是基于一个即将被取消的产品的经验。它没有提供客户所需的吞吐量，他们还想要很难实现的新功能。它是其市场的后来者，并且一直在努力增加其市场份额，因此，如果其吞吐量和开发人员的生产率没有显着提高，它可能会被取消。因此，决定该产品需要重写。重写保存了该产品，该产品在20年后仍在开发中。

在重写之路上

避免重写

与其他工程产品不同，软件系统的本质是变化。要求将桥延长50米作为其“下一个版本”的一部分会引起嘲笑，但这种期望在软件产品中很常见。

如果您系统的原始设计没有预期到新的要求，那么添加它可能会很困难，因为它不会与您现有的体系结构完美地结合在一起。如果您不断将这些类型的需求添加到系统中，它将降级为“大泥巴”。技术债务一词描述了这种情况。生产率下降。错误会更频繁地出现，并且变得难以修复。最终，人们开始提出重写的想法。

通常可以通过重构来避免重写，重构是指不断地重新制作软件以保持简洁的整体设计的过程。在极限时，重构和重写是相似的。但是重构是循序渐进的，并且会在产品的整个生命周期内分散其成本，而重写具有破坏性，并且在进行过程中会产生更大的开销。重构通常被认为是进化的，但是重写将被视为革命性的。

尽管重构的重要性似乎正在被人们接受，但是它仍然经常遇到阻力。这样做的主要原因有两个：

1. 经理们希望每个人都致力于新功能。
2. 如果没有损坏，请不要修复。

第一个原因是可以理解的，因为新功能会产生收入。重构没有。但是，这是一个狭隘的观点，因为它只关注可见的内容，而忽略不可见的内容。没有看到的是没有重构的意想不到的后果：系统退化到了这样一个程度，即使每个人都在开发新功能，但随着生产力和质量的下降，交付的功能会越来越少。

这并不是说重构始终是最重要的。如果客户现在就需要修复一个错误，那就修复它，然后去他妈的架构。但这应该在发布分支中发生。适当的修复程序（包括需要进行重构的任何内容）应在以后合并到开发分支中。

不重构的第二个原因——不想修复未损坏的东西——也可以理解。“修复程序”可能会引入错误，并且需要找到并修复错误。而且由于它本身并没有损坏，因此修复它也被视为浪费时间，应花费在开发新功能上。同样，重构也不会发生。一位前同事将其称为验证惯性：一旦对软件进行了测试并且可以正常工作，就没有人愿意更改它，除非在修复错误或开发新功能时不可避免地要进行更改。

为了克服验证惯性，自动化测试至关重要。开发自动测试功能的成本将很快收回。它将消除在每个软件版本发布之前手动执行一组不断增长的回归测试的成本。同样重要的是，它将通过简化重新测试修改后的软件以确认其仍然可以正常工作来鼓励重构。

最好避免重写，因此您需要重构。为了进行重构，您需要自动化测试。

考虑重写

一旦系统变成泥泞的大球，是否应该重写它？进行重写之前，您需要满足几个先决条件。

必须充分了解您的产品要求，并且您必须能够有效地确定新软件是否满足这些要求。

如果您的产品符合IETF发布的行业标准，那么满足该标准将有很长的路要走。如果没有，您应该具有在最初开始开发之前就已编写的产品规范，而其他文档应描述稍后添加的功能。

如果没有记录您的产品需求，则必须记录这些需求，并通过让熟悉产品的人员对其进行审核来进行验证。这些审阅者应包括客户。在不知道需要交付什么的情况下进行重写在临床上是疯狂的。

如果您的产品具有一组良好的测试，它们将帮助确认该产品符合要求。如果测试不是自动化的，则将其包括在重写成本中。您可能会陷入困境，因为没有人愿意重构必须手动重新测试的软件。

您的架构师必须确信重写将大大提高生产率。

如果您的反应是“什么架构师？”，这就是您身处困境的原因之一。除非您找到在您的问题领域有经验的架构师，否则不要重写。然后，架构师将需要时间来研究产品的需求及其现有软件，然后才能估计重写可以提高生产率的多少。

如果您的架构师指出他们可以领导重写工作，从而显着提高生产率，请与高级开发人员一起审查提议的设计，以查看他们是否普遍同意，因为他们承诺重写是很重要的。

系统越大，就越有可能需要一个应用程序框架来显着提高生产率。理想情况下，应该在内部开发框架，以便可以演进以完全支持新功能。但是，如果架构师有信心可以满足您产品的需求，并且供应商对用户做出响应，则可以选择外部框架。

您的框架应定义基类以及它们之间的许多协作。它实际上是系统对象模型的体现。它的基类通常应提供开发人员可以适当定制的默认行为。精心设计的框架

• 提供可重用的组件，加快开发时间；
• 消除了多余的多样性，使开发人员更容易理解彼此的代码；和
• 是即插即用的，允许在不修改现有代码的情况下添加新功能。

您必须在产品的整个生命周期中收回重写的成本。

要确定是否满足此要求，您需要回答许多问题。

如果重写产品，开发人员将获得多少生产力？假设生产率将提高p倍。为了恢复重写的成本，p可能至少需要为2，甚至可能更大。

到目前为止，在软件开发上花费了多少员工年？让我们将此数字称为k，在这种情况下，重写的费用应约为k/p。但这不是那么简单，因为当开发人员重写现有功能而不是开发新功能时，还存在机会成本。在此期间，您的产品将产生较少的收入。

什么是产品的预期寿命，如果它是——或者是不是——重写？重写一个很快就会过时的产品是不可能成功的。竞争对手是否有可能在重写完成之前就将产品替换掉了？还是重写可以大大延长产品的使用寿命？如果可以的话，它开始看起来很有吸引力。

现在我们可以开始估计重写是否可以弥补其成本。比方说

• 产品的预期使用寿命为m年（不重写），n年（不重写），
• 开发该产品的开发人员数量为d，并且
• 重写将花费r年。

我们还可以引入f，表示每员工每年交付的功能数量，但这不是必需的，因为可以在重写之前将f缩放为1，p在重写之后将缩放为1。因此，我们只说d开发人员每年在重写之前先生成d个功能，然后再创建pd个功能。

因此，不重写产量的dm更多的功能。重写会在重写过程中产生dr-k / p个功能，完成后会产生pd（nr）个更多的功能。因此，为了使重写能够收回成本，它必须保持

d(r - m + p(n - r)) > k/p

也就是说，由于重写而将提供的额外功能必须远远超过其成本。

但是，我们已经假设了一些不一定正确的事情。

首先，我们假设收入与交付的功能数量成正比。这是可疑的，因为在任何发行版中，最低优先级功能的值通常小于最高优先级功能的值。例如，将提供的功能数量加倍不会使收入翻倍。

其次，我们假设开发人员的数量是恒定的。但是，几乎可以肯定的是，一旦建立了应用程序框架，便可以添加更多的开发人员。这是因为一个好的框架将允许更多的开发人员并行工作而不会互相干扰。

只要添加新功能带来的收益大于添加其他开发人员的成本，交付更多功能就很有意义。鉴于客户通常要求发行版中的功能多于交付的功能，通常就是这种情况。

如果您认为您可以在重写后添加更多开发人员，则可以用d 0（之前的开发人员数量）和d 1（之后的开发人员数量）替换d，在这种情况下，公式变为

d0(r - m) + pd1(n - r)) > k/p

如果仍不清楚重写是否有意义，则将电子表格放在一起，通过估算每年的收入来评估这两种选择。为此，您需要一个高层项目计划进行重写，这将在下一部分中概述。而且，别忘了还有第三个选择：停止新开发，将产品置于维持模式，然后产出直到没用价值。即使没有更多功能交付，该产品仍将在一段时间内继续产生收入。

管理重写

本文不主张特定的项目管理或软件开发方法。它只是假设您将继续使用现有流程，或者在您认为必要时采用新流程。本文仅限于与重写特别相关的建议。

考虑品牌。

要获得批准进行重写，最好将其称为重新设计，这听起来会更加专业，并且对某些高级管理人员而言也不太可怕。

限制范围。

努力重用您的“泥浆大球”中的某些东西。整个子系统可能会适应新架构而不会影响新架构，尤其是在围绕它们构建包装器的情况下。出于本文动机而进行重写的产品是建立在专有平台上的，该平台的操作系统已被完全重用。配置和操作产品的几个子系统也是如此。重写主要集中在应用程序上。

将重写限制在已经成为泥潭的区域，可以大大提高成功的机会。这就是为什么这篇文章的标语使用了对着你的大泥球做心脏手术的比喻，而不是向它的头部射击。

管理人员将担心重写，因此可能会试图过度限制其范围。因此，作为一名架构师，您可能需要淡化要重写的内容。经理最终将了解真相，但是到那时，将重写从正确的方向转移开为时已晚。

避免客户可见的更改。

回想一下，在激发本文灵感的重写过程中，与配置和操作产品有关的子系统被重用了。其原因之一是，它将避免引入客户可见的更改。如果您打算更改产品的操作方式（例如，其GUI），则必须咨询操作人员。不是他们的管理，而是实际操作的人。人们很容易陷入这样的陷阱:交付你确信是更好的用户界面，结果却遇到了来自那些已经知道如何操作你的产品、不想重新学习的人的抵制。

保持火车行驶。

您可能已经注意到一种假设，即迄今为止尚未阐明的假设是您的产品已经有客户。如果不是，则说明您已构建了原型而不是产品，因此请按照弗雷德·布鲁克斯的建议将其丢弃。或者，如果现在进行营销太重要了，请承诺在初始发行后立即开始重写。如果你的产品是创新的，它应该能够让它的客户着迷，而你正忙于重写。

客户总是想要新功能，因此如果您告诉客户您暂停开发以进行重写，他们将不满意。他们甚至可能开始怀疑您是否不称职，以及是否应该更换您的产品。因此，至关重要的是，继续为他们提供他们所需的重要功能，这些功能也将在重写期间带来收益。

因此，您需要将开发团队一分为二。一组将继续在现有代码库上提供功能，而另一组将进行重写。当重写重新实现了产品的足够功能后，将所有人转移到新软件中以发布下一个版本，在此期间，您将完成所有丢失的功能的重写，同时还提供新功能。

分阶段构建它。

在重写期间将开发团队分成两部分，以便您可以继续提供新功能，这还有另一个好处。它可以防止您一次尝试重写太多内容，这将大大增加失败的风险。

特别是当重写涉及开发应用程序框架时，将需要时间为广泛的开发做准备。因此，通过分配一小部分熟练的开发人员进行重写，从小处着手是明智的。他们的任务是实现框架，以及跨系统所有层和组件的某些功能。只有在拥有稳定的基础之后，才可以为新软件分配更大的组。

本文描述的重写跨越了三个版本（大约18个月），涉及大约50个开发人员。

• 在第一个版本中，六位开发人员实现了新框架和少量应用程序，其余团队继续在旧代码库上工作。
• 在第二版中，团队的一半重新实现了新代码库中的现有功能，而另一半则继续在旧代码库中提供了功能。
• 在第三版中，整个团队都转移到了新的代码库中，其中大约有一半仍在重写以前的现有功能。

举行每周设计会议。

作为负责重写的架构师，请安排每周一次的会议，该会议可能长达三个小时。这次会议的重点将随着时间而改变。首先，它的主要目的是教那些最近加入重写的应用程序框架的开发人员。后来，随着这些开发人员开始重写各种功能，他们将开始询问如何实现具有挑战性的需求。有时，您会了解在框架设计期间被忽略的需求。如果该要求再次出现，则必须认真考虑改进框架，以便可以完全实现该要求。

在上午9:00开始会议。这有助于将结论定在中午的最后期限，并且使开发人员可以在下午进行工作，而会议期间仍在进行新的讨论。并将其安排在星期三。没有人想要以会议开始他们的一周，很多周二都因为周一的假期而成为会议的一部分。周五不上班是因为如果每个人都不能在最后期限前完成工作，有些人就会放弃。因此，星期三最好，尽管星期四也很合理。

发布会议记录，以便那些不能参加的人也可以从讨论中受益。自己编写会议记录，因为它们需要包括有关如何使用框架以及框架如何演变以适应被忽略的内容的总结。

会议可能是徒劳的，乏味的。但是，在本文所述的重写过程中，每周一次的设计会议参加得很好，尽管它是可选的。有时，它开了整整三个小时，有时甚至不到两个小时。它给您带来的好处是，如果没有它，您将不断被咨询打断。该会议通过整合您的大部分咨询时间并减少您回答同一问题的次数，将其降低到可管理的水平。它之所以在开发人员中流行是因为他们了解整个系统：他们听到同事们在做什么，出现了什么问题以及如何实现具有挑战性的需求或实际发展支持它们的框架。

总结

进行重构以避免最终需要重写。为了鼓励重构，请自动化测试。

在决定重写之前，请确保

• 您对产品的要求很了解；
• 您将能够有效地确定新软件是否满足这些要求；
• 您的架构师知道重写将大大提高生产力；和
• 您将在产品生命周期内收回重写的成本。

决定重写后，通过以下方法提高成功的机会

• 限制重写的范围；
• 避免顾客可见的变化；
• 继续在现有代码库上提供功能；
• 分阶段构建新软件；和
• 安排每周的设计会议。