编程之广，包罗万象，从用uml工具进行总体框架设计来体现各种设计模式，到高内聚，低耦合，面向接口编程，依赖倒置，再到参数类型的抽象（泛型）,函数的封装，每个私有字段的通过属性进行控制访问，以及软件工程等诸多奇妙的开发模型，归根结底，不过只为两个字：效率！
话说到这里，我知道，一定有人会驳斥我了，他们会说我们所做的这些不光是为了效率，我们是为了提供各种层次上的复用，是为了增强代码的健壮性和抵御变化的能力，是为了加快开发进度和提高开发成功率等等！
我想说的是，以上观点我完全同意，但他们不足以成为驳斥我的理由，我所说的效率的内涵是丰富多彩的！
首先是开发效率，一切项目都是从开发开始的，我说的开发是指从提出问题开始经由需求分系等一系列过程最终测试投入使用的整个过程，而不是单指编码阶段！开发效率决定了开发成本，几十人的团队三天干完了原来需要半个月的工作，这就是各种架构，模式，开发模型的魅力所在，她们提供的各种层次上的复用确实替老板节省了真金白银，提高了利润，要是碰到个慷慨些的老板，程序员的待遇也会有所提高，大家皆大欢喜，更加热爱她们了！进一步推动了她们的发展，成为人见人爱，花见花开的宝贝，甚至于开口必是谈模式，闭口必说架构！其实我们不应该为模式所累，为用几层架构所困扰，只要能提高开发效率，有时候无模式也是一种模式，无架构也是一种架构（注意，我说的是有时候）,如果因为过度套用架构和模式而让一个本来通过简单设计三天可以搞定的项目用了半个月，那就适得其反了！熬来是为了提高开发效率，却反倒成了提高效率的绊脚石，实在不可取！再有就是很多程序员都力求完美，特别是高手（尤其是科学家那一级别的）,经常为了提高10%的性能而让开发周期延长50%,导致软件成本过高，最终得不偿失！
开发完成后，就是部署运行了，这时运行效率又跳了出来！或者用他的另外一个大家更熟悉的昵称：性能！如果一个高性能的软件在同样的服务器上比同类低性能的软件能多提供50%的服务，那么客户就能节省大量硬件的购买和维护费用，软件的竞争力就自然就上去了，市场占有率也随之提高了，软件开发商的利润自然也会跟上，接着就是后续资金投入到新版本的开发中，如果公司没被并购，老板还没换，那么程序员的待遇又继续提高，wow,世界真美好！于是乎一系列提高性能的技巧便堂而皇之的进入了软件的各个角落，为提高软件性能贡献出自己全部的光和热！这些技巧有些是光明磊落，教科书式的经典方法；有些却是江湖上口口相传的独家秘籍，效果貌似不错，但是副作用未知，为将来维护埋下了无数的伏笔！
部署运行后，软件如果总能正确无误并且稳定高效的运行，那自然是天下太平，所有人求之不得！但是哪怕是微软这样天才云集的地方，出的东西也是个百衲衣，周身全是补丁，更何况一般的公司！软件出错是必然的，软件维护是必不可少的，也是耗时最长成本最高的部分！所以维护的效率对一个软件也是至关重要，如果每次维护都要对整个系统进行重新编译，我想无论是部署人员还是用户，都已在崩溃的边缘挣扎了！所以一个合理而不是过度的设计，适当而不是过量的技巧，对于提高维护的效率，那是相当的关键！大量不知为何的设计和不知所云的技巧，绝对的维护人员的噩梦！
综上所述，软件开发归根到底就是个效率问题，只要能把软件整个生命周期的效率提高，任何一个部分的效率都是可以做出妥协和让步的，已达到整体效率的平衡，这才是软件开发的根本所在！
本文来自：http://www.cnblogs.com/tieqixia/archive/2009/06/10/1500108.html