许多人的头脑中都有可能吸引数百万人的在线创业公司，但大多数时候你只需要最少的预算（时间和资源），所以你想在一年之内交付。启动后不久，您必须执行一个或一系列升级，其中可能包括：更新基础的代码重构，在软件架构中添加层次结构或重组数据库。这个升级/重构循环继续：
以上述为先决条件，我想认真讨论这个问题，确定Web应用程序可升级解决方案的本质。在讨论中，您可以谈论任何发展阶段（初始，早期升级，增量上升），并涵盖以下其中一项：
答案 0 :(得分：5)
我们公司的网络解决方案是第四代主要代，在过去的8年中发展很快。最新一代引入了各种各样的结构来帮助完成这项任务，因为根据新的客户需求更新上一代变得笨拙。因此，我在2009年花了不少时间思考这个问题。
您可以做的最有价值的事情是采用敏捷方法来构建软件。特别是，您应该维护一个可以每天创建（和）新构建的环境。虽然每日构建只是敏捷的一个方面，但这是解决您的问题最重要的做法。虽然这与可升级性本身不同，但它本身会引入一个规则，有助于降低代码库变得难以处理的可能性（或者您将成为Architect Astronaut）。< / p>
就框架和语言而言，有两个主要要求：框架是长期稳定的，环境支持Separation of Concerns。在这方面，ASP.NET对我来说效果很好：它以合理的方式发展，没有使旧代码无效的不连续性。我使用单独的业务逻辑层来管理SoC，但ASP.NET现在也支持MVC开发。相比之下，我在使用它几个月后开始不喜欢PHP，因为它似乎只是鼓励混乱的做法会危及未来的升级。
关于 DBMS选择，任何现代RDMS（SQL Server，MySQL，Oracle）都能为您提供良好的服务。以下是关键：您将需要维护DDL脚本来管理升级。这只是生活中的一个事实。那么，你如何使这个易于处理？来自任何第三方开发人员的最有价值的工具是我从Red Gate获得的SQL Compare副本。这个过程曾经是一个彻头彻尾的噩梦，并且在我找到这个工具之前，我的代码发展能力受到了很大的影响。因此，通用建议是使用存在工具的数据库来比较数据库结构。 SQL Server在这方面非常幸运。
硬件几乎是不在乎的。只要您的开发过程包含合理的发布构建过程，您就可以随时转移到新硬件。
需求不断变化的策略。再次，请参阅敏捷。我鼓励你们不要再将它们视为“要求” - 传统意义上的大型文件充满了规范。敏捷以重要方式改变了这一点。除了在为外部付费客户签订合同时，我不会保留需求文档，以便我可以确保适当的计费并防止功能蔓延。此时，我们的内部流程非常迅速和流畅，我们的功能请求/错误管理软件（如果您想知道的话，FogBugz）的报告在记录新的营销版本时可以作为我们的文档。
总体重新设计的策略/决策是：不要。如果你对你将要使用的进程进行合理的思考，选择主流工具，并强制执行一个关注点，那么完全放弃HTTP和RDBMS就会导致全面重新设计
如果你足够灵活，任何可以更改，你就不太可能处于所有必须更改的位置的
答案 1 :(得分：1)
为了让球滚动起来，我认为支持依赖注入概念的语言/框架（或者现在似乎被称为控制反转）将在列表中占据很高的位置。
答案 2 :(得分：0)
您会发现RDBMS技术不易扩展。所有供应商都会告诉您，当您尝试多个服务器并进行负载平衡时，会出现固有的限制。其他所有东西都可以用“更大的铁”加强，可能是更高效的代码，但数据库不能轻易拆分和分发。
Web应用程序将有望推动数据库技术的创新，并帮助我们打破古老的关系模型思维模式。它早就应该了。
我建议从一开始就非常关注这个薄弱环节。