讨论到现在，有一部分人认为：需要取得平衡，为什么要取得平衡，因为他们潜意识中还是认为过分考虑设计会增加复杂性，不会带来简单性，因此，够用就好，虽然有些问题，但是那都是客户以后碰到的，正如一位道友说：做项目当然"够用"就好，因为做完项目可能该项目与你无关了。
也确实，等客户发现该项目够用的问题后，那也是几年或十多年以后的事情，难道中国信息化过程还要按照外国教训再走一遍？而且必须走？

充分考虑设计到底是否会增加复杂性？我认为不会，只有蹩脚不正确的思维形成的设计才会造成系统的复杂性，还是那句话：真正科学的设计反而是简单的，下面以一张图说明：

图中低部是够用思想造就的水平线，如果不满足够用，那么系统的复杂性就会增加，到达图中的A点时，是系统的一个瓶颈，这时的系统既复杂，又没有灵活性，几乎一无是处，这也是很多人萌生“够用”思想的根源。

但是，坚持下去，用新的软件思想，思维方式和编程方式重整系统，系统会超越瓶颈,超越A点，达到一种新的简单’而灵活美妙的境界。

可能有人不相信，但是我相信，我也曾经经历过这种喜悦，这好像类似信仰了，我做程序就有对那种喷薄而出的简单美妙境界追求的冲动，所以我作程序有兴趣，我也不怕将程序做复杂。

这就涉及到迭代设计的概念了。
“够用就好”是基于当前的需求所作的设计，会考虑一部分未来的需求。随着时间的推移，系统会越来越复杂，越来越难维护。这时就需要对系统重构了。重构之后会形成新的架构，主要还是考虑当前的需求和一部分的未来的需求。如此循环，迭代，即进化式的开发。
只考虑当前需求，够用就好，而不考虑未来的需求的一次性设计，才是我们真正应该抨击的。

我来表明一下我的观点：

如果我可以把握我做的东西的整个框架，而且非常清晰的知道应该怎样做才是对的，那么我会注意它的扩展性；

但在很多时候，我不知道这个东西以后会怎样，也就是说我但是无法拿出一个最佳的解决方案，那么我根本不会自己去搞一个很大的框架，而会简捷的把问题解决。

Anders Hejlsberg在谈他为什么不引入Java中的Check Exception特性的时候也说：

“我一直都持这样的观点：如果你对一个问题没有准确的说法，没有一个完美的解决法案，那你干脆什么也不说，而不是试图去建立一个解决它的大框架。如果你让初级程序员写一个日历控件，他们常常会这样对自己说，“天啊，我决定写一个全世界最棒的日历控件，它将针对不同的历法展现出多态行为。它会有各种花哨的特性。”他们只有两个月的时间来完成这个任务，却把几乎所有的时间用在搭建程序的框架上，而只花两天的时间来写真正有关日历控件的代码。这样的设计方法从一开始就错了。而我却不断看到这种现象，一而再，再而三的发生。因此我坚信简单就是美。除非你能解决一个通用问题，否则不要把一个解决特定问题的方法变成一个通用的框架...”

说到底还是谈得太空泛了。所以大家争吵半天，说不定最后发现自己反对的也是对方反对的。^_^

如果就具体的例子说，就说引起这个话题的pico的使用吧？我问为什么使用pico，banq说灵活，为什么灵活？体现在什么地方？banq却说不出个所以然。
这就让人很难不觉得这个对pico的使用是盲目的，只是跟着别人的脚步走而已。

没有人反对系统要设计灵活，但是没有具体实例，各人对灵活的理解都不一定一样，怎么讨论？

那篇pico的文章，强行把pico和ioc绑在一起，好像使用了ioc就要使用pico。可是二者之间的必然关系却忽略不提。这怎么让人理解呢？

“够用就好”的观点是针对完成用户需求而提出的，当然没有问题，难道我们作用户不需要的软件功能？
框架、模式等等设计方法是针对用户需求变更而提出的，如果我们原来版本的软件不能完成用户新的需求，或者我们没有理解用户的真实需求，就需要利用“以前”良好的设计，使得完成需求变更对以前程序的影响降低到最小。
我觉得这个主题的讨论好像有点问题。“够用就好”不等于不设计，当然要设计。设计的目的也不是开发没有必要的功能，而是提供一个易于维护和扩展的框架。二者不矛盾！
一个好的设计人员会不知不觉的将程序设计为灵活和可扩展的。一个好的公司会将这样的设计纳入软件配置管理，并不断改进和应用它们。这样就形成了框架。在上述前提下，软件设计的工作量会大大减少，程序人员会集中精力于功能实现。这就是以不设计胜设计，以无招胜有招^_^.
如果道友们有在东软（CMM5）工作的，应该可以体会到这种NB的境界。软件重用只依靠设计是不够的，管理工作至关重要。

