转自：http://kb.cnblogs.com/page/516088/
http://kb.cnblogs.com/page/516088/
知晓各种设计模式，框架，技术技巧只是事情的一方面，而知道何时该、何时不该应用他们才是更重要的问题。在不知道一种技巧方式如何能对系统的开发有帮助的情况下，这种模式方法极有可能成为一种开发的阻碍，而不是一种有益的帮助。
好代码是廉价的代码。
但是 … 设计模式毕竟是个好东西 … 不是吗？
当然，但它们好在哪里？它们能提供什么好处？
- 容易维护
- 产品更健壮
- 容易理解
- 易于日后的改进提高
- 更好的可跟踪性
你会发现所有的这些最终都落到一点上：从长期的角度看，它们能让你更快的做事情。这事情有可能是系统迁移，或是增加一个新功能，不论是什么，通过运用这些方法模式，你会在时间效率上获得实实在在的好处。
系统
用PHP创建一个发邮件的表单，表单里有几个表单项，用邮件把这些数据发送给某个人。除此之外，表单里的内容还要存入MySQL数据库里。
现在，用什么方式实现它们最好？按照传统的说法，采用最好的实践设计模式，你可能会想到这些：
- MVC
- N-层设计，包括数据库抽象层
- 对象关系映射(ORM)
- 可能用到的框架
- XML配置和相关模型
- 等等.
SCRUM
它不会允许你在实现东西上有任何所谓“正确方式”的奢侈行为。
复用性
如果你有一个清楚的远见，知道什么地方会复用这些东西，这就不同了，因为你确实有一个内部的业务需求在指导你正确的开发方向。
最后的思考
- 了解你的设计模式，知道它们各自的好处(我一直认为，好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式)；
- 让你的代码廉价：
- 当模式能够给你带来好处，而且为你省时时才去使用它们；
- 如果不是这样就不要使用它们(例如：想想你最近的一次为什么要把系统迁移到一个不同的数据库上？)；
- 当框架能够帮你提高开发速度时才使用它们；
- 在必要的时候重构，不要做一些超前性的开发；
我想，如果你能按照这些指导原则做事，你会发现开发周期变短、实现的代码更简洁，易于调试，易于维护修改。