缘起宇轩阁

第1章焦油坑史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目

画蛇添足就过分设计，而书中很明确的指出了过分设计往往出现在设计和开发第二个系统的时候，对于第一个系统他们小心谨慎，倾向于精炼和简洁，但是到了第二个系统他们太想去追求完美，又加上盲目的自信，再加上没有太多的成本和进度等意识，导致了画蛇添足和过分设计。结构师如何避免画蛇添足——开发第二个系统所引起的后果（second-system effect）？是的，他无法跳过二次系统。但他可以有意识关注那些系统的

削足适履-关注程序的空间规模和空间控制技能削足适履这个章节在讲什么？我们很多时候在开发程序的时候都是考虑程序的运行时间和效率，而很少考虑到程序的运行空间问题。现在的存储空间是越来越廉价，我们很少去考虑这些问题。经典的DOS版本的仙剑奇侠传还不到20M，而现在的一个大游戏却是2,3G甚至更大。由于计算机的不断更新换代和性能的提升，我们不是特别去强调空间问题，而对于一些操作系统的底层程序我们仍然会强调

1.未雨绸缪不变只是愿望，变化才是永恒。-  SWIFT 普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。 - 富兰克林 D. 罗斯福 为之于未有，始之于未然。 －《道德经》  未雨绸缪这章我开始还原来一直记成了是讲风险，但是仔细阅读后发现主要讲如何快速适应变化。在敏捷软件开放中我们强调通过迭代和快速交互等各种方法来适应变化

设计模式的原则 1、"开－闭"原则——模块应对扩展开放，而对修改关闭。 2、里氏代换原则——如果调用的是父类的话，那么换成子类也完全可以运行。里氏代换原则是继承复用的一个基础。 3、合成复用原则——要少用继承，多用合成关系来实现。 4、依赖倒转原则——抽象不应该依赖与细节，细节应当依赖与抽象。                    要针对接口编程，而不是针对实现编程。 5、接口隔离原则——每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都

1敏捷软件宣言我们正在通过亲身实践和帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：1)  个体和交互 胜过 过程和工具。2)  可以工作的软件 胜过 面面俱到的文档。3)  客户合作 胜过 合同谈判。4)  响应变化 胜过 遵循计划。虽然右项具有价值，但我们认为左项更具有价值。 2敏捷宣言遵循的原则1)  我们最优先做到的是通过尽早的努力、持续交

当你能够度量你所说的，并且能够用数字去表达它时，就表示你理解了它；若你不能度量它，不能用数字表达它，那么说明你的知识是匮乏的、不能令人满意的——凯尔文勋爵（英国物理学家）★SLS：看来“可度量”并不仅仅是软件工程重视的要素。所有科学的一个基本要求之一就是可度量。下面的内容是对极限编程中计划游戏的内容的描述。其他敏捷方法都没有XP描述如何做计划详细。★3.1初始探索项目开始会尽力

作为开发人员，我们应该记住，XP并非唯一选择。——Pete MaBreen★2.1极限编程实践极限编程(eXtreme Programming)是敏捷方法中著名的一个。由一系列相互依赖的实践组成。★2.1.1客户作为团队成员XP中客户的定义：定义产品特性并排列这些特性优先级的人或团体。可能是统一家公司的业务分析师和市场专家，或者用户团体代表，或者支付开发费用的人。客户与开发

设计和编程都是人的活动，忘记这一点将失去一切。——Bjarme StrousStup本章是一次结对编程(pair programming)，编写保龄球比赛记分软件的例子。在这个过程中代码、逻辑、设计、需求都出现过错误，但最后出现了次序。★6.1保龄球比赛 66页对谈话和代码的总结：1.确定验证测试用例。2.画出UML类图。3.精简合并类图。4.先用最简单的设计，

人与人之间的交互是复杂的，并且其效果都是难以预料的，但确实工作中最为重要的方面。——《人件》第五页原则(principle)、模式(pattern)、实践(practice)都是重要的，但使其发挥作用的是人。“过程和方法对于项目的结果只有次要影响，首要影响是人”——Alistair Cockburm。如果把程序员团队看作是由过程驱动的组件所组成的系统，那么就无法对其进行管理。人不是“插

烈火验真金，逆境磨意志——卢修斯?塞尼加编写单元测试是一种验证行为，更是设计行为，更是编写文档行为。避免了反馈循环。★4.1测试驱动的开发方法设计程序先编写测试方案，单元测试是检验程序功能的唯一标准，不多加一个功能、不增加一行代码。包罗万象的单元测试的好处：1.每项功能都有测试来验证其正确性。2.迫使我们从调用者的角度思考。3.迫使我们把程序编写为可测试的，易于调用的，和周边环境解

这章开头以教堂来说明概念完整性，所以先学习下法国兰斯大教堂:这是一座从公元13世纪便动手修建的教堂。在其3段式构造的教堂正面，高高矗立着2座左右对称的尖塔。每当夕阳西下时，整座教堂便沐浴在金黄色的光辉之中。遍布教堂外墙的花纹及雕像也非常美丽动人。特别是正面中央大门右侧的四尊立像，更是哥特式建筑鼎盛时期的杰作。此外，仍然是正面部分的作品《微笑的天使》、《玛丽亚的侍从》、《圣约瑟夫》等，也全都是优秀作

