如何计划企业级Web应用程序？
在我的自由职业生涯中，我已经为中小型企业开发了多个Web应用程序，这些应用程序支持诸如项目管理，预订/预订和电子邮件管理之类的工作。
我喜欢这项工作，但发现最终我的应用程序达到了对维护的高度重视的地步。我回头看六个月前写的代码，发现我不得不花点时间重新学习最初的编码方式，然后才能进行修复或者添加功能。我确实尝试练习使用框架(我之前使用过Zend Framework，并且正在考虑将Django用于我的下一个项目)
我们使用什么技术或者策略来计划一个能够处理大量用户而又不会破坏代码并且仍然保持足够干净以易于维护的代码的应用程序？
如果有人推荐任何书籍或者文章，也将不胜感激。
解决方案
我们应该考虑也许使用SharePoint。这是一个已经设计完成我们提到的所有内容的环境，并且具有我们可能尚未想到的许多其他功能(但将来可能会用到:-))
这是来自官方网站的一些信息。
我们可以使用2种不同的SharePoint环境：Windows Sharepoint Services(WSS)或者Microsoft Office Sharepoint Server(MOSS)。 WSS是免费的，并且随Windows Server 2003一起提供，而MOSS不是免费的，但是具有更多功能，几乎可以满足我们企业的所有需求。
老实说，我建议我们看一下企业应用程序体系结构的Martin Fowlers模式。它讨论了许多使应用程序更有组织性和可维护性的方法。另外，我建议使用单元测试来更好地理解代码。肯特·贝克(Kent Beck)关于测试驱动开发的书是学习如何通过单元测试解决代码更改的重要资源。
在将旧的Web应用程序发展为具有高可用性，高需求的Web应用程序方面，我能提供的最重要建议是封装所有内容。特别是
- 使用良好的MVC原理和框架将视图层与业务逻辑和数据模型分开。
- 使用强大的持久层将业务逻辑与数据模型耦合在一起
- 规划无状态和异步行为。
这是一篇关于eBay如何解决这些问题的精彩文章
http://www.infoq.com/articles/ebay-scalability-best-practices
尽管肯定有关于该主题的好文章，但是没有一篇文章可以替代现实世界的经验。
除了非常小的项目外，可维护性是我们无法直接计划的。在整个项目中，我们需要注意这一点。实际上，提前创建类和基础结构代码的负载会产生比天真的意大利面条式代码更难理解的代码。
因此，我的建议是通过不断重构它们来清理我们现有的项目。查看那些难以更改的部分，并努力寻求更易于理解和调整的简单解决方案。如果该代码太糟糕了，请考虑从头开始重写它。
不要因为我们阅读了更多文章或者使用了新框架而开始新项目并期望它们成功。相反，请确定现有项目的失败并修复其特定问题。每当我们需要更改代码时，请问自己如何重组它以支持将来的类似更改。无论如何，这是我们需要做的，因为将来会有类似的变化。
通过进行这些重构，我们会偶然发现各种可以询问和阅读的特定问题。这样一来，我们不仅会提出一般性问题并阅读有关维护和框架的一般性文章，而且会学到更多。
立即开始清理代码。不要将其推迟到未来项目中。
(对于文档来说也是如此。每个人的第一批文档都非常糟糕。几个月后，它们变得太冗长，里面充斥着不重要的东西。因此，对文档进行补充以解决我们实际遇到的问题，因为下一次的机会很大一年中，我们将面临类似的问题。这些经验将比任何"如何写好"的风格指南更能改善写作风格。)
为了提高可维护性，我们可以：
- 如果我们是唯一的开发人员，则采用编码风格并坚持下去。稍后，当我们浏览自己的代码时，这将使我们充满信心，以了解可能要做的事情和绝对不会做的事情。确信在哪里寻找，寻找什么以及不寻找什么将为我们节省大量时间。
- 总是花一些时间来更新文档。将任务纳入发展计划；将时间作为更改或者新功能的一部分包含在计划中。
- 保持文档平衡：一些高级图表，有意义的注释。最佳注释表明不能从代码本身读取。像业务原因或者某些代码块后面的"为什么"。
- 将计划中的工作包括在内，以使代码结构，文件夹名称，名称空间，对象，变量和例程名称保持最新，并反映其实际功能。这将大大改善可维护性。始终将锹称为"锹"。避免使用大块代码，使用我们选择的语言中可用的方式对代码进行结构化，并为块赋予有意义的名称。
- 低耦合和高相干性。确保我们掌握最新的实现这些技术的方法：按合同设计，依赖项注入，方面，设计模式等。
- 从任务管理的角度来看，我们应该估计更多时间，并对非连续工作收取更高的费用。不要犹豫，让客户意识到我们需要更多的时间来进行随时间分散的小型非连续变更，这与较大的连续项目和正在进行的维护相对，因为管理和分析开销更大(我们需要管理和分析每个变更，包括影响分别在现有系统上)。客户将获得的好处之一是系统的预期寿命更长。另一个是准确的文档，如果他们决定这样做，它将保留他们寻求他人帮助的选择。既保护客户投资，又是强力卖点。
- 如果我们还没有使用源代码管理，请使用它
- 保留为客户完成的所有工作的详细日志，以及任何重要的交流信息(简单的计算机或者基于纸张的CMS)。每次作业前都要刷新记忆。
- 记录未解决的问题，每个客户的想法和建议；在开始分配作业之前，请再次刷新记忆。
- 提前计划实施后的支持将如何进行，并与客户讨论。使系统易于维护。计划参数设置，监视工具，内置的完整性检查。作为初始合同的一部分，向客户出售实施后的支持。
- 通过雇用来扩展，即使我们只需要提供实施后支持的人员，也请执行管理。
推荐阅读：
- 史蒂夫·麦康奈尔(Steve Mcconnell)的"代码完成"
- 有关设计模式的任何内容均包含在推荐阅读清单中。
- 使用框架/ MVC系统。代码越组织和集中越好。
- 尝试使用Memcache。 PHP具有内置扩展名，它大约需要十分钟来设置，另外二十分钟要放在应用程序中。我们可以为每个应用程序缓存任何想要的内容-我将所有数据库记录都缓存在其中。它确实徘徊。
- 如果我们还没有的话，我建议我们使用Subversion之类的源代码控制系统。
