如果我们熟悉"建立一个可以扔掉的东西"这个短语，那么，我们似乎已经做到了；达到了我们在线应用程序版本1的限制。现在该通过以下方式清理问题：

• 重新组织代码和UI
• 统一UI流程
• 增加更多功能
• 为未来而建
• 修改我们的数据库结构以处理上述所有问题

进行这种过渡的最佳方法是什么？

我们希望避免将所有用户都扔到新系统上(一旦完成)……他们会发疯，我们无法处理呼叫负载。我们的用户范围很广，从技术熟练的二手软件到写软件的类型，再到不知道HTML是什么的类型。

在确保此新设计足以解决版本1的足够问题之后，我们是否应该开始系统的新"安装"并将用户逐步移至该系统？

我们是否应该(以某种方式)逐步更改系统的每个模块，并逐步进行？这可能很困难，因为数据库布局将发生变化，从而导致必须调整"核心代码"和几个周围模块的代码。

拥有一组使用最新版本应用程序的受信任的，耐心的" beta测试人员"客户是否很常见？ (这里的目标是获得反馈并测试新系统上的错误)

还有其他建议吗？第一手经验？

解决方案

回答

我们刚刚在用户身上投放了一个全新的CRM系统，然后让我告诉我们，这样做是一个很糟糕的主意：这对我的团队和我们的客户都非常痛苦。

我会尽一切可能做逐步发布，即使这意味着要做更多的工作。我们将不胜感激，因为我们无需付出任何艰苦的努力就可以使所有产品都移动起来，并且客户将不胜感激，因为它能使我们一次获得产品介绍。

希望对我们有所帮助！

回答

恐怕答案取决于情况。这取决于应用程序的类型和我们拥有的用户的类型。如果不知道系统是什么以及版本更改的范围，就很难提供答案。

也就是说，有一些经验法则。

首先，避免大爆炸。系统的任何启动都会有问题。这个行业到处都是项目，人们认为爆炸式发射是个好主意，只是为了解决即将到来的问题。 Cuil是最近发生的大爆炸事件的因果关系。

为了使初期问题易于管理，我们需要首先使用少量用户，然后慢慢增加用户数量。

其次，我们绝对必须积极做的事情是把用户放在第一位。用户应该要做的工作最少，才能使用系统的V2. 理想的工作量为零。

这意味着，如果我们选择将用户从一个系统缓慢迁移到另一个系统，则有责任确保其所有数据和设置都已迁移。例如，不要做任何愚蠢的事情，例如告诉用户必须在2008年12月9日之前对所有记录使用V1，在之后的所有记录中使用V2.

释放V2的目的应该是使用户的生活更轻松，而不是不必要地增加其难度。

第三，有一个beta程序。这甚至适用于Intranet应用程序。开发应用程序非常类似于Newton-Raphson的用于找到多项式根的方法。我们可以猜测用户的需求，然后将其交付给用户，用户会提供反馈，并且缓慢但可以肯定的是，每次迭代都会使我们更接近问题的解决方案。

Beta版程序可以更快地找到根源，而不仅仅是将新版本强加给人们而没有时间让他们对更改发表评论。 Beta版可更早地加入用户，并让他们感到自己被包含在流程中；我不能强调的重要性。

回答

听起来增量式重新架构应该是敏捷选择。

我从未在Web应用程序上进行过此操作，但是我已经经历了一些相当激进的客户端应用程序更改，这些更改是逐步进行的。如果我们花了一点时间在前面，以确保以合理的方式对工作进行排序，那么它可以很好地工作。如果我们还没有的话，对良好的重构辅助工具进行少量投资将非常有帮助。如果我们使用的是.NET，并且可以基于Java，我可以亲自推荐jetBrains Resharper。我相信IntelliJ IDEA包含类似的功能。

回答

我同意Esteban的观点，最好是逐步发布。这就像装修房屋：将房屋拆掉似乎是一个好主意。但是，这意味着我们必须预先计划所有事情，雇用大量承包商并搬出。然后，计划中的某些更改或者承包商消失了，我们希望节省的所有时间都消失了。同时，渐进式变革使每个人都有机会停下来并在步骤之间进行思考。有时，当较早进行的更改比我们计划的要好时，我们可以避免进行较晚的更改。

我在一个存在巨大扩展问题的系统上工作。我们列出了我们认为需要的所有更改，并根据可能的影响对它们进行了优先排序。然后，我们开始一次进行更改。在列表的大约一半处，我们发现我们已经解决了缩放问题。我仍然有列表，但是我可能永远不需要完成它。我可以随意添加功能并解决其他问题。

当然，有时候最好是硬着头皮把整个东西拆下来。但这比人们通常认为的要少得多。对于关键的操作系统，"拆解"决定可能是致命的。看一下每个人都同意必须带入现代计算时代的大型政府项目，但是不能这样做，因为某些重要的服务会丢失。如果哲学是逐渐变化的，也许它们一次可以现代化。