《程序员修炼之道》Tips摘录06

第7章 在项目开始之前 Before The Project

36. 需求之坑

完美，不是在没有什么需要增加、而是在没有什么需要去掉时达到的。
——Antoine de St.Exupery,Wind,Sand,and Stars,1939

提示51: Don't Gather Requirements-Dig for Them
不要搜集需求——挖掘它们

如果需求被陈述为“只有人事部门才能查看员工档案”，开发者最后就可能会编写代码，在每次应用访问这些文件时进行明确的检查。

但是，如果陈述是“只有得到授权的用户可以访问员工档案”，开发者就可能会设计并实现某种访问控制系统。

当政策改变时（它会改变的），只有该系统的元数据需要更新。

找出用户为何要做特定事情的原因、而不只是他们目前做这件事情的方式，这很重要。

有一种能深入了解用户需求、却未得到足够利用的技术：成为用户。

提示52: Work with a User to Think Like a User
与用户一同工作，以像用户一样思考

Cockburn的用例模板:

用例样本:

制作需求文档时的一大危险是太过具体。好的需求文档会保持抽象。

提示53: Abstractions Live Longer than Details
抽象比细节活得更长久

提示54: Use a Project Glossary
使用项目词汇表

如果用户和开发者用不同的名称指称同一事物，或是更糟，用同一名称指称不同事物，这样的项目很难取得成功。

37. 解开不可能解开的谜题

提示55: Don't Think Outside the Box-Find the Box
不要在盒子外面思考——要找到盒子

很多时候，对需求的重新诠释能让整个问题全都消失——就像是戈尔迪斯结。

你所需要的只是真正的约束、令人误解的的约束、还有区分它们的智慧。

38. 等你准备好

了不起的表演者有一个共同的特征：他们知道何时开始，何时等待。

提示56: Listen to Nagging Doubts-Start When You're Ready
倾听反复出现的疑虑——等你准备好再开始

39. 规范陷阱

有一个挑战：写一份简短的描述，告诉别人怎样系鞋带。

这是一件极其困难的事情。而我们大多数人不用有意识地思考就能系上鞋带。

提示57: Some Things Are Better Done than Described
对有些事情“做”胜于“描述”

有时一幅图胜过千言万语，有时却又毫无用处

40. 圆圈与箭头

盲目地采用任何技术，而不把它放进你的开发实践和能力的语境中，这样的处方肯定会让你失望。

提示58: Don't Be a Slave to Formal Methods
不要做形式方法的奴隶

提示59: Expensive Tools Do Not Produce Better Designs
昂贵的工具不一定能制作出更好的设计