好的结构或者框架是设计出来，而不是CMM出来的。
你说的这个话好像就是说"今天的鱼真好吃，因为我的米饭是用高压锅煮的".
简单优秀的设计是一种创造性活动的结果。CMM只是对平凡活动的过程管理。就好像孙子兵法(当然，CMM在软件研发过程中的地位远没有孙子兵法在军事中的地位)，那么多人读过了，但正儿八经能够运用自如的有几个？关键还在于人，而不是工具。一个企业CMM水平再高，也只能说明或许(注意，是或许，不是必然)有不错的过程管理人才，但如果没有在软件设计上的牛人，还是搞不定框架设计这个活。
以我们的做事方式，只要有足够的利益驱动(比如信息产业部或政府其他部门出面规定不同规模的软件项目承接商必须有CMM相应级别以上的资质，就像现在要求系统集成资质一样)，不出两年，CMM认证也会像ISO认证一样遍地开花(虽然实际上大家还是照常干活)。

1、没有软件不需要设计，也没有人愿意承认自己是“过度设计”。关键在于如何判断一个设计是否过度，有没有量化的标准。

2、“长期维护成本＋长期重用成本”是我在前面提出的一个标准，我们先讨论计算的方法，在讨论长期的数量级。

3、在每一个项目中，都存在一个维护问题，没有一个客户会对我们的产品一见钟情，而且终生不渝。我们常常会讨论变态的客户，其实那往往是因为客户的需求在我们的设计考虑之外。如果一个产品发布以后，经常遇到变态的客户，那就说明你的设计有大毛病。

4、长期维护成本应该等于每一个采用这个设计架构的产品的整个生命期的维护成本。

5、长期重用的成本取决于两个因素，一方面是这个企业的产品目标需求是否稳定，以及对于这些需求的“共通性”的总结是否合理。另一方面是设计的质量，包括重用这个设计的学习曲线，用这个设计进行开发的难度、成本、出错的概率等等。

6、长期重用成本应该等于每一个采用这个设计架构的产品的二次开发成本。

7、如何计算成本呢？通过工作量，当然，不同的水平的人的工作量是不等价的。如果只是一个设计架构的使用者的开发工作量，还不是太要紧。如果需求更改一定要架构设计师亲自动手才能搞定，那成本就太高了。

8、最后一个问题，也是最难的问题，就是长期应该有多长？首先它不应该太短，如果只有两三个项目能够用上这样的设计，（如果每个项目时间长达2年，除外），那么当然不能算数。当然也不可能太长，比如基于JDK1.0的设计，到了现在（J2EE1.4）还打算用，自然也不现实。时间问题还取决于老总对这个设计师的信任（或者说迷信），如果老总认为只要是他的设计，我就不遗余力的支持了，那就是设计师的天堂，如果老总一定要在当年的财务报表上看到收益，那就太难了。

我的意见是：两位数以上的项目，2～3年的使用期内的，总成本最低的设计，是最有价值的设计。

to ajoo
关于Pico以后我们有机会继续讨论，这个“够用”不是针对我们以前的讨论，以前我碰到过很多这样的想法，只是那次pico讨论让我觉得有必要单列题目专门讨论这个问题，虽然很泛，但却是思想境界和编程追求的问题，我只是想让更多程序员能脱离编程“苦海”，以此为乐趣，是不是我太自以为是了，呵呵。

我不是在吹捧CMM，但是我极力推荐好的软件过程管理。
没有好的管理，或许能产生一个个好的软件设计的人才，但是不会产生好的软件公司。一个由一帮NB人组成的公司只是一群乌合之众，他们能够写出高水平的程序，可以开发成功一些项目，但是他们绝对不能生产软件产品。
这是提外话了。
我认为，软件重用＝良好的设计＋过程管理

看到banq谈到的“思想境界”的问题，我感觉是非常需要强调的，本身也深有体会：当看到“设计模式”时，眼前一亮，很多疑团豁然开朗；当看到“体系结构”时，感觉以前想法太窄，拘泥于一点；但看到“极限编程”时，太棒了，成对编程。时间久了，自我感觉上了一个层次，所谓站在巨人的肩膀上了吧！

