7、当前

“2018年12月17日，星期一，21:40。测试的电子邮件准备好了，即将发送给我们的内部测试组。”

经过12个月筋疲力尽的工作，代码重写终于完工。我们准备了第一个测试版本说明，就像上次这个产品面市的第一天一样。

我们又回来了…

这个产品的重写版本仍处于测试阶段。测试已经快一个月了。我们正在修复错误，倾听用户的意见，审查用户反馈……一切就像4年前一样……

但是在这12个漫长的月中，我们错过了什么呢？如果不是重写，我们会做出什么新产品？！

许多问题可以在这里提出来。但我知道我们只有重写一条路，我们看不到任何其他的解决方案。

如果你也落入了这个陷阱，开始思考“我是否应该从头开始重写代码”，那么在开始代码重写的第一步之前，就考虑自己提问下面的问题，每个开发人员都应该问问自己：

8、你准备好抛弃关于旧代码的所有知识了吗？

这个问题很重要！请诚实地回答：你真的准备好抛弃所有的知识，所有收集到的错误和修复，年复一年的编码结果吗？抛弃旧代码并从头开始，真的是你所期望的吗？当你从这个角度来审视代码重写的决定，你会发觉很痛苦，不是吗？所有那些试图修补bug的不眠之夜都会在你眼前闪过。相信我，因为我有切身体会。

你必须和很多用户交谈才能找到导致你的软件不能正常工作的问题所在，然后你要在你的软件中定位这个错误，重现这个问题，然后找到解决方法，然后……等等。

9、你能保证你会做的比第一次更好吗？

这点很重要：当你从头开始的时候，没有人能保证你会比第一次做的更好。

因为你选择抛弃关于这个软件的所有知识和已经收集的错误和修复，所以同样的错误很可能再次出现在你的新代码里。

可能代码重写团队已经不是第一个版本的开发团队。所以你实际上没有“更多的经验”。你会犯下旧版本中的大部分的的错误，并带来一些新错误，而这些新错误在旧版本中并不存在。

如果你没有很好地计划重写工作，你可能面临新版本比原始版本更糟的风险。然而，既然作出了重写的决定，你就要承担这个风险，这个风险可能导致你失去你的客户。

10、你准备好将几个月/几年的时间优势拱手送给你的竞争对手吗？

你知道需要多少时间来重写你的软件吗？

代码重写牵扯到大量的精力、计划和准备工作。你必须把每项任务计划好，然而一个接一个地冲刺。你必须确切地知道完成这个痛苦的过程的最后期限。没人知道你会不会错过这个最后期限。有很大的可能你不能准时完成这个过程。

你不得不在数月或数年时间内只能交付旧版本给用户，这将置你于极其危险的境地。你完全无法进行任何战略改变或对市场所需的新功能作出反应，因为你没有任何新代码可以交付。

你的客户可能会抛弃你，因为你除了不断地提供一成不变地旧版本外，无法给他们任何新的东西。

这些你都考虑到了吗？

11、从代码重写中我们学到了什么？

从头开始重写一个系统，本质上就是承认作为一个设计师的失败。它其实是在声明，“我们未能设计一个可维护的系统，因此必须重新从头开始。”

——摘自 Max Kanat-Alexander的 Code Simplicity

像其他设计师一样，我们承认我们未能设计好我们的软件，我们从这个精疲力尽的过程中学到了很多东西。在这里，我分享一些我们从中获得的经验教训。

代码重写是开发人员的一种错觉，大多数情况下它不是解决方案。

当你的代码遇到问题时，准确地诊断问题很重要。像每个开发人员一样，你最初的想法不应该是代码重写。代码重写只是一种错觉。因为你在阅读别人的代码的时候，你会认为如果你从头重写代码，你能做得更好。在这种情况下，请始终牢记那个重要的，基本的编程法则。

在决定重写代码前，考虑代码重构

有针对性的重写对于处理代码库中最严重的错误很有用。如果可以限制范围并解决大部分问题，就不要进行整体重写。例如，软件的加载速度非常慢。但这只影响到项目的一小部分。通过小心地移动代码、重构和更改接口，这个问题可以一次性解决。你不必重写所有代码。

代码重写是一条比预期耗时更长、更困难、更容易失败的路。

告诉大家一个开发人员通常在错过最后期限后才意识到的事实：一切都比想象的要花更长的时间。代码重写成本的估计通常很悲观，然而实际的成本几乎总是比你想象的更高，花费的时间也更长。因为总是会有想不到的复杂问题要解决，这些都会使重写过程变得更加困难和痛苦。最后，你很可能不得不接受失败的结果。

确保重写后的产品能够更好地解决用户的问题，至少相同，不能接受更差。

重写对用户没有直接的影响/好处。因为用户不关心代码，他们只想解决自己的问题，仅此而已。在用户看来，能够解决他们问题的产品就是好产品。否则，他们不会用它。用户不关心你的代码重写决定，所以重写后版本必须至少和旧版本一样有效地解决他们的问题。

保持对现有产品的维护和支持。

在我们的案例中，我们有一年的时间没有向用户提供任何软件更新。这对于我们今天生活的世界来说是太长了。尽管我们的产品依然足够优秀，但是没有更新用户肯定会抱怨。当程序员重写代码时，永远不要停止维护当前正在使用的系统。在重写过程中，旧的代码仍然需要维护，小的更新和错误修复需要及时提供给用户。否则，你将面临失去用户的风险。

让用户尽快参与设计过程

确保定期向用户展示最新进展，以便他们能够帮助你捕获最严重的错误。尽快与用户见面是很重要的。他们的反馈将帮助您根据他们的需求设计新产品。不要实现任何不必要的功能，这将避免你的代码库过于复杂化。

保持产品团队同步步调一致

一个产品团队不仅仅包括编程队伍，营销、支持、编程、设计……所有团队需要协力工作。通过定期汇报重写进展情况来确保整个团队步调一致。

在我们的案例中，我们遇到了很多这样的问题。例如，营销团队准备产品测试活动时，他们必须准确了解产品方面的情况，以便让客户为即将到来的产品改变做好准备。但是，有时我们在没有通知他们的情况下做了一些更改。这害得他们必须从头开始准备他们的测试活动。记住：不要浪费任何人的时间。

不要对产品作重大更改。

了解你的产品的弱项和强项，这一点很重要。切记不要改变产品的强项，也即用户喜爱的方面。如果用户对用户界面满意，不要对用户界面作大改动。只做最小的更改和小的用户体验改进。当您用重写后的版本替换现有版本时，确保你的用户不会被新的巨大变化所困扰。有许多情况用户放弃了新版本，因为他们找不到以前版本提供的相同的功能。不要让同样的事情发生在你身上。

不要让你的产品只依赖于一个开发者。

在我们的案例中，CTO是负责开发我们软件的首席开发人员。由于他的立场，我们的产品开发进展缓慢。即使是很小的变化也需要几个星期，有时甚至几个月。我想表达的关键点是保持一直更新，永远不要停止。

版本迁移/更换要循序渐进。

当您确认新版本已经准备好，开始用新版本替换旧版本时。要一步一步，循序渐进。

首先，从一个小型的内部测试组开始，将您的产品发送到该组。收集他们的反馈和崩溃报告，修复错误，迭代新版本，然后重复这个过程，直到你确认你的产品已经准备好公开测试。

进入公开测试后，用户的反馈是你最期待的。你的第一个目标应该是确保您的产品能够解决用户的问题。当你确认新版本提供的功能与旧版本相同或者更好时，就可以进行更换了。这时候开始为新用户发布新版本，并将现有用户迁移到新版本。