第7章 在项目开始之前

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

---

36 需求之坑　　

51. 不要搜集需求—-挖掘它们
Don’t Gather Requirements - Dig for Them
需求很少存在于表面上。它们深深地埋藏在层层假定、误解和政治手段下面。
52. 与用户一同工作，像用户一样思考
Work with a User to Think Like a User
要了解系统实际上将如何被使用，这是最好的方法。
53. 抽象比细节活得更长久
Abstractions Live Longer than Details
“投资”于抽象，而不是现实。抽象能在来自不同的现实和新技术的变化的”攻击”之下存活下去。
54. 使用项目词汇表
Use a Project Glossary
创建并维护项目中使用的专用术语和词汇的单一信息源。

完美，不是在没有什么需要增加、而是在没有什么需要去掉时达到的。
需求很少存在于表面上。

试图在想在项目初期弄清需求其实是不太可能的，因为那时即使是用户，也不清楚所有的需求，因为用户对需求的理解也是一个循序渐进的过程。我比较认同Scrum中的做法，逐步迭代，让用户参与整个的过程，给出反馈，这其实也是帮用户弄清了其需求。

了解用户为何要做某件事情的原因，而不是其目前做这件事情的方式。因为其可能一开始就错了，因为你可能有更好的方式 — 你才是提供方法的那个人。

同理，在你帮助别人解决问题时，也要记得挖掘其根源，而不要跟着其方式往下走，因为他有可能从一开始就错了。

37 解开不可能解开的谜题　　

55. 不要在盒子外面思考—-要找到盒子
Don’t Think Outside the Box - Find the Box
在遇到不可能解决的问题时，要确定真正的约束。问问你自己：”它必须以这种方式完成吗？它真的必须完成吗？”

对各种约束进行分类，并划定优先级。
对需求的重新诠释，能让整个问题全部消失。

Think out of the box。
转换一下思路，很有可能就会柳暗花明。

38 等你准备好　　

56. 等你准备好再开始
Start When You’re Ready
你的一生都在积累经验。不要忽视反复出现的疑虑。

是良好的判断还是拖延

我们似乎很容易走在两个极端。有的时候我们太激进，还没想好就开始coding了；而有的时候却爱拖延，迟迟不肯动手，总觉得还没准备好。自己属于哪种情况，问问内心其实很容易判断，关键是如何克服自己去正确的做事。

39 规范陷阱

57. 对有些事情”做”胜于”描述”
Some Things Are Better Done than Described
不要掉进规范的旋涡—-在某个时刻，你需要开始编码。

有些规范描述起来相当复杂，但做起来却十分简单。
让PD费劲的在spec上写下来，再让开发费劲的去理解，实在是一种浪费。
这也是在Scrum中引入User Story好处：通过交流就能解决的问题，就不要费劲去写什么spec了。
毕竟，spec不是目的，只是一种手段。

40 圆圈与箭头

58. 不要做形式方法的奴隶
Don’t Be a Slave to Formal Methods
如果你没有把某项技术放进你的开发实践和能力的语境中，不要盲目地采用它。
59. 昂贵的工具不一定能制作出更好的设计
Costly Tools Don’t produce Better Designs
小心供应商的炒作，行业教条、以及价格标签的诱惑。要根据工具的价值判断它们。

没有过时的方法，也没有最优的流程，关键是看你如何摸索出一套适合你们项目于团队的流程。
光追求某种先进的方法，只是流于表而疏于本。again，流程不是目的，只是一种手段。

部分评论摘自豆瓣书评

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://my.csdn.net/dkjkls