程序员修炼之道读书笔记---第七章 在项目开始之前

 不管是在做需求、分析、编码还是在测试，都会遇到各种难题。大多数时候，他们其实不像最初看起来那么困难。

解决难题的关键是找出真正的约束，有些约束是绝对的，有些只是先入之见。

找出其中的绝对约束，从多个不同的角度分析问题。

各种形式的开发过程和方法学都有其优点和缺陷，但是他们都无法代替思考，所以不要成为方法学的奴隶。

不要搜集需求，要发掘它们。因为需求掌握在客户身上。任何描述都可能存在偏差，所以应该通过多种方法进行确认。

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

为了找出真正的需求可以使用以下的方法：

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

2.         成为用户：我能否在你们工作时在这里呆上一周-----与用户一同工作，想用户一样思考。

需求的潜在风险是需求的爆炸，应对的方法是向出资人指出每项新特性对项目进度的影响。永远将不去实现这个需求作为决策的选项之一。

在需求发掘的过程中建立需求文档。因为需求文档是深入讨论的基础。

需求文档应该简单易懂，因为听众相当广泛。

需求文档写作之前应该维护词汇表，以确保一致性（就像人名一样，不存歧义）。

需求的潜在风险之一是太过具体。需求不是架构。需求不是设计。需求不是用户界面。需求是需要。最简单的、能够准确反映商业需要的陈述是最好的。

需求不为自己而写，需求应该尽量传递到用户和程序员那里。只有这样需求才有意义。项目越庞大，就越必要。

项目开发过程中各个环节的界限极其模糊，开始新的阶段是让人身心交瘁的经验。此时就要分辨是良好的判断还是拖延。解决的方法是选择困难的地方，进行“概念验证”。

从“政治策略”的角度来说，去构建原型也许比简单地宣布“我觉得不该启动”，并开始玩单人纸牌游戏更能让人接受。

如果反复感到疑虑或者体会到勉强，要注意。软件开发仍然不是科学，让直觉为你的表演做出贡献。

编写编程规范是一项重要的工作，但是编程规范不应追求完美，随之规范越来越详细，得到的回报会递减。其实在项目周期的每个阶段都会存在这个问题。

（代码有自身的惯性，这种惯性会最终导致代码偏离需求，严重的时候会抛离需求轨道；接受代码偏离需求，但是当代码抛离需求时需要重新分析需求是否正确或者及时纠正代码）。

方法不应也不能代替思考。不要低估采用新工具和新方法的代价。提取方法学中精华的部分融合到每个月都在变得更好工作习惯中。

 

程序员应该不断努力提炼和改善你的开发过程。