第一章：注重时效的哲学

第一节：我的代码让猫给吃了

在做项目的过程中，我们每个人难免会犯错。对于这类错误，单单一句“我的代码让猫吃了”，是远不能解决的。这时候需要自己主动承担这份责任，主动承认错误。并且在最快的时间内提供解决方案，尽可能地挽回局面。

第二节：软件的熵

熵是一个热力学概念，指的是在某个系统中的“无序”的总量，热力学定律指出宇宙中的熵总是倾向于最大化。软件工程里中也存在这么一个定律，工程越庞大，代码的“无序”状态越严重。

根据破窗效应，项目的腐烂并不是突然发生的，而是由一个小的漏洞引起的，另一个人接手之后，并不会修复它，还会在原来的基础上进行破坏。对于这类问题的解决，是在发现漏洞伊始，便召集团队进行修复。毕竟，一个优美的景区，谁也不愿意把它弄脏的。

第三节：石头汤和煮青蛙

石头汤和温水煮青蛙的故事都是听过的。

有时候，我们不需要要求别人如何办事，我们只需要将项目设计好，将小的成品展示给大家，然后向其他成员提出需求（前提是你的项目足够吸引人），将所有人拉到自己的身边。做团队的催化剂，实现共赢；同时，我们需要时刻关注周围的变化，并且利用这种变化，将团队的“蛋糕”做大。

第四节：足够好的软件

现实生活中，我们往往不能保证产品的质量。所以指定需求时，把质量这一块考虑进去，在商定的时间内，由产品或者客户决定他们可以接受的质量是什么样的。

没有完美的软件，应该知道何时止步。今天了不起质量高的软件往往是由用户决定的，开发人员仅需要尽可能满足用户的需求，及早让客户使用，他们的反馈常会把你引向更好的解决方案。

第五节：你的知识资产

本杰明·富兰克林说过：知识上的投资总能得到最好的回报。这没问题，但遗憾的是知识是有时效的资产，特别是计算机领域。我们可以把我们了解的技术实现、工作经验视为知识资产，并使用管理金融资产的形式管理这些知识。

经营知识资产可以从以下方面进行：

定期投资：定期投入时间学习，即使很小的投资也是很重要的。

多元化：作为底线我们需要对当前所从事的技术熟练掌握。但不要就此止步，技术的发展 变化很快，掌握的知识越多，就越能更好的进行调整，赶上变化。

管理风险：不要把所有的“技术鸡蛋”放到一个篮子里。

低买高卖：新技术流行之前就掌握它往往比之后跟风再学得到更大的回报。

第六节：交流

在一个有效的交流中，我们可以得到许多信息，从而升华自己的项目。

一个真正有效的交流，发言者必须知道自己在说什么，了解自己的听众。信息紊乱以及不了解听众，无法将自己的项目表达清楚，听众也只会做做样子。

同时，发言的时机也很重要，选择合适的时机能让你的发言事半功倍。

在介绍自己的文档时，让其保持优美，直观准确的表达自己的观点。

在做发言者的同时，也要学会做倾听者，让观众参与到你的项目。

第二章：注重时效的途径

第七节：重复的危害

强加的重复：开发者觉得他们无可选择，其实是有一些方法让我们避免重复的

无意的重复：设计中的错误，开发者并没有意识到自己的错误，需要提高代码意识。

无耐性的重复：在时间压力之下，开发者进行偷懒。

开发者之间的重复：众多开发者使用同意公共区域，进行了多次重复，主要缺少交流。

第八节：正交性

正交性是一个从几何学中借鉴而来的术语，如果两条直线相交成直角，他们就是正交的。这在向量中的解释是沿着一条直线移动，你投影到另一条直线上的位置不变。

正交的好处是它提高生产效率，各个组件不相互依赖，使得改变得以局部化，促进复用，对于正交组件进行组合也可以提高生产效率，同时它还降低了代码的风险。

延伸开来，项目团队的配合也应该遵循正交性。如果成员之间任务重叠较多容易让大家疑惑问题和责任的归属如何划分，这会造成配合的效率低下。

第九节：可撤销性

如果某个想法是你唯一的想法，那再没有比这更危险的事情了。

在开发过程中，保持代码的灵活性，为随时出现的错误做准备，构建一个灵活的框架，让代码能够“摇滚”。

第十节：曳光弹

聪明的程序员往往使用曳光弹。

在黑暗中发光的代码——曳光代码，适合不熟悉的项目。使用曳光代码，保留了完整的错误检查，只不过功能不全而已。它有以下优点：

用户能够及早的看到能工作的东西。

开发者构建了一个能在其中工作的结构。

你有了可用于演示的东西。

你能共感觉到工作的进展。

第十一节：原型与便签

制作原型是一种学习经验，其价值不在于产生代码，而在于从其中所得到的经验教训。

使用原型可以忽略细节：正确性、完整性、健壮性、风格。

制作原型不需要编码，只需要实现逻辑模型。制作原型时需要考虑以下问题：

·主要组件的责任是否得到了良好定义？是否恰当？

·主要组件间的协作是否得到了良好的定义？

·耦合是否得以最小化？

·你能否克服确认重复的潜在来源？

·接口定义和各项约束是否可接受？

第十二节：领域语言

计算机语言会影响你思考问题的方式，以及你看待交流的方式。

无论用于控制和配置应用程序的简单语言，还是用于制定规则或过程的更为复杂的语言，你都应该考虑让你的项目更接近问题领域。

易于开发还是易于维护，决定了采用哪种语言。

第十三节：估算

估算，以避免发生意外。

在估算的过程中，你将会加深对你的程序所处的世界的理解。

多准确才足够准确？130 个工作日和大概 6 个月，是不同的，显然，前者表示的精度更高。我们在做估算的时候也需要选好描述估算时间的单位值。

估算结果怎么来呢。

首先需要确认你是否理解了需求所涉及的各个方面，这个是前置条件。

然后你需要建立系统模型，在这个系统中，把模型分拆成各个组件，然后给每个参数设置定一个值，最后根据模型计算一个时间。

模型应该是一个动态的，它像一个人工智能模型，你需要持续不断的训练它，才能使它真正准确起来。每次的估算都需要记录，反思估算效果，找出影响因素，加入新的影响项或者调整对应参数。

被要求进行估算时间时，我们可以这样回答：我等会儿回答你。然后花点时间仔细检查我们在这一节描述的步骤，你总能得到更好的结果。