由于本书的阅读没有先后之分，所以我跳过了几章内容直接阅读了第七章在项目开始之前和第八章注重实效的项目的内容，了解一些方法和理论。也得到了一些感悟。
1：需求之坑：不为收集需求，挖掘它们。有一种能深入了解用户需求，却未得到足够利用的技术：成为用户。与用户一同工作，以像用户一样思考。描述需求文档时，要使用项目术语表。用WEB来收集和管理需求。
2.解开不可能解开的谜题：遇到不可能解决的问题时，退一步问问自己如下问题：1）有更容易的方法吗？2）你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？3）这件事情为什么是一个问题？4）是什么使它如此难以解决？5）它必须以这种方式完成吗？6）它真的必须完成吗？
3.等你准备好：一件事没有开始，是谨慎？还是在拖延？我觉得要通过自己的判断，事情的优先循序和紧急情况还有你的准备，再决定是否要做。而不是鲁莽的去做或者是不做拖延着。
4.规范陷阱：需求文档写上几百页不成问题，但是一旦用户看到了实际运行的系统，你就会被各种变更要求淹没。对有些事情“做”胜于“描述”
5.圆圈与箭头：有些设计图是给程序员看的，对最终用户没有意义，不要认为用上了UML等形式化描述图形就能制作出好的设计。
6.注重实效的团队:不要留破窗户，不要重复你自己，按功能划分团队
7.无处不在的自动化：持续集成的概念
8.无情的测试：早测试，常测试，自动测试
9.全都是写:嵌入在代码中的注释，注释应该讨论为何要做某事、它的目的和目标。
10.极大的期望：给他们的东西要比他们期望的多一点。
11.靠巧合编程：软件开发者，每天就像工作在雷区，有成百的陷阱等着抓住我们。
多余的或不必要的代码可能这次能够正常运行，但换个环境可能就会崩溃，另外会使代码变慢，或引入新的bug。总之，不要靠巧合编程。
要想着尽可能在开发周期的早期抓住并修正错误，道理很简单，但在项目进度压力大的时候，把这句话忘在脑后。
为编码工作划定优先级，把时间花在重要的上面，经常也是最难的部分。但如果基础设施不正确，再花哨的界面或装饰也没有什么用。
12.算法速率：没有什么可说的，就是o()表示法。
13.傲慢与偏见：在你的作品上签名。
下面是一些书中的观点解析：
足够好的软件
就是俗话说的一鸟在手胜于二鸟在林.
首先得确保软件可用性,至于亮点,特色,在可用以后才需要考虑.而且还得明确用户需
求(虽然这点始终被强调).大家都知道系统不可能做的完美,但是自己着手开发的时候
总是朝着尽可能完美的方向发展,欺骗自己说,这个功能多么伟大,一定要加上去,那个
功能多么惊天动地,最后反而成为四不像,使项目延期.
在第一次企图做那个todo list的时候,想着把calendar和task两项功能完整的结合,
同时还想着把contact功能也加入,甚至还有ms porject的管理功能,但是一切都太多,
以致于设计了少数几个界面以后就陷入了无止境的功能权衡中,因为太多东西又想完美
.所以第一次最终结果是除了最后那个简陋的复杂的界面,什么东西都没有,当然如今代
码也已经不知道是不是被自己删除,能够留在自己硬盘上并且使用的还是那个简简单单
的GeeTask,功能不多,但是的确对我来说,足够好了,如果还有新的功能,添加就是了,不
用一次就做一个大而全的玩意出来.
也想起在上一个公司参与的第一个项目,房地产的预警系统,先前同事通过研究,不知
道从哪里搞到一些其他人做的预警系统,动用高深的所谓经济学景气循环算法来计算,
艰难的实现这些公式.当然我们自己也不知道这个是不是准.后来我负责去给客户实施,
在客户处,得知了惊人的消息:客户需要的足够好的软件其实就是一个新闻发布功能的
东西,因为他们也不懂,是领导的要求---领导当然也是被上层领导要求.这个例子虽然
特殊,但是也说明了一定要及早知道客户心中的足够好的软件是什么.
你的知识资产
关于学习的一个章节,提到了不少如何学习,把学习知识作为投资一样看待,分析的也
很在理.自认为在这方面还是赶上了书中的要求,不然也不会看到这本书了^_^,学习是
一个过程,不会有立杆见影的效果,当然我们不是政客,不需要立马可见的政绩,那么种
种树又何妨呢?学习也要有实践,把学到的知识找机会就应用起来,起码,自己没用到,也
可以看看别人怎么用嘛.学的多了自然有了自己的判断,前两天不小心点开了jdk源码当
中关于Arrays.sort方法的实现.看到内部的合并排序法却不如《算法导论》中描述的
那么简洁,那么具有可读性,这时候,有了判断了,就不至于傻乎乎的研究它的写法,当然
,jdk里面的mergesort又有一些额外的处理(小数组优化),这个又是可以学习的地方.对
了,这一小节里面还有一段关于如何获得答案的方法,和国内论坛风靡一时的《提问的
智慧》一文有多处相似之处,不知道作者是否参考了本书.
交流
这个不用说就知道重要了.离开上一家公司最后一个项目就是最好的例子,一开始其
他同事从客户处带回来老系统的截图以及一些需求的说明,然后我们就要按照这些支离
破碎的东西进行开发.我们不是先知,不是某些领导人,可以自由的发挥,于是绞尽脑汁,
开始努力向可以吻合的方向发展,这种日子很不好受,直到我可以与客户联系上以后,直
接的面对面的确认客户的需求(又是需求) 才让项目的进展在几天里面比前面一个月都
要好的多.
原文：https://www.cnblogs.com/zql98/p/10959115.html