程序员修炼之道读后感(七)

需求之坑

Don’t Gather Requirements—Dig for them.不要搜集需求——挖掘它们

挖掘需求

需求是对需要完成的某件事的陈述

“我能否在你们工作时在这里呆上一周”——注意不要妨碍别人工作

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

建立需求文档

将挖掘出来的需求建立需求文档；

看待用例的一种方式是强调其目标驱动；

把形式化的模板用作备忘录；

规定过度

制作需求文档时的一大危险是太具体；

       需求不是架构，需求不是设计，也不是用户界面，需求是需要；

看远些

       Abstractions Live Longer than Details.抽象比细节活得更长久

再摸一层薄薄的薄荷

       许多项目的失败都被归咎于项目范围的增大——也称为特性膨胀，蔓延特性论或需求蔓延

维护词汇表

       对用户和领域专家的属于进行有条例地记录并随时维护

       Use a Project Glossary.使用项目词汇表

把话说出来，放在Web上，大家一起看。

 

解开不可能解开的谜题

自由度

Don’t Think Outside the Box—Find the Box.不要在盒子外面思考——要找到盒子

对于各种约束和条件边界，应该从更高角度看，忽略一些不适用的约束，并确定你确实拥有自由度。

一定有更容易的方法

对于“不能解决的问题”经常问问自己：

1．  它真的必须完成吗？

2．  它必须以这种方式完成吗？

3．  是什么使它如此难以解决？

4．  这件事为什么是一个问题？

5．  你是在设法解决真的的问题，还是被外围的技术问题转移了注意力？

6．  有更容易的方法吗？

 

等你准备好了

Listen to Nagging Doubts—Start When You’re Ready.倾听反复出现的疑虑——等你准备好再开始

是良好的判断，还是拖延？

       对于无法判断项目是否拖延，可采取一种行之有效的技术构建原型，而对于有困难的地方，可进行“概念验证”(proof of concept)

       最可怕的事情：花了几周认真开发，却发现原来只要一个原型。

 

规范陷阱

注：这里的规范通常就是我们平常说的设计

程序规范就是把需求规约到程序员能够接管的程度；规范也是与用户的约定，一份隐含的合约。

Some Things Are Better Done than Described.对有些事情“做”胜于“描述”

应把需求挖掘、设计以及实现视为同一个过程，而不要信任：需求分析、编写规则、编码是独立的分开进行的。因为这些步骤本身就是无缝的。

太细的规范可能会演变为“分析瘫痪”(analysis paralysis)

 

圆圈与箭头

盲目采用任何形式方法，其结果往往令人失望

形式方法缺点：

1．  大多数形式方法结合图和文字说明，但用户通常喜欢原型

2．  形式方法鼓励专门化，大家更希望了解整个系统，而不是冰山一角

3．  元数据让我们运行时改变应用特征，而大多数形式方法鼓励你在对象间建立静态关系

Don’t Be a Slave to Formal Methods.不要做形式方法的奴隶

批判地看待方法学而从中提取精华，融合到每项工作中。

Expensive Tools Do Not Produce Better Designs.昂贵地工具不一定能制作出更好地设计。