程序员修炼之道---从小工到专家（第7章）

在项目开始之前

36，需求之坑
完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的。
不要搜集需求－－挖掘它们。通常，它们深深地埋藏在层层假定、误解和政治手段的下面。
挖掘需求：
需求要明了，不要嵌入商业政策。
把政策信息的文档和需求的文档分开，并使用超链接连接起来。让需求成为一般性陈述，并把政策信息作为例子发给开发者。最后，政策可以成为应用中的元数据。
这样，当政策信息变化，只有该系统的元数据需要更新，这让你去开发为支持元数据而进行良好的分解的系统。
找出用户为何做特定事情的原因，而不只是他们目前做这件事情的方式。最终，你的开发必须解决他们的商业问题，而不只是满足他们陈述的需求。用文档记载需求背后的原因将在每天进行实现决策时给你的团队带来无价的信息。
成为用户，参与他们的工作一个星期，仔细观察系统实际上如何被使用，有利于你与用户建立信任和沟通的基础。
与用户一同工作，以像用户一样思考。
建立需求文档：
有时接口就是系统。成功的工具会适应使用它们的双手。
用于捕捉需求的用例概念。描述系统的特定用法，不是根据用户界面，而是以一种更为抽象的方式。
看待用例的一种方式是强调其目标驱动的本质。
用例图：
可以用UML活动图捕捉工作流，而且有时要为手边的事务建模，概念层类图很有用。但真正的用例是具有层次结构和交叉链接的文字描述。
不要做任何表示方法的奴隶，只要是与你的听众交流需求的最好方式，就可以使用。
规定过度：
太过具体的需求文档很危险，保持抽象。把底层的语义不变项当作需求进行捕捉，并把具体的或当前的工作实践当作政策记入文档。
需求不是架构。需求不是设计，也不是用户界面。需求是需要。
看远些：
Y2K问题
抽象比细节活得更长久。
再抹一层薄薄的薄荷：
许多项目的失败都被归咎于项目范围的增大，－需求蔓延，特性膨胀，蔓延特性论。
管理需求增长的关键是向项目出资人指出每项新特性对项目进度的影响。
维护词汇表：
用户和开发者，使用一套词汇表。
把话说出来：
通过web分发项目文档。

37，解开不可能解开的谜题
解开这个谜题的秘诀是确定真正的约束，并在其中找出解决办法。
自由度：
解开谜题的关键在于确定加给你的各种约束，并确定你确实拥有的自由度，因为在其中你将找到你的解决方案。
不要在盒子外面思考－－要找到盒子。
对你的各种约束进行分类，并划分优先级。先确定最为严格的约束，然后再在其中考虑其余的约束。
一定有更容易的方法：
你可以退回一步，问自己
有更容易的办法吗？
你实在设法解决真正的问题，还是被外围的技术问题转移了注意力。
这件事情为什么是一个问题。
是什么使它如此难以解决。
它必须以这种方式完成吗？
它真的必须完成吗？
你会有让自己吃惊的发现。对需求的重新诠释能让整个问题全都消失。
你所需要的只是真正的约束、令人误解的约束、还有区分它们的智慧。

38，等你准备好
倾听反复出现的疑虑－－等你准备好再开始。
作为开发者，你在整个职业生涯中都在做同样的事情。你一直试验各种东西，看哪些可行，哪些不可行。你一直在积累经验和智慧。当你面对一件任务时，如果你反复感觉到疑虑，或是体验到某种勉强，要注意它。你可能无法准确地指出问题所在，但给它时间，你的疑虑很可能会结晶成某种更坚实的东西，某种你可以处理的东西。软件开发仍然不是科学。让你的直觉为你的表演做出贡献。
是良好的判断，还是拖延：
解决这个问题，初步构建原型。
1，开始后，你可能觉得自己实在浪费时间。那就放弃原型，回到真正的开发。
2，随着原型进展，你可能会突然意识到有些基本的前提错了，而且你有了解决办法。那么愉快放弃原型，投入正常的项目。
记住，只是写个原型，并不是打算真正的开发。

39，规范陷阱
编写程序规范就是把需求规约到程序员能够接管的程度的过程。
有些描述无法被准备理解。
语言本身表达能力存在问题。
对有些事情“做”胜于“描述”
没有给编码者留下任何解释余地的设计剥夺了他们发挥技巧和艺术才能的权利。
你应该倾向于把需求搜集、设计、以及实现视为同一个过程－交付高质量的系统－的不同方面。健康的开发过程鼓励把来自实现与测试的意见反馈到规范中。
不要一致沉浸在规范中。在某个时刻，你需要开始编码。考虑构建原型或曳光弹开开发。

40，圆圈与剪头
不要做形式方法的奴隶。
大多数形式方法结合图和某些说明文字来捕捉需求。更愿意向用户展示原型， 并让他们实际使用。
形式方法似乎鼓励专门化。让所有人对系统都有所了解，不要各自分离，会带来糟糕的交流和工作的浪费。
我们喜欢编写有适应能力的动态系统，使用元数据让我们在运行时改变应用的特征。
形式方法能成功吗：
有些方法带来的好处何时会显现：在使用该技术、其用户培训自己的同时，生产率和质量明显下降。决不要低估采用新工具和新方法的代价。要做好准备，把使用这些技术的第一个项目当作一种学习经验。
我们应否使用形式方法：
绝对应该。批判地看各种工具和方法，不断改善一套工作习惯。不断努力提炼和改善你的开发过程。
不要向方法的虚假权威屈服。
昂贵的工具未必能够制作出更好的设计。