在项目开始之前

《程序员修炼之道》读书笔记 

需求之坑

1 don't gather requirements - dig for them. 不要“搜集“需求，而应该是去“挖掘”他们。因为需求很少存在于表面，通常他们深埋在层层的假定误解和政治手段下面。用户口中描述的东西可能并非他们真心想要的功能。在确定需求时，要找出用户需要做特定事情的原因，而不是他所说的做这件事的方式。你的开发的功能应该是帮他们解决商业问题，而不是仅仅实现了他所陈述的需求。

2 work with a user to think like a user. 要想深入的了解用户需求，一种方式是成为用户，从用户的角度去思考需要哪些功能。

3 建立需求文档。如何描述需求？是形式化的文档还是非形式的？到底什么程度的细节才是合适的？这些还没有定论，但是有一个原则，那就是要目标驱动，能够描述真正的需求，无论是UML还是详细的文字描述。（不要做任何表示方法的奴隶。）

4 Abstractions live Longer than details。在制作需求文档时，不要追求太过具体，好的需求文档应该保持抽象。准确简单的反映商业需求的文档是最好的。

5 谨慎预防“特性膨胀”，要严格控制“只是再增加一个需求“。

6 use a project glossary。使用项目词汇表。确保大家对某些词汇的理解是一致的，不会出现歧义。 7 把需求文档以web方式发布到大家可以访问的地方，比如内网上。通过超链接来是该文档保持抽象层次感，以便满足不同的需要。

解开不可能解开的谜题

1 一个不可能解开的结，亚历山大帝一剑劈开了这个结。有些约束是绝对的，有些是相对的，绝对的约束必须遵循，但是有些外表上的约束也许根本不是真正的约束，或许是由于你的先入为主。许多软件问题也是如此，你确认了所有的约束是真正的约束吗？（类似的问题比如三线四点回到原点的问题）

2 don‘t think outside the box － find the box。面对棘手的问题时，列出所有可能的解决方案，包括你认为不可能实现的方式。逐条解释为什么不可行。问自己它必须以这种方式完成吗？你所需的只是真正的约束，令人误解的约束，以及区分他们的智慧。

等你准备好

1 Listen to nagging doubts － starts when you are ready。当你面对一件任务时，如果你反复感觉到疑虑或是勉强，那此时你要注意它。你的积累的经验和智慧，会让你的直觉告诉你该怎么做。

2 你可能有“启动恐惧症“。启动或者开始一个新的项目，会让你感到身心交瘁，我们许多人更愿意延缓做出最初的启动承诺。那如何判断你是在拖延还是在等待所有工作准备就绪呢？如果你不能确定，那你可以开始构建原型，对你的疑惑的地方进行概念验证。在做的过程中，或许你会消除你原来的疑虑。

规范陷阱

1 编写程序规范，但是不要对系统或者需求的每一处细节都要捕捉。因为有时候语言本身很难向用户或者自己描述清楚领域问题。比如你给我用一段描述来教我学会系鞋带。 这时候，some things are better done than described。 另外，程序规范写的太过详细，会阻碍程序员的发挥技巧和艺术才能的权利。

2 注重实效的程序员，不应该把搜集需求，设计以及实现当成独立的阶段，而应该无缝集成，规范和实现应该是统一过程的不同方面，每一步都应该直接流入下一步。健康的开发过程应该是把实现与测试的意见反馈到规范中去。

3 规范还是必需的，但是不应该在规范这边太过追求详细，掉进规范的漩涡，而阻碍进入下一阶段编码中去。

圆圈与箭头

1 圆圈与箭头代指各种形式化方法，比如case工具，瀑布开发，螺旋模型，er图，uml等工程化软件开发方法。

2 do not be a slave to formal methods。应该批判的看待方法学，从各种方法学中提取精华，融合到自己的开发过程和习惯中去，而不是把方法学的呆板限制当成你世界的边界。expensive tools do not produce better design。