这个问题我想也许有人的答案都跟我以前的答案差不多，不就是解决实际编码当中所遇到的问题吗？不就是解决怎么设计一个程序的问题吗？确实是这样，但这只是表面现象。如果没有深入的挖掘问题的本质，就可能会错误的是用这些知识。
最近在JGTM2004这里工作的时间，我学到了不少东西，有了更高的觉悟，对这个问题的理解就是其中一方面。以前我就没有仔细去想过这个问题，并且站在一个实际做开发的人员的角度来看，自认为这个东西就是为了减轻开发人员的负担，并且为最终产品提供更加优良的特性。其实这个只是一方面，并且就我目前的理解觉得可能还是一个次要的方面。为了阐述这个问题，我不妨举一个具体的例子：
某天你接到一个项目，客户说，我们需要一个对树型结构的数据节点进行遍历，同时对这里面的数据进行一个统计，你就开始噼里啪啦的敲键盘编码了。但是过两天客户跟你说了，现在要添加一个新的统计，于是你就开始辛辛苦苦的进行修改。再过两天用户又说了，去掉原来那一个，只要后来增加的部分。等待产品快要发布了，用户一看，说：“哎呀，看来这样还是不好，你还是给我显示原来的统计数据吧。”等到展品发布之后过了一个月，用户打电话找你然你进行维护——当初没有说清楚，实际上要遍历的数据是网络型结构的……
现实确实就是这样的，事情总是在变。唯一不变的就是一直在变，这个确实是一句名言，甚至就是真理。我想大家也一定认同，问题是作为普通的程序员，可能没有意识到这个变化是从一开始进行开发就出现的，并且在整个产品的生命周期里面，出变化最多的可能是产品发布之前的阶段。而产品一旦发布了，用户通常也能够理解有一些东西改变起来不方便。如果我们从管理高层的角度看问题，可能会更容易解释这个问题。实际上制约一个软件成功的最大要素并不在于技术，而在于两个制高点——“创意”和“市场”。创意我们不谈，我们就说这个市场。你的产品是否买得出去，在于你的产品是否能够适应并满足市场的需求，不能够满足需求的东西显然不可能赚钱。至于你的技术怎么样，用户根本就不关心，甚至你的产品写的很垃圾都好，只要你能够满足用户需求满足市场需求，那就一定赚大钱。那么怎么才能够尽最大的程度满足需求呢？在一个项目的最开始，我们肯定不会非常清楚。如果我们按照自己一知半解的假设去做，那么最终做出来的东西可能就不是用户所需要的，至少是用户所最需要的。所以我们需要用户给我们提出需求，到这里就是传统软件工程学里面的思想。很可惜的是，用户根本就不知道自己需要些什么，而我们对于用户想表达的是什么更是没有头绪。
因此我们只好不停的跟用户接触，不停的把我们现阶段的东西展现给用户，哪怕没有具体实现，哪怕背后的数据都是假的，也要给用户一个Visualize的东西出来看看，这样用户才有可能把需求说明白：噢，这个确实是这样的，那个我不需要，但是我需要的是什么，能不能这么改，这么操作我不习惯，我就要那样的……有了这个你才可能进行更进一步的设计。这里就已经出现了一定的需求变化了——由于原始需求的定义是粗糙的，没有经过验证的，而现在进行了一定的验证之后可能发现原来的想象可能有问题，需要修改。于此同时，你也需要谨记，客户可能会随时反复。只要你的产品没有正式发布，你就没有理由不去响应客户的需求变化。因此你做出来的东西应该能够随时地，方便得在某种程度上面进行修改。简而言之，在设计和开发阶段，需求的变化是最为剧烈的，这种变动的次数可能会很多。怎样有效率的适应这些变化，我觉得可能是设计模式所要解决的一个很重要的问题。
我们来假设一下，某个客户一共会更改10次的需求，如果你每次接到需求变化之后第二天就能够把修改过的演示版本提交给用户评议，而我则每次都要花费10天的时间，我们两个人之间的差别将会是多大。事实上市场的变化速度是相当快的，可以说一年前的产品基本上就进入了淘汰序列，如果你还在卖一年以前普遍使用的技术，那就是一件危险的事情——这表明你跟不上时代的节奏，不可能拉到大量的订单。这说明现代IT行业的产品有一个非常重要的一点就是从“创意”到“市场”这两点之间花费的时间越短越好，也就是要求你的开发效率要高。如果你的设计灵活，能够有效地应付变化，那么你就在这一点上面成功了。
当然，这只是其中的一个方面。今天关于这方面问题的总结就暂时到这里，以后还有什么想法再贴。
P.s.: 其实我到了北京已经有一个星期左右了，这段时间也不是没有发Post，主要都发在cnblogs上面了。因为我担心我的那些Post对于各位大侠来说简直就是班门弄斧，实在不好意思放在博客堂里面。此外要说一声，JGTM2004的私家机器好爽啊！19'的屏幕确实非同凡响，现在看17'的屏幕就觉得好像在看14'的屏幕一样。好工具就是能够激发人的灵感和激情……
打印 | 张贴于 2004-09-03 17:35:00 | Tag:Design & Architecture
留言反馈
我不是速马啊！已经是第4次解释这件事情了……
@ymail:
你说的正是我想的，看来你总结的笔我要好。：）
软件构造从来就是复杂性很高的一项工作，表现在早期的失误发现的越晚纠正的代价越高。这就要求需求必须尽早的稳定下来，而需求分析需要有良好的沟通能力，即使具备这种能力，信息传递过程中还是会畸变。这个过程中客户代表必须充分参与。
在经过几次提交-反馈的循环，得到基本正确的需求后，必须说服自己，说服管理人员，抛弃为弄清需求开发的原型，再站在计算机世界的立场上重新设计软件结构。
当然任何一种过程、方法都不是放之四海皆准的，不同规模、不同领域的软件开发还有各自的特点，用于软件过程各个阶段的时间比例各不相同。
来，hug hug~ :$
程序员就该拽一些，我喜欢。来，拥抱一下:)
变更看来也未尝不是一件好事了
不是液晶的，是我4年前买的DELL P991（SONY OEM）——纯平特丽珑、行频103.9KHz（85Hz时最大分辨率1600x1200；平时我用1280x960x100Hz）。
依我看来，还是传统CRT技术（尤其是珑管）的视觉效果最为出色，其次可能是未来的等离子，再次可能才是液晶的——当然，新技术还在发展中，但是老技术也不一定就不中用了，关键是当初作出了正确的决策。:P
显示器是这样，软件开发何尝不是呢？我拽…… :D
Exactly! 在我们这样的敏捷团队中，一切活动都是围绕适应变化而展开的：快速迭代、持续集成、重构、原型、推迟决策、应用模式……等等等等。
尤其在项目的这个阶段，一切都在持续变化中，一切都只能在做了之后才能看得更清楚（无论是你还是你的客户），因此保持敏捷、拥抱变化并应用适当的方法和技术是目前有效的解决途径——今天强调敏捷是为了明天能够更有纪律的完成任务（balancing agility and discipline）。
重构自己的设计和代码，使其变得灵活，易于修改，是我最近对重构的一点体会，具体的细节Fowler谈的很详细。不知我说的切题没，随便发发牢烧
确实，Weinberg在这本著作中给了我们丰富、深邃的启示，这些启示对我们前些阶段的工作起了相当积极的作用。
具体到目前我们开发的产品和服务，其实并没有一个什么传统意义上的（项目的）客户，因为这是我们的一项发明。广义上说，公司的股东们就是项目的客户。然而，我们的主要工作就是要去深入挖掘我所针对的目标客户群体的潜在需求（是挖掘——而不是收集！）——而目前的技术研发活动只是我们用来挖掘用户需求的工具而已。
《探索需求》——设计前的质量！希望有机会能够与你一起探讨这方面更加深入的问题。：）
我一直在说 把钱留着投资显示器。
LH出来后 更是支持高精度的显示设备，如果发挥不出来，那真是遗憾。
对于开发人员来做，大的可视设计环境很重要，会影响效率的，特别是这toolbar sidebar到处飞的年代
客户说，我们需要一个对树型结构的数据节点进行遍历，同时对这里面的数据进行一个统计。
这其实不是需求，而是客户所给你的解决方案！
客户的这一句话中，没有说出他碰到了哪些问题，也没有说他期待有改善！
而是直接给你解决方案！这束缚你的想向力，被他牵着鼻子走，按他的方案行事。而这之后好像每次的需求变更也是如此！到最后他才说出他需要的是网状型结构。这样的解决方案是最佳且不变的吗，以后会不会变成更简单明了的二维表格结构呢？？客户提出的解决方案往往屏蔽的客户所遇到的真正问题。
需求不是一上来就问客户需要什么！这样他往往会告诉你他的解决方案！
客户只是问题领域的专家，解决方案应该由技术人员来出！
这是我看了<探索需求>第五章后的感受，建议你也看看！
永远不变的是变化，计划不如变化。