在开发小组中，最好和最查人员生产率比在10:1，在运行效率和空间上5:1惊人差距。如果一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。对于一个软件项目，适合的项目团队规模在20人左右，这是一个专职的IT项目经理可以管理的最大值。那由于项目进度压力需要增加团队规模到100人的时候，让项目经理来开发实际操作是很困难的方式，在这里

20世纪最后一年也就是1999年的图灵奖，授予了年已69岁的资深计算机科学家布鲁克斯(Frederick Phillips Brooks, Jr.)。布鲁克斯这个名字在中国知之者不多，但在美国却是大名鼎鼎。因为他在60年代初只有29岁时就主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作，取得辉煌成功，从而名噪一时。以后他作为硬件和软件的双重专家和出色的教育家始

岸上的船儿，如何海上的灯塔，无法移动。 - 荷兰谚语焦油坑的意思说明了即使你足够强大，也无法摆脱束搏而沉到坑底。IT项目也是这样，不论是开发大型软件系统还是小型项目，都会遇到诸多复杂的问题和影响因素，项目本身就是一个足够复杂的动态系统，没有最优，只有满意。项目四要素，人员，组织环境，干系人，外部依赖和约束，风险和假设，团队，人等诸多问题都是你必须要考虑的问题，任何一个要素出现大的差错都可能导致项目

实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。这个章节标题是胸有成竹，而要做到胸有成竹就必须在项目计划阶段我们对项目的预测和估算都需要很准确。因此整个章节的内容就是在讲估算，而估算就涉及到预测和估算模型，估算要做到准确必须通过前期多个历史项目和版本的积累，同时通过历史版本和数据的积累来发现预测指标Y和相应的估算因子X之间的关系。这样建立出来的估算模型就可以提供我们的估算准确性。最早

我们要谈贯彻执行和提供执行力首先要要考虑纪律，在《专业主义》里面提到过，要想成为专家，有一个重点就是具有永不厌倦的好奇心和进取心，严格遵守纪律。历史上伟大和卓越的企业都有一个共同的特征就是严格遵守纪律和强大的执行力。无论如何完善教育制度，如何增加报酬和改善福利，也不会产生大批的专家。只有纪律——或许称之为价值观更准确些，才能培养出专家。在郝明义的《工作DNA》里面也曾经谈到过，人在职场的基本功即是

据《创世纪》记载，巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，但巴比伦塔同时也是第一个彻底失败的工程。为何拥有了清晰的目标，充足的人力和物力资源的项目最后仍然失败，巴比伦塔给我们的管理教训就是它们缺乏沟通和交流，以及交流的结果-组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。

1.整体部分(部分如何高质量的集成为一个整体)根据英文内容这里最好应该翻译为整体和部分。为了得到整体的可运行和高质量的软件，我们需要在哪些方面进行改进和下功夫。这章主要从消除Bug的设计，构件单元测试和系统集成调试三个方面来谈。之所以谈消除Bug的设计，就让我们更加意识到质量是设计出来的，而不是测试出来的。V.A.Vyssotsky 提出许许多多的失败完全源于那些产品未精确定义的地方。这要求我们在

最后一章仍然在讲文档和文档有效性的问题。在开始就指出，我曾经非常勤奋地给我的软件工程师们举办了多年关于文档必要性以及优秀文档所应具备特点方面的讲座，向他们讲述——甚至是热诚地向他们劝诫以上的观点。不过，这些都行不通。我想他们知道如何正确地编写文档，却缺乏工作的热情。所以这章重点仍然放在了如何写文档，文档应该包含哪些核心要素上面。不同用户需要不同级别的文档。某些用户仅仅偶尔使用程序，有些用户必须依赖

没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。-没有银弹一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。这些要素本身是抽象的，体现在相同的概念构架中，可以存在不同的表现形式。尽管如此，它仍然是内容丰富和高度精确的。我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念

作者介绍:20世纪最后一年也就是1999年的图灵奖，授予了年已69岁的资深计算机科学家布鲁克斯(Frederick Phillips Brooks, Jr.)。布鲁克斯这个名字在中国知之者不多，但在美国却是大名鼎鼎。因为他在60年代初只有29岁时就主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作，取得辉煌成功，从而名噪一时。以后他作为硬件和软件的双重专家和出色

向进度落后的项目中增加人手，只会使进度更加落后。 -Brooks法则人月的启示 进度问题是IT项目管理最为关注的问题之一，到了第二章人月神话开始讲进度问题。进度的可保证性和可控制性来源于项目计划的科学性，项目计划对进度预测的准确性又来源于估算的准确性，估算是否准确又涉及到项目规模，根据规模可以得到工作量，根据工作量和人

大千世界中，唯一缺乏的就是人的注意力。————凯文凯利阐述人们应该关注手边的工作，并说明使事务能够工作和事务正确之间的区别。重构的定义：在不改变代码行为的情况下对代码进行修改，以改进代码行为的过程。为什么要违反谚语“没有坏就不要修理她”软件模块职责：1。完成功能。2.易修改、易维护。3.易读。要做到易修改和易读，需要原则和模式，还有你的注意力、纪律约束和创造美的激情。★