《程序员修炼之道》笔记(七)
第七章 在项目开始之前
你是否曾经有过的你项目注定要失败的感觉，甚至是在项目启动之前？有时它也许会这样，除非你先建立某些基本准则。否则，也许你现在就可以建议结束它，并且给出资人省下一些钱。
1 需求之坑
a) 完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的。
b) 不要搜集需求——要挖掘它们。许多项目都把需求搜集当做项目的早期阶段。“搜集”暗示需求以及在那里，你只需找到它们，把它们放进你的篮子，就可以愉快地上路了。但事情在很大程度上并非如此。需求很少存在于表面，它们深深的埋藏在层层假定、误解和政治手段下面。
c) 怎样挖掘需求
用户对需求的陈述常常会嵌入商业政策。比如用户要求“只有员工的上级和人事部门才可以查看员工档案”，但这个陈述背后的需求实际上是“只有指定人员才能查看员工档案”。政策会经常改变，所以建议把政策文档与需求文档分开，并用超链接把两者连接起来，使需求成为一般陈述，并把政策信息作为例子发给开发者，而政策可以成为应用中的元数据。
在讨论用户界面时，需求、政策和实现之间的区别可能会变得非常模糊。例如需求陈述为“系统必须能让你选择贷款期限”，而“我们需要一个列表框，以选择贷款期限”，可能是需求也可能不是。如果用户一定要有列表框，就是需求。如果用户只是在描述一种选择能力，只是用列表框做例子，那么就不是需求。
找出用户为何要做特定事情的原因，而不只是他们目前做这件事的方式，这是很重要的，因为到最后你的开发必须解决他们的商业问题，而不只是满足他们陈述的需求。用文档记载需求背后的原因将在每天进行实现决策时给你的团队带来无价的信息。
与用户一起工作，向用户一样思考
d) 建立需求文档。这可作为开发者、用户等进行讨论的基础文档。
e) 可以用各种UML图作为表达、分析工具。但不要做任何表示方法的奴隶，只要是与你的听众交流需求的最好方法，都可以加以利用。
f) 规定过度。制作需求文档时的一大危险是太过具体。好的需求文档会保持抽象。最简单地、能够准确地反映商业需要的陈述是最好的。但这并非意味着你可以含混不清，你必须把底层的语义不变项当做需求进行捕捉，并把具体的或当前的工作实践当做政策计入文档。需求不是架构、不是设计，也不是用户界面。需求是需要。
h) 看远些。2000年问题（千年虫）的教训告诉我们，不要局限于当下的商业逻辑。抽象比细节活的更长久。
i) 应对需求蔓延。需求蔓延也被称为特性膨胀、特性蔓延。要积极地追踪需求的变化，谁请求增加新特性、谁批准的、批准的请求总数是多少等。管理需求增长的关键是向项目出资人指出每项新特性对项目进度的影响。但项目已经严重拖后，各种责难开始纷飞时，能够准确、完整地了解需求增长时怎样及何时发生的，会很有帮助。
j) 维护词汇表。一旦开始讨论需求，用户和领域专家就会使用对他们特特定含义的术语，于是需要建立并维护项目词汇表，这是定义项目中使用的专用术语和词汇的地方。项目的所有参与者，从开发人员到支持人员到最终用户，都应该使用这个词汇表，以确保一致性。
k) 使用web方式分发需求文档，这可以更好得满足不同听众的需要。项目出资人可以在更高的抽象层面巡视，程序员则可以使用超链接钻入越来越深入的细节中。
2. 解开不可能解开的谜题
遇到看似不可能解决的问题时，要首先确定真正的约束，并在其中找出解决方法。有些约束是绝对的，有些则只是先入之见。绝对的约束必须受到尊重，不管它们看上去有多讨厌或愚蠢。另一方面，有些表面上的约束也许根本不是真正的约束。
a) 自由度。“在盒子外面思考”鼓励我们找出可能不适用的约束并忽略它们，但这并不完全准确，诀窍在于找到盒子，它可能比你以为的要大得多。解开谜题的关键在于确定加给你的各种约束，并确定你确实拥有的自由度，你可能会太快就排除了潜在的解决方案。
b) 一定有更容易的方法。有时会发现，自己在处理的问题似乎比你以为的要难得多。这正是你退回一部，问问自己一下问题的时候：
有更容易地方法吗？
你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
这件事情为什么是一个问题？
是什么使它如此难以解决？
它必须以这种方式完成吗？
它真的必须完成吗？
很多时候，对需求的重新诠释能让整个问题全部消失。你所需要的只是真正的约束、令人误解的约束、还有区分它们的智慧。
3 规范陷阱
a) 编写程序规范就是把需求规约到程序员能够接管的程度的过程。这是一个交流活动，旨在解释并澄清系统的需求，比如消除主要的歧义。除了与最初实现的开发者交谈之外，规范还是留给未来进行编码维护和增强的几批程序员的记录。规范也是与用户的约定——是对他们的需要的汇编，也是一份隐含的合约，最终系统将会符合该合约的要求。
b) 但规范不必要太细致。随着规范越来越详细，你得到的回报会递减，甚至会是负回报。
4 圆圈与箭头
a) 不要做形式方法的奴隶。盲目地采用任何技术，而不把它放进你的开发实践和能力的语境中，这样的技术肯定会让你失望。
b) 我们不是在否认形式方法，但是要明白，形式开发方法只是工具箱里的又一种工具。
