本书主线是一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件Chandler，后来花了七年时间才完成这一创举，但是已经落后时代太久。
我的理解，时间脱了这么久的原因就是，这群大牛讨论了很多细节，而没有付诸实践，他们太专注于细节了，想要保证一次性开发出完美的软件，就像我不经意间就会追求代码做到完美，导致软工程序写出来后完全符合BOSS(民哥)的要求，不过，讽刺的是，需求是他随便想出来的。所以被坑过的我决定痛定思痛，痛改前非，总之就是很痛，在软件中做到规定的时间完成规定的事儿，至于做成什么玩意儿就不考虑了，反正我把技术交在那了，回头有时间再精细加工呗。
咳咳，扯远了。这本书的支线就是很多软件工程中的名词，概念的解释，作者很巧妙地自然过渡，读起来不是很费力，也很有乐趣。
背景是卡普尔这个人，他创建了莲花公司，公司很成功，每年给他赚几百万美元的利益。但这与他的价值观不服，于是他“功成身退”，然后就去搞Chandler了。
喷：以写作为生的跟以编程为生的就是不一样，还是前者写的书更招我们读者喜欢。
接下来是对我有用的名词的解释。
我觉得这本书最重要的是里面的一个个故事，大故事下的小故事，这叫“以史为镜可以明得失”，可让我闲的没事儿写自己看过的不知道忘没忘记的故事，我欠你的？
第0章 软件时间
心流：
你沉浸在一行行代码的逻辑中无法自拔，以至于过去了很长时间而你浑然未觉。
我们在写一篇很长的代码或者在用算法优化某个函数的时候，会进入这种状态。
当然，对于我来说，像进入这种状态无比简单----随便打开个动作类游戏即可。
没有银弹：
在现代软件研究领域多有建树的专家弗里德里克·布鲁克斯在1987 年写了一篇题为没有银弹(No Silver Bullet )的著名论文。
文章把软件比作当时人们最害怕的精怪---狼人，而银弹可以杀死狼人。
很遗憾，作者对存在杀死软件制作困难这个狼人的银弹持否定态度。
第1章 死定了[2003年7月]
讨论软件进度：
进度忽而突飞猛进，忽而不知何故驻足道中。在你以为大功即将告成之时，却又山穷水尽， 花上整半年时间，一无所得。
第2章 Agenda之魂[1968～2001年]
布鲁克斯法则：
最理想的开发组规模是一个人----无须停下工作与同事沟通的单个开发者。
提靴带：
初次启动计算机时，内存是空的。这就造成了鸡与蛋的悖论：计算机硬件需要操作系统软件来装载程序——包括操作系统本身。计算机系统发明者们通过一个叫做"bootstrap loader (靴带装载者，引导程序）”的小程序让机器具备刚好足够把大操作系统装入内存的能力，开始正常运行。
第3章 原型与Python[2001～2002年11月]
python是解释型语言，科普了python的优缺点
电梯游说：
就是当你有幸在电梯间遇到某位权钱人士时，能脱口而出，在短时间内说服他。
第4章 乐高王国[2002年11月～2003年8月]
乐高假设：
未来程序将由可复用的部件组合而成。部件将在全球范围内提供。
做好项目的关键在于复用，而不是重复发明。
第5章 管束奇客和狗[2003年4月～8月]
质量三角：
既好、又快、还便宜，同时满足的事情不太可能发生。好像书上说的是最多满足两个。
奇客：
编程能力很强，但与人交往能力差的要命的人。
奇拗：
沉浸到细节中直到变态境界。
（愿意刨析底层代码不是一种优良的品质吗？）
第6章 完成设计方案[2003年7月～11月]
关于Linux的作者李纳斯托瓦茨的一段原话：
别做大项目。从小项目开始，而且永远不要期望它变大。
如果这么想（指做大型软件），就会做过度设计，把它想象行过于重要。
更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。
所以要从小处起步，着力考虑细节。别去想大图景和好设计。
如果项目没解决某些需求，多半就是被过度设计了。
（很有道理！）
第7章 细节视图[2004年1月～5月]
“吃你自己的狗食”：
比尔盖茨提出，意思是开发者必须使用自己正在做的产品。
第8章 白板上的即时贴[2004年6月～10月]
第9章 方法
瀑布模型:
将项目切分为依序进行的多个独立阶段，比如需求定义、设计、实现、集成、测试和发布。每个阶段需在下一阶段开始前完成。
这套做法在纸上看似合乎逻辑，但实践起来却总是导致延误、混乱和灾难。每个阶段都耗时无算，但没一个工作正常的。
（深受其害的我强烈认同这句话）
螺旋模型：
将开发切割为六个月到两年的“迭代周期”——更快生产出可工作代码的小瀑布，从部分完成的产品使用中得到反馈、指导下一步迭代。
（对，这也是我们需要采用的编程方法）
第10章 工程师和艺术家
写软件是门艺术？你要是这么想我也无话可说。
第11章 通往狗食版之路[2004年11月～2005年11月]
尾声 长赌[2005～2029年及以后]