http://www.jdon.com/artichect/why.htm
欢迎大家发表见解，在讨论中明晰自己定位。
你在OA、电子商务等系统有过这样的经验，我在网站上也看到了您写过这方面的技术文章，也拜读过，学了不少，希望您还会继续写出更多的文章。
不必要的假设，如很多该用ioc的地方直接就依赖于具体实现了，损害了系统的灵活性，扩展性，但是对简单性并没有大的帮助。当系统长大之后，反而因为灵活程度不够而损害了系统的简单性。
必要的假设，则在对灵活性影响不大的情况下，大大降低了系统的复杂度。
还有一个原则，叫做do one thing and do one thing well。
当你对一个未来预测的扩展不是100％肯定的时候，不要为了对付假想的敌人冒复杂化系统的危险。只有等你或者不得不做了，或者已经对问题100％了解吃透了，才去着手解决这个问题，然后一击必杀。
唉。我怎么也犯了着天不着地的毛病？一大篇东西都是虚头把脑的。好像我是个专家似的。算了，不故作高深状了。
一句话，我认为设计是讲究平衡的。不能走极端。
听我接着说下去。
软件开发，特别是面向实用的，商用的软件开发，不是空中楼阁，不是闭门造车，一定要考虑成本。没有老板愿意让你借他的鸡，下自己的蛋。如果你的开发、设计，会最终导致他的成本上升的话，你挨炒是迟早的事情。
关键在于，如果计算成本，假设我们要计算长期平均成本，多长期的成本是可以承受的。
假设：如果我的这个设计，能够在下一个项目中起到重要作用，那么效果自然立杆见影。这样的设计，当然是好的。
如果我的这个设计，考虑了今后1年内可能遇到的项目，那么这个设计需要说服老板，颇要花点功夫了。
如果我的这个设计，考虑了今后5年内可能遇到的项目，而且在今后5年内的技术进步中，这个设计不会落伍。那么我就是“超级天才”。没有一家公司（也许banq的公司除外）敢要我这样的设计师。
再换一个说法，banq的JdonSD，到现在有了多少个版本？不断了修改了多少设计？这些设计是你在一开始就已经考虑到了的吗？如果有这样的一个软件，他实现了所有的可能性，对于他的使用者来说，只存在一个如何配置的问题，他本身已经不再需要改进，我认为这是神话。
再换一个说法，我们需要一个标准，来判断什么是有前瞻性的设计，而什么是过度设计？我认为需要通过“长期维护成本＋长期重用成本”来衡量。因为变化是无穷的，我们如果能花20％的成本，满足80％以上的需求变化，这样的设计我认为就是优秀的设计。而剩下的20％变化，应该在具体项目中具体解决，而不是提前解决，这样的追求，我认为就算是过度设计！
以上是我的一点初步的设想，不客气的地方，望banq原谅。
我从另外一个角度说老板和设计的关系，如果老板意识到进行框架或可重用组件设计和完善实际是将公司的积累精华保留下来，我想老板肯定很支持。
以前我看到东大阿派老总就提出三大目标，前面两个是：提高开发效率；提高软件可重用性。这两点都和软件复用技术有关，可见明智的老板必然欢迎可复用软件技术。
中国信息化历程还很短，只有个别少数单位或个人深切饱尝信息系统反复维护、难于扩展之苦。总之一句话：硬件扩展只要花钞票就能扩展，软件则不是这样容易，如果原来软件系统仅仅对“够用”设计，请来再大能耐的高手也无法使得“老树发新芽”，死路一条，难道真的只有推倒重来？
当然政府一直喜欢这么做，这是异类，不去理会它。
可重用的软件并非唾手可得，那需要长时间的实践、积累。
另外，我觉得banq的题目虽然很有视觉冲击力，但也不免极端。Robert Martin等XP的先驱也曾提出过“够用就好”的理论，但与banq这里所说的似乎有点出入。
任何事情都要辩证的看，不是么？
选择那些通用性较高的组件和框架做本地化的调整加入到我们的效率中，可以大大节约项目的开发成本和测试成本。开发通用性组件的任务是专业公司。至于我们做具体的项目的，应该去抓住主要的业务逻辑，而为了将来维护上的方便，在抽象业务逻辑的时候考虑得比较多一些是不能省略的成本。
设计范式是一些典型问题的通用思路。是被大家认可的“公理“，只要熟悉了它的思想，开发的成本并不会增加太多，可是将来的收益却是 事半功倍，合乐而不为呢？
>Robert Martin等XP的先驱也曾提出过“够用就好”的理论，但与banq这>>里所说的似乎有点出入。
其实我们并没有出入，XP讲究项目开始之时“够用就好”，不断迭代，根据需求的变化不断refactorying。
我批评的“够用”思想，是指整个项目宗旨，发现有拓展性余地了，也不去refactorying，够用就可以了，结果，当需求变化时，接手第二任程序员如果有水平，先替你refactoring，但是这种refactoring是必须了解掌握你这位前任的设计思想和思路，又不能影响正常功能实现，多难!
我曾经就做过这种接手活，也耗费了我不少脑力，如果每个程序员都以一种负责任的态度对待编程，自己在自己的能力范围里，将自己的程序编写得具有可拓展性一点，至少象一个标准的OO程序阿，常常是一个方法体内有超过百行代码，不花心思refactorying。
是不是不会refactorying?不是，其实做程序大家都明白，一开始编码时可能对系统实现没有把握，但是很傻地做了一遍后，脑子里已经有比较清晰的理解和把握，这时，再进行refactorying是顺理成章的事情阿。
懒、工资待遇嫌少这些都不是一个标准程序员的素质，“够用”就好的思想往往占主要部分，我要批评的是这种“够用”就好的思想。
一个软件公司如果没有自己的核心技术，公司还有什么，除了计算机就没有什么了，真是可悲哦！！
任何事情都有两面性。够用就好，我觉得是对的。你不可能现在考虑20年后的需求。够用就好，我觉得也不对。只考虑今天的需求，明天肯定寸步难行。这其实是如何看待设计的问题。
设计就是一个Trade-Off。关键就在于找到一个平衡点。而这个平衡点随着时间，地点，人物，经济的不同而不同。所以，并不是人人都可以做好设计，也并不总是有好的设计。
但只用面对接口编程才是提高效率的做法
举个例子：
我原来的主页是基于WEB的，现在做WAP，想将网站做个WAP版，在回家的路上想了想，然后回家只用了两个小时就做好了，所有论坛的贴子都可在WAP下观看，因为是面向接口，我只需要找到数据的源头，将它们的表现形式换一下即可。
WEB:http://www.mwjx.com
WAP:http://www.mwjx.com/wap
产品：要综合考虑进度，资金，竞争对手，开发人员的情况来决定。
你不能说，只要有“够用”想法的程序员就不好，就不能发展，这是片面的看法。关键是学会“通”的思想，融会贯通，灵活变通，涉及到具体问题要分析、权衡、全面考虑。
至于简单和灵活的关系应该说是相辅相成的。
我的理解可能与banq有点出入，“软件够用”应该是功能的够用，与具体的技术实现无关。 banq的意思可能是“软件够用”指为了实现功能，不考虑系统的重用性、扩展性等方面。如果是从这一前提出发，那么我同意banq的观点，国内的软件行业之所以“在风雨中飘摇”，就是因为没有充分地进行系统的设计，其间有架构师的水平问题，也与这个行业追求低成本的风气有关。（最终是不是低成本，地球人都知道）
说到设计，就有一个度的问题，什么样的设计是一个好的设计？什么时候才算设计的完成？这个问题我觉得在很多书里都有描述，不同的软件工程方法有不同的答案，如RUP与XP。自己把握就行了,zbw 说了对过度设计的看法，我完全同意。
但是我觉得Banq在这里想说的可能不是过度设计，而是想强调的是：应该本着可重用性、扩展性和维护性的思想去设计一个系统。我想这个观点应该有大部分人认同的
我们首先得改变自己得这种思想,再谈别的....