注重实效的途径
2.1 重复的危害
1. DRY: 系统中的每一项知识都是必须具有单一、无歧义、权威的表示
DRY: Do not repeat yourself
2. 文档与代码:你撰写文档,然后编写代码。有些东西变了,你修订文档、更新代码。文档和代码都含有统一知识的表达
2.2 正交性
1. 正交性:如果两个或更多事物中的一个发生变化,不会影响其他事物,这些事物就是正交的。在设计良好的系统中,数据库代码与用户界面代码是正交的;你可以改动界面,而不影响数据库;更换数据库,而不用改动界面
2.3 可撤销性
1. 要把决策视为是写在沙滩上的,而不是把它们刻在石头上。大浪随时可能到来,把它们抹去
2. 不存在最终决策
2.5 曳光弹
1. 曳光弹:
(1) 定义: 曳光弹是一种"原型制作" 。曳光弹代码虽然简约,但是完整的,并且构成最终系统的骨架的一部分;"原型制作"是用来生成用过就扔的代码。
(2) 曳光弹并非用过就扔的代码;你编写它,是为了保留它。它含有任何一段产品代码都拥有的完整的错误检查、结构、文档、以及自查。它只不过功能不全而已。但是,一旦你在系统的各组件间实现了端到端(end-to-end)的连接,你就可以检查你离目标还有多远,并在必要的情况下进行调整。一旦你完全瞄准了,增加功能将是一件容易的事情
(3) 优点: a. 用户能够及早看到能工作的东西; b. 开发者构建了一个他们能在其中工作的结构; c. 你有一个集成平台;d. 你有了可用于演示的东西; e. 你将更能够感受到工作进展
(4) 曳光弹并非总能击中目标。但是,小段代码的惯性小,要改变它更容易、更迅速;你能够搜集关于你的应用的反馈,而且与其他方法相比,你能够花费较少代价、更为迅速地生成新的、更为准确的版本
2.6 领域语言
2.7 估算
时长 报出估算的单位
1~15天 天
3~8周 周
8~30周 月
30+周 在给出估算前努力思考一下
估算来自哪里:去问已经做过这件事情的人;在你一头钻进建模之前,仔细在周围找找也曾处在类似情况的人
理解提问内容:需要把握问题域的范围;需要养成在开始猜想之前,先思考范围的习惯
建立系统的模型:
将模型分解为组件:
给每个参数指定值:
计算答案:在计算阶段,你可能会得到看起来很奇怪的答案。不要太快放弃它们。如果你的运算是正确的,那你对问题或模型的理解就很可能是错的。这是很宝贵的信息
追踪你的估算能力:如果结果证明估算错了,不要只是耸耸肩走开。找出事情为何与你的猜想不同的原因。也许你选择了与问题的实际情况不符的一些参数。也许你的模型是错的。不管原因是什么,花一点实际揭开所发生的事情。如果你这样做了,你的下一次估算就会更好
在被要求进行估算时说什么:你说:"我等会回答你"。需要放慢估算的速度,花一点时间检查&思考