我们决定重新写Snapp； 这就是为什么

大约一周以来，我们试图在我们的iOS应用中重现一些令人讨厌的错误，最近我们听到了很多。 大量的脱毛什么也没做。 我们很拼命。 我们决定放弃该错误并宣布失败。 但这无法继续。 必须要做的事情，所以我们决定从头开始重新编写应用程序。

当开发人员正在使用他们未编写的某些代码库时，这种情况经常发生。 他们尝试在各行之间阅读以了解原始开发人员在编写它们时的想法。 几乎总是无济于事，因此他们决定丢弃所有内容并自己编写代码，希望这些错误不再出现。 而且，它并不总是与调试有关。 我们很难在旧代码库的基础上开发新功能。 由于Snapp的快速增长，我们承担了许多技术债务。 我们必须提出一个新的体系结构和代码库，该体系结构和代码库可以使用很长时间，并且在以后的几年中都将在其基础上开发功能。

我们有两种选择：逐渐迁移代码或暂停所有内容，然后从头开始重新编写应用程序。

移民

当然，风险较小的方法是迁移。 这样，我们不必停止开发代码库，并且可以在很长一段时间内顺利进行。 但是我们发现这种方法存在一些问题。

首先，在某些最重要的代码部分中，我们遇到了严重的体系结构问题。 Snapp是一个网络密集型，实时，事件驱动的应用程序，我们的事件处理程序和网络代码在该应用程序中无处不在。 我们对应用程序的静态部分或较少使用的部分没有任何问题，我们的主要问题来自该应用程序的实时功能。 我们发现，重构应用程序的网络部分实际上意味着重写整个应用程序，因此无法进行逐步重构。

其次，我们以前在重构网络代码的某些部分时遇到过失败的经验。 它从来没有完成过，因为那时我们还没有可靠的质量检查机制，并且如果我们无法彻底测试它，就不会冒险发布该应用程序。 重构应用程序重要部分的每一次尝试都扩大到编辑项目中几乎每个文件。 您可能会认为“好吧，您可以先编写单元测试”。 尝试为具有M [assive] VC架构的iOS应用编写单元测试。 这不愉快，不可能。

改写

因为我们排除了“迁移”，所以最终只有一个选择：使用可靠且可扩展的软件体系结构完全重新编写应用程序，并在此基础上编写单元测试。 质量检查小组也有足够的时间提出有关如何测试该应用程序的想法。 这是技术方面的事情，我们开发人员深信重写是必经之路……但是！ 重写已经在生产环境中使用多年的软件存在风险。 像Snapp这样的大型企业所依赖的重写软件的风险更大。 因此，我们必须说服管理层让我们为这个雄心勃勃的项目分配足够的时间和资源。

当我们考虑是否要从头开始重写Snapp时，我们寻求其他公司的经验，就像任何理智的头脑一样。 如果您在Internet上搜索以寻找决定重新编写其应用程序的公司，那么您可能最终会阅读Joel Spolsky的文章，其中涉及Netscape在重新编写浏览器时如何使自己失望。 这是一篇不错的文章，在决定重新编写正在使用的软件之前，您必须先阅读它。 但这只是事情的一方面。 大公司肯定有成功的改写，又有什么公司比强大的优步做得更好的改写呢？ 当我们开始研究这些问题时，我们发现Uber最近启动了他们的新应用程序，这是我们启动该项目所需的灵感。

下一个原因是由于在Objective-C中开发存在问题。 开发该应用程序的第一个版本时，Swift 2尚未发布，不仅它周围没有社区，而且语言本身也有缺陷。 因此，总而言之，选择Objective-C是一个合理的决定。 Flash向前发展了几年，并发布了Swift 4，它相当稳定，几乎所有第3方库和工具都支持Swift，并且使用Swift进行编程非常令人高兴。 团队中的所有新开发人员也对Swift更加满意，因此转向Swift似乎是不可避免的。 从长远来看，这是值得的。

现在我们有了理由，但首先我们必须说服管理层这是一个明智的商业决策。 幸运的是，管理层开了绿灯，我们开始了这个项目。 我们进行了大约5个月的研究，最后提出了自己的架构框架，然后花了将近10个月的时间使用该框架编写应用程序并最终发布。 在这段时间里，尽管开发时间更长，但我们并没有完全停止对旧代码库的工作并继续交付功能。

结论

有时候，我们回想起重新编写Snapp的决定，并认为这是一个错误。 我们不会完成这个项目； 最终我们可能会发现某个应用无法正常运行。 但是我们错了。 我们推出了新版本，没有收到任何投诉。 甚至大多数用户甚至都没有注意到任何东西，这从一开始就是目标。

请不要将重写软件视为解决开发中遇到的每个难以发现的错误的灵丹妙药。 您必须仔细分析所有内容。 也许如果您花费时间重新编写已经运行的软件，则会失去市场份额，因为您必须停止使用新功能。 请记住，这些决策不是技术团队可以做出的。 公司的所有团队都参与以下事务：业务，市场营销，产品，设计，每个人。 他们必须做出相应的计划。