<分区>
如果您熟悉“ build 一个扔掉”这个短语，那么，我们似乎已经做到了；我们即将达到在线应用程序版本 1 的限制。是时候清理一切了:
实现这种转变的最佳方式是什么？
我们希望避免将所有用户都转移到新系统(一旦完成)......他们会吓坏，我们无法处理调用负载。我们的用户范围广泛，从技术精通的用于编写软件的类型到不知道 HTML 是什么的用户。
我们是否应该开始新的“安装”我们的系统，并在我们确保这个新设计充分解决版本 1 中的足够问题后逐渐将用户转移到它？
我们是否应该(以某种方式)逐步更改我们系统的每个模块，并分阶段进行？这可能很困难，因为数据库布局会发生变化，导致不得不调整“核心代码”和几个周围模块的代码。
让一组值得信赖、耐心的“Beta 测试者”客户使用应用的尖端版本是否很常见？ (这里的目标是获得反馈并测试新系统上的错误)
还有其他建议吗？第一手经验？
最佳答案
恐怕答案要视情况而定。这取决于应用程序的类型和您拥有的用户类型。不知道系统是什么，不知道版本的变化范围，很难给出答案。
也就是说，有一些经验法则。
首先，避免大爆炸发射。任何系统的启动都会有问题。这个行业充斥着人们认为 bang-bang 发射是个好主意的项目，只是为了让发射陷入困境。 Cuil是最近大爆炸发射的一个引人注目的因果关系。
为了使初期问题易于管理，您需要先与少量用户合作，然后慢慢增加用户数量。
其次，您绝对必须积极做的事情是将用户放在第一位。用户应该做尽可能少的工作来使用系统的 V2。理想的工作量是零。
这意味着如果您选择缓慢地将用户从一个系统迁移到另一个系统，您有责任确保迁移他们的所有数据和设置。例如，不要做任何愚蠢的事情，比如告诉用户他们必须对 2008 年 12 月 9 日之前的所有记录使用 V1，对之后的所有记录使用 V2。
发布 V2 的目的应该是让用户的生活更轻松，而不是不必要地增加难度。
第三，有一个测试程序。这甚至适用于 Intranet 应用程序。开发应用程序很像 Newton-Raphson 的求多项式根的方法。您猜测用户想要什么，将其交付给用户，用户提供反馈，缓慢但肯定地每次迭代都会让您更接近问题的解决方案。
Beta 程序将帮助您更快地找到根源，而不是仅仅将新版本强加给人们而没有时间让他们对更改发表评论。 Beta 有助于让您的用户更早地参与进来，并让他们感觉自己融入了这个过程；我怎么强调都不为过。
关于database-design - 实现大型系统更改，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59974/