从头开始重写应用程序的利弊|应用程序所有者指南

你的产品是否有遗留的代码，它是否遭受了随之而来的所有缺点？看似简单的功能平均上市时间是否在飙升？找到愿意在应用程序使用的过时技术堆栈中工作的开发人员是否越来越难、越来越贵？您的产品是否受到错误和/或性能问题的轰炸？

当这些和类似的问题开始困扰产品所有者时，他们可能会面临一个两难的境地，即决定是否从头开始完全重写应用程序。那么，什么时候值得从头开始重写一个遗留应用程序呢？在这篇文章中，我们将看一些能帮助你下定决心并最终做出正确决定的要点。在我们深入研究从头开始重写应用程序的利弊之前，让我们简要地解释一下应用程序重写的含义。

什么是应用程序重写？

首先，让我们定义项目重写的真正含义。这个定义是必要的，以确保我们在同一页。已经有许多文章讨论软件项目重写。因此，人们认为重写的内容有多种定义。

有完全重写（又称从头重写），还有部分应用程序重写的功能定义，也称为修改、重写、调整或移植。如您所见，软件产品重写的概念很快就会变得混乱。

在这里，我们将重点讨论从头开始重写应用程序。与项目重构相比，这种方法有几个优点，也有一些缺点。

现在，请记住，我指的是应用程序的完全重写，它有时仍然允许重用某些代码位。例如，算法的实现或各种（适当隔离的）业务用例有时可以很容易地重用，只要业务需求没有改变。

相反，项目重构非常注重重用旧代码，只从头开始重写某些部分。两者之间的界限很细，这取决于你假设的定义。

有关重构过程的更精确的解释，以及何时选择重构而不是重写更好，请参阅我们的《重构与重写移动应用程序-应用程序所有者比较》一文。

从头开始重写应用程序的优点

更快的迭代

应用程序重写通常还包括应用程序架构的重新设计。新的体系结构应该确保代码在将来易于更改和改进。这将导致更快的迭代向前推进，以及更短的反馈循环。

无限快速发展

开发人员不会以任何方式受到现有代码的限制，从而更容易使用最新的技术。这将帮助您确保应用程序是使用最先进的技术开发的。这不是一个空洞、浮华的时髦词。新技术是最流行的技术。软件工程师喜欢与他们保持同步。这意味着如果您决定扩展您的开发团队，市场上将有更多的开发人员可供选择。

每一个遗留应用程序的产品所有者都知道为一个旧的语言或框架寻找开发人员是多么困难。除此之外，技术越受欢迎，它周围的社区就越好，规模也就越大。这意味着有更多关于如何处理开发人员偶然发现的bug和问题的知识。反过来，这意味着应用程序开发过程更快。

避免过去的错误

如果您已经组建了一个具有进行大型重写经验的开发人员团队，那么新的开发团队将有可能避免犯以前的开发人员所犯的错误。为此，您还需要完全控制业务领域知识。

刷新应用程序设计

应用程序重写允许您重新考虑整个应用程序设计和模块，以及其优化。您有一个很好的机会来修改您的用户旅程地图，并确保沿途的每一步对最终用户都是不言自明的。请记住，设计良好的用户体验是不需要解释的。

重新思考应用程序功能

您有机会验证您的产品是否以最有效的方式解决了用户的问题，并决定它真正应该具有哪些功能。重写是一个很好的机会，因为您可能会重新访问用户旅程图或类似的文档。

从头重写应用程序的风险

使您的竞争对手受益

决定完全重写而不同时维护旧的应用程序就像给你的竞争对手一年或两年的自由时间（例如，在构建新功能方面）。从商业角度看，这是一个很长的时间。由于如此糟糕的战略规划，整个公司都倒闭了。

耗时

时间是重写过程中消耗的关键资源。如果不能达到目的并解决关键问题，其中的一部分将被浪费掉。在重写过程中，可能会出现一些最初隐藏的业务需求，并且可能会发生额外的延迟。

也重写工作特性

重写将丢弃应用程序中按要求工作的部分。重写要求开发人员重新实现所有特性。当应用程序用另一种语言或框架重写时，这是不可避免的，当产品继续使用相同的技术堆栈时，这是反对重写的一个优点。

因此，当我们谈论使用完全相同的技术重写应用程序时，即使是一段非常好的代码也常常需要重写。为什么？因为它可能不适合新的架构。如果我们要留下这样一段旧代码，我们就必须立即使用一些适配器，以便新的体系结构可以使用这个旧部分。这是一个危险信号，因为遗留代码不应该控制新的体系结构。

当然也有一些例外，例如，你可以复制一些数学算法，但这种情况很少见。

浪费以前的错误修复

以前为修复bug所做的努力都白费了。项目的前一个版本可能有很多专门知识和开发时间用于修复bug。开发人员可能被迫解决仅从所使用的技术和框架衍生出来的问题。应用程序中的一些bug总是与使用过的库和架构相连接，否则就不会出现。进行一次彻底的重写就好像所有的努力都是徒劳的。

提高利益相关者的期望