既然说到“思想境界”，就不能不说到“理论联系实际”，没有实践，不能证明理论的正确；没有理论，不能引导更好的实践。很多东西是需要自己去摸索的，在这条路上有很多步骤是不可避免的，最多只能降低其破坏性。忘记实际，空谈理论是要不得的，所谓境界高者，无非是在实际环境中能取得更好的结果。

思想有好有坏，有深有浅，应该包含很多种的思想，软件够用也是其中之一，关键要看思想发挥的场合、作用，而不是一味的否定其的在特定环境下的特殊作用。

banq，其实咱俩的爱好挺一致的。我也是特喜欢写框架，特有成就感。呵呵。
也最讨厌别人写出一些不遵循接口编程原则，结构僵化的代码。

不过，我最近正在一个自我的转变阶段。逐渐有点认识到凡事不能无限制地追求完美。架构的灵活性也总是有限的。
逐渐理解了这个“适当的假设”的必要性。

实际编程中，我也更注意do one thing well。就是说，一个功能，能不做就不做，要做，就做好它。

框架不怕功能有限，怕的是太复杂，怕的是不容易扩展。一个功能，当暂时想不到一个完美的解决办法，我会优先选择放弃它，宁可保持simple and stupid。要知道，加东西比删改对一个框架来说更容易。

至于说设计，呵呵，我这么说可能不大合适。我觉得追求design pattern实在是一个最错误的事情。
时常看到程序员们在讨论“这是pattern A还是pattern B？”，“pattern C的定义是这样的吗？”
让我感叹程序员大好的青春时光就被浪费在模式考据学的泥潭里。

不是说设计不重要。但是，设计不是这么个学法。
design pattern这本书就象围棋的定式书。如果你能够理解这些pattern试图解决的问题，那么把它当作best practice来开阔一下思路很好。但是初学者去直接背诵这些定式招法是有害无益。搞些似是而非的比喻来试图“加深理解”，也只是让人产生一种“我好像理解了”的假想，一样是南辕北辙。
其实，只要你按照接口编程的原则，最小化接口，最小化assumption，自然就会得到良好的设计，你管他是叫肥猪模式还是波若波萝密模式？

就象那个ioc，我都很惊讶会有人给这个东西起出五花八门的名字来。

我比较欣赏这位老兄的这段话，说出了我的心声：
The principles behind what is now being called IoC have been described in many papers over the last 20 years or so, under names such as configuration programming, third-party binding, or architecture description. The idea is to make explicit the relationships between components/objects, instead of code that creates those relationships being hidden within object implementations. (Note: the term Inversion of Control is usually used somewhat differently to the way that the IoC folks are using it.) If you actually design your program using OO principles -- as a set of objects that talk to each other and have no other, hidden interdependencies -- it is very rare NOT to end up with an "IoC" architecture. The fact that so many people think that IoC is some exciting new insight is an indication of the poor quality of OO design that the industry puts up with.

其实，不只ioc，那么多pattern，不都是按照OO原则对某种特定情况设计出来的自然结果吗？何必搞成这么深奥的样子？

全文在这里：
http://www.enterprisej2me.com/blog/java/?postid=12

to ajoo
所谓难者不会，会者不难。OO思想是现在所有新技术的基础，有了OO思想，理解这些新技术都没有问题，包括MDA等。

我前天去给人家咨询，从J2EE到项目工程管理（XP）到开发方法（MDA），大家听了之后，觉得这三个环节是必须紧紧相扣的，缺一个都做不好，为什么？因为它们建立在OO基础上。

所以OO是一个新世界，但是传统程序员因为教育体制弊端和经验，经常很难进入OO世界，他们从他们的朴素的过程化思维经验中无论如何都推断不出：软件竟然可以重用！面向接口简直故弄玄虚，自找麻烦。

看来讨论到现在，我们找到了根源，还是编程世界观问题，到底你有没有真的OO了?

关于框架和成本问题。

我的观点是：以后没有做产品和做项目之分了。一家软件公司将结合做框架产品和做项目两者结合，因为没有一个放之四海皆准的最终产品，只有可以不断重用的框架产品，正如传统工厂需要根据订单生产产品一样，正是所谓按需生产，如下图：

一个软件公司将分两条线工作，做新项目，然后从中提炼框架，一旦框架提炼成功，可以反复应用在以后新项目中，那么开发这个可重用的框架的成本是由这些新项目分别平摊的，成本并不高。

所以，这其中也不存在够用能够节省成本的想法。

对于某个具体的项目来说，当然是够用就好。如果将来要复用某一部分的话，可以进行重构。把更多的时间花在业务上，学一些写的技术。等将来成熟以后，再应用。

那可不可以理解为：够用是暂时的方案，但不是程序员最终追求的目标？