你必须满足组织的期望。当应用程序被重写时，来自整个公司的利益相关者肯定会期望投资回报。例如，它可以是更好的用户体验/用户界面设计、开发速度的提高、整体产品性能的提高、用户对应用程序的评价提高、用户保留率的提高，或者是更多的新用户。产品所有者必须管理这些期望。你将是那个让利益相关者相信蛋糕值蜡烛的人。

什么时候重写遗留应用程序会是一个错误？

当一个新团队看到一个继承的项目代码时，说服客户并重新开始似乎是明智之举。碰巧，对于应用程序拥有者来说，这并不总是最好的选择。

此外，用与原始版本相同的开发团队重写应用程序很少是个好主意。假设开发人员由于各种原因（紧迫的截止日期、低技能的开发人员）积累了太多的技术债务。如果这是唯一的原因，公司绝对不应该进行完全重写。

如果开发人员要求重写决策仅仅是希望摆脱他们负责的混乱局面（除其他外），这表明您缺乏可靠的流程。每一个应用程序拥有者都应该知道，给团队一张白纸而不花时间去发现为什么这些问题会首先出现，并且可能会改进组织流程，这很可能会导致同样的情况——技术债务不断增加。

即使你确信你有一个优秀的开发团队，这在很大程度上取决于行业的活动周期。如果你的竞争对手给了你很大的压力，你不应该以重写为目标。决定完全重写意味着发布新特性将在很长一段时间内停滞不前。

当然，除非您有时间和资源进行重写并并行维护当前产品版本。如果您的业务集中在市场的特定利基，您的上市时间指标将是最重要的。在这种情况下，你应该利用你所有的资源，以确保你将能够获得所需的部分市场蛋糕。

为你的应用程序重写做一个潜在开发团队的背景调查

正如我已经提到的，从头开始重写应用程序的关键是确保指定的团队能够达到预期。理想情况下，您希望了解开发人员是谁，他们的背景是什么，以及他们的总体经验。您可以在专业社交媒体（如LinkedIn）或开发人员的私人Github存储库中查找此类详细信息。

如果你决定与一家软件开发公司合作，这将变得更加容易。一家重视客户透明度的公司会愿意与您分享其中的一些细节。例如，您可以获得有关特定开发人员参与的项目的详细信息或有关客户满意度的一些指标。

请记住，您可能无法获得确切的产品名称，因为许多项目是在严格的保密协议下开发的。在这里，您可以阅读一篇关于如何检查应用程序开发的潜在合作伙伴的深入文章。

要重写的项目有许多形状和大小。如果你有一个大的，复杂的产品，你最好雇用一个非常适合的软件工程师团队。

从长远来看，对于以前从事过复杂领域和大型代码库项目的经验丰富的开发人员来说，支付额外的费用是值得的。这些经验丰富的开发人员可以引导您完成收集业务需求的过程，向您提出明智的问题，从而能够快速掌握业务领域的细节。

确保团队了解您未来的计划和其他功能

大家一致认为这并不总是可行的。或者至少不是完全的。也就是说，我并不是想说服任何人重新使用瀑布模型（这对于IT项目来说是一个完全的错误）。

问题是，如果你：

• 从业务的角度了解您的领域，

• 甚至有一个模糊的产品路线图，

• 能够掌握并规划一套几乎完整的功能，

• 可能还有某种用户旅程图……

它将使开发人员和负责选择正确的体系结构模式的人员的工作变得更加容易。您对预先计划的产品功能了解得越多，未来的代码就越不复杂。同样，我们讨论的不是瀑布过程，而是一个良好的产品设计研讨会/产品发现的结果。

通常，软件开发机构也会提供产品设计研讨会服务。这是一个向开发团队传达应用程序远景和需求的理想机会。这些研讨会的几天将为团队提供未来几个月的足够知识。与软件工程师一起，您可以尝试将这些特性调整为对启动应用程序至关重要的少数特性（最小可行产品）。

同时，呈现给开发人员的更广阔的视野将使他们能够规划体系结构。他们将能够以一种使添加新特性几乎不费吹灰之力的方式来构建它，极大地限制了遗留代码在未来的影响。什么是遗留代码，为什么要担心它？在我们的文章中，您可以阅读更多关于重构和重写应用程序的比较。

从头开始重写应用程序的利弊——结论

对于开发者和产品拥有者来说，重新编写一个应用程序似乎很有诱惑力，但从商业角度来看，这并不总是最好的选择。作为产品所有者，您必须考虑许多因素，以确保这是您的组织蓬勃发展所需要的。获取免费电子书-产品所有者指南。

如果您根据本指南决定重写是一条路要走，请记住前面还有很多需要考虑的注意事项。首先也是最重要的是，你必须确保你依赖的是一个经验丰富的开发团队，对他们来说，这不是他们的第一次牛仔竞技。

在复杂的应用程序重写中成功的几率与开发人员的经验以及他们创建的团队的优秀程度成正比。除此之外，确保尽一切努力向他们传达你对应用程序的看法。团队对业务领域的理解越深入，他们的工作就越有效率。