本文将读过的《观止-微软创建NT和未来的夺命狂奔》这本书中一些觉得经典的语句摘抄下来，供以后借鉴：

经典摘要

• 软件不仅是智慧的结晶，也是信仰、尊严和魅力的代名词。

• 好的技术不一定都能换成钱。不能换成钱的技术，不是成为别人去买的技术，就是成为历史。

• 在行业外的人看来，编写软件的人，特别是所谓的高手，大多有些古怪之处。

• 开发软件不是一件简单的事，分析需求、定义功能、设计架构、编写代码、测试集成……每个环节都不容易做。但难度最大的，最难以控制进度的，其难度又经常被低估的，即时定位和去除臭虫，也就是所谓的软件调试。

• 把打造NT的过程比喻成一场“戏”；一场虽没有刀光剑影，但也绝对堪称紧张激烈的戏；异常发生在高科技领域，但也处处彰显人性光芒的戏；一场有欢乐，也有悲伤的戏；一场让人拍手叫绝的戏……

• 小的失误积累起来一定会拖延进度，而开发团队的负责人要努力推动项目前进。

• 软件将个人电脑变成了一个精密的思考工具，帮助个人或组织控制最有价值的资产：信息。

• 编写优秀的代码逐渐成为了大团队的工作。然而这样的团队经常沦为平庸，因为单就其大小就足以滋生官僚主义和缺乏创新。每个大的团队都将面临这样的挑战：在组织好那些才华横溢的成员的同时，又要鼓励领导能力和灵活性。

• 工作就是他们的全部。朋友退居幕后；婚姻紧张甚至破裂；孩子们被忽视，或者推迟生孩子的计划；业余爱好也没有了。计算机代码意味着一切。如果还能照顾到什么个人的梦想，那也只是为了减轻创造软件的痛苦。

• 伟大的成就在阴冷的背景下出现。把懒散、困惑、没有竞争力视为敌人。

• 我们只有一件事情需要关心——交付这个产品，并且尽己所能做到最好。

• 每一个有价值的创造都交织着爱和*。

第一章 代码勇士

• cutler对自己的前途很有把握，在他体内的某个地方生长着被傲慢包裹着的信心和一种信念，他相信他无论干什么都能成为最棒的。

• 编程“是最奇怪的事情，因为你过去习惯了做一些事情，而且你觉得你做的是对的”，cutler说：“但实际上错了。你只是没有注意到它是不对的。电脑对差不多正确是没有一点宽慰和原谅的，差不多就意味着你还是错的。”

• 最大的前进障碍会来自程序员自己。就像转变到一种新的宗教信仰一样，他们经常表现出思想保守，掩盖了他们的*。“程序员是非常古怪的一个群体！”

• cutler是一流的程序员。他全身心地投入，沉迷其中，争强好斗。他有非常坚强的意志和信心。他投入非常大的精力来注意细节。而且，他在设计和编写代码时不断地追求更好。cutler会从自己的成功中学习。下一次，他会做的更好。so,每一次他都上升到一个新的高度。

• cutler喜欢奚落他的伙计们，但是为了改善他们的代码质量，他会不遗余力。他要求他的团队要绝对诚实。“当你做过头或犯错误时，他会立刻批评你”

• 平庸是留给弱者的，要成就伟大就要有意愿去打破荒谬或者突破传统（而且不管什么后果）。

• “首先，质量是每个人都必须坚信的东西，”cutler写道，“这意味着要管理到所有层面，从上面到最下面的工人。不给那些总是顺着市场部门的方向倒的无能经理们留一点空间。也不给工程师们留空间去通过降低质量伪装做了更多的工作。要站起来对质量问题说不，有时需要勇气，不过我项目里的所有人都拿到了这样的许可。如果某个地方的某个笨蛋想要发布没有准备好的软件，那我们会告诉他滚蛋！”

第二章 代码之王

• “运行你的程序是一个绝对的考验，”盖茨说：“你写一个程序，运行它，测试它是否能工作。”

• 盖茨，他会经常坐在他的房间里设想他的未来，“像哲学家似的，一个抑郁的家伙，总在琢磨我应该怎样对待我的人生。”

• 盖茨，“如果可能，你朝我大脑里面看看，它其实充满着关于技术的想法。”

• 盖茨的检验标准是不固定的：他掌握了在对的时间改变风向的窍门。这个世界上，人们往往之抱住一个坚定信念不放，但盖茨不会墨守成规。然而，他也会情绪化和感到焦虑，有时候甚至是个妄想狂。他会想象失败的下场，也幻想他被敌人包围的场景。这些想法使盖茨“害怕地奔跑”，不过他认为这是有力的条件。“自满是毁灭之路，”他说，“你必须要一直想谁将取代你。”

• “所有的东西都在急转直下”。

• 对于管理，盖茨有一个简单的方法：让你周围都是极富智慧的人。“聪明人，”他说，“是掌握充分事实后，能推算出所有可能性的那种人。”

• cutler在修正罗伯。索特的作业，索特突然笑起来，“他就是在玩我的家庭作业，”索特说，“这太搞笑了。”

• “戴夫的领导风格是他自己做大量的工作，也促使其他人做大量的工作，”索特说，“有意思的是，真的很复杂的技术活也不能让他慢下一点点。不管有多复杂，他总是用同样的速度进行。”

• cutler他不喜欢考虑精神生活的阴暗面。

• 软件业优秀的两大传统精神：自视清高，超然出世，厌恶商业伎俩；却又是实用主义者，坚持“想就去做”的观点，同时也是很聪明的自学型人才。

• “好设计不可能出自委员会（“委员会设计”指很多人同时进行设计，却没有统一的看法）”

• 许多程序员的工作方式是步进式的，通过多个版本来逐步完善一段代码。每个版本都为他们的想象和推理扮演者堡垒的角色。cutler则相反，他在开写之前，现在头脑里形成代码图，然后再高精确度的写下代码。“我不是那种尽可能快的写出代码，然后再一遍又一遍地修改的那种人。”他还说，“另一方面，我不怕重写任何东西。如果它的结果并不是我想要的，我不怕全部推翻，重新来写。”

• 对于编程，cutler是个实用主义者。他相信形式优先于功能，但他也不是完全屈从于结构。

• 皮亚佐利的管理哲学很简单：让你的人们快乐。

• “出货”也许是衡量程序员的生产成果的唯一真实的标尺。“如果你没完成，”cutler说，“所有绝妙的好点子都无任何意义。”

• 可移植性、可靠性、个性化

• cutler传达的信息也总是生硬而简洁明了。“我希望每个人都做到他们自己的最好——一直如此。”

• “如果你有位父亲说你已经做得很好，你就不用一直去证明它了，但是戴夫不停地证明给他父亲看。”

• 工作中，cutler可以在一眨眼的工夫从笑脸菩萨变成一头怒狮。他不喜欢吊儿郎当，建议办公室里禁止娱乐。他从不考虑别人的感受。他并不是故意想让所有人都感觉很糟，而是希望工作时别去顾忌情绪问题。

• 技术争论既是实验室里的福音，又是祸根。工程和发明总是用不同的方法得到同样的结果。关于技术的恳切争吵在所有的技术公司都很常见。

• cutler给他的部落成员们以生活的目的，在某种程度上，他像一个天生的*一样振奋起他们的精神。他浑身散发的自信力，能使他的追随者们感觉到事物都是正确的和好的。

第四章 死胡同

• 芯片的选择十分关键：这二者之间的关系就好比赛马和骑手间的关系那样密切。不管骑手的技艺多么精湛，他也不能把一匹耕马变成优等纯种良马。芯片和软件间的关系同样如此。

• 有人这样说不死队的风格：“他们把自己想象成为男巫，而不是科学家。男巫意味着阴暗和神秘。他们不把世俗的成功象征当回事——金钱、地位、女人对他们来说不值一提。这些家伙是那种坐在计算机科学实验室最后一排的人，他们的成绩很糟糕，但也许是故意的。他们通常并不广博，但是在某一方面很出色。而且他们不喜欢解释自己。”

• “可能你除掉了不好的东西，”马瑞兹说，“但是你可能会把好的东西也搞糟。”

• “要么你达到了这个里程碑，要么没有。你不能拿牛粪来糊弄。”

• 典型的微软帮，包括比尔。盖茨，都模模糊糊的有种反叛性格，他们自我感觉良好，经常异想天开，而且漠视等级差异。

• 测试很辛苦，而且是做软件开发的幕后英雄。但唐尼坚信测试“尽管不如制造产品那么光彩夺目”，但是很多时候却决定着一个程序的命运。

• 在测试一个程序时，没有万无一失的方法，这使测试员们都很谦卑。

• 一种偏见的观念：测试员们乐于作弄程序，让其看起来很糟糕。测试员们不同意这种说法，他们觉得他们不会故意让任何人难堪，但是事实上这是真的，正如一个测试员所说的：“我们的目标就是把一个程序搞死——要使其产生个灾难性的问题。”

• 如果编写代码的人把自己看成高明的手工艺人，那么测试员把自己看做是劫匪，四处寻找代码中的弱点，然后残忍的利用它们为自己添光加彩。最有力的测试技术并不复杂：向程序施加压力直到它完蛋。

• 工作是对抗忧虑的解毒剂。

• 布特兹说：“没有人临死的时候还希望应该多花些时间在工作上。”

• 在微软，项目经理帮助定义产品，尽管他们不写代码。项目经理可以雇佣合同工来编写他们想要的代码。理想情况下，项目经理是来自于市场的使者。当代码编写者集中精力去完成项目经理定义的产品时，项目经理会研究竞争对手的产品，从竞争者那里收集产品的亮点，并从潜在用户那里征求建议。如果一种产品上市时缺少客户喜爱的功能，那么项目经理需要解释为什么没有包含这样的功能。有时，他们缺少技术或者其他方面的判断力，但是他们至少可以让程序员们对他们的目标做出裁定。

第五章 嗥叫的熊

• 一个果敢的决策。NT和Windows “结婚”。关键时刻的策略改变！

• 这个从来没想过拥有一个帝国的人正在得到一个帝国。马瑞兹感到这是抑制cutler总是“向旁边所有人撒尿”的唯一方法。“我知道那是唯一可行的方法。否则想调节cutler和其他部门领导间的争端几乎是不可能的。”

• “我们主要雇佣那些必须限制他们工作的人，而不是催促他们工作的人。”一个老员工说。

• 拉科夫斯基比伍德更加挑剔，但他们有很多共同点：做事情非常专注，能够快速编写大量的代码，对过多的文档极度厌恶，以及近乎狂妄的自信。

• 盖茨有一种理念，只有扎实的程序员才能当经理，所有程序员的经理们都应该坚持写代码。很多软件公司的通病是他们的经理成了手下程序员的俘虏，而微软的做法对这个问题是很好的解药。

• 无法赶上进度安排，产品失败，预算被消减——所有的问题都源于上层的人从来都搞不清楚他们的人才在干些什么。

• 更多的控制并不是办法。“看起来稍加管理还是必要的，”皮亚佐利说，“然而你永远无法做到只管一点点，你总是管得太多。而没有足够的管理则是个非常不稳定的状态。然而想要成功你一定要管理到位。”

• cutler相信是金子总会发光的，而突出的才干最容易在人数较少的小团队中显示出来。

• 每个开发组有一两个资深程序员，称为架构师，他们负责设计重大的程序模块。这样做的思路是越少的人参与模块设计，整体的一致性就越好。作为设计的蓝图，架构师的规格说明会交给一个或几个程序员进行开发。这里留有一定的灵活性：架构师有时候会亲自修改程序缺陷；开发人员偶尔也会去做设计。

• “我不是个循规蹈矩的人，”谈到对于复杂的规章制度的厌恶时，他说，“人们应该明白，操作流程是为了帮助完成工作的，而不是工作本身。”

• 戴蒙德对增加功能的请求十分小心，只有在放弃一个旧功能的时候才同意增加一个新功能。“我们可以做这个，但你要在别的地方付出代价”成了他的口头禅。

• “代码完成”的最后期限，团队对这个术语的定义是：过了这一天将不再增加新的功能，只能进行修正。

• 穆格利亚强调，计算机软件尽管一定是由程序员构思和创造出来的，但一定要反映当前的市场状况和客户需求。没有任何伟大的软件只是盲从市场的需求，或简单地实现消费者的想法。但创作者们生活在重重包围之中。技术上的要求使他们很难超越想象力的局限。

第六章 狗粮

• “知道如果你完全与世隔绝的做什么事情，就无法做到最好。你需要至少有人可以给你点反馈意见”

• “吃自己的狗粮”——使用自己开发的产品。程序员将有紧迫感去提高伙食水平，尽快修复错误的代码，从开始就编写更加耐用的程序。

• 对于复杂的程序来说，越早进行集成，越能尽早发现某些类型的程序缺陷。

• 作为原则性的问题，他希望构建尽快更新。构建来的越快，测试人员就能越早地开始对其进行测试，程序员就能越早的开始精炼代码。因为真正评价代码的唯一方法就是运行那些代码。

• cutler认为检入的代码质量是衡量一个程序员最真实的标准。他最生气的是有程序员在将代码提交给构建实验室之前不做测试。

• “如果因为你打断了构建，”cutler经常说，“你的屁股就是草坪，而我是割草机。”

• cutler每次听说要增加新功能都很愤怒。“那使他发疯，”一个密友说，“因为那使他无法按照承诺交付产品。根据经验，他知道如果加入更多的功能，就只能拖延进度，你假装没有影响是没用的。”

• “戴夫所做的第一件事就是清楚的告诉你实现目标非常重要。”

• “没人在乎你提问题，只要你已经认真研究过了，能够清楚地告诉别人你自己寻求答案的过程。”

第七章 交付模式

• “不，我们必须比这做得更好！”

• 绝大多数的用户有个共识：最重要的是保证一定程度上的隐私权，同时保证在组织内部的控制。

• 管理集体创作的软件非常困难。最理想的软件团队是由一个人组成的。“从一个人能掌控的程序到由四个五个或七个人完成的程序，它们之间存在一个巨大的跳跃。”霍恩想，“然后飞跃至一百个程序员编写的程序，这几乎是不可理解的。”

• 范。戴克把自己的才能看作一种可持续并有限的资源。一个人一天只能编这些代码。事与愿违的是，“当我增加工作时间时，我要花更多的时间来找到正确答案”。他与家人——他的妻子和孩子们——相处的时间也是他保持创造力的原因，他相信在生产力方面，有时候少即是多，解决问题需要稳步推进。他避免将工作和家庭放在对立面上。“我有多少时间微软就会用掉多少时间，”他说，为了保护自己，“你只能离开。工作了一天之后回家。”

• “我这里要求的不是火箭科学，但是你们应该感到惊讶，我们已经有多久没有做到这些了，”他接着说。然后他给出了很多正确步骤的示例，强调往最坏处考虑的益处：“如果你添加了新功能……要准备好它会失败。并且请确保如果我们在构建时出现问题，你可以撤销对系统的改变。这是非常重要的！我们即将冻结代码。如果有新代码检入，导致构建失败，通常要找到解决问题的办法都会是令人发疯的经历。”

• 逆水行舟，不进则退。

• 有时程序员在面对自己代码中的缺陷的时候会自我防御——总是带着足够的尊重。对测试人员来说，“如果你正确地对待他们，不会有任何问题”秘诀是：“做好准备。在你讨论细节问题以前，做足功课。”

• “系统太复杂，大多数的程序缺陷的代价远远超过单单程序员的宝贵时间，如果你不把它（程序缺陷）带进来，就不用费力去找它们，以及把它们清除掉了！”

第八章 死亡行军

• “如果cutler在构建实验室，那么程序员们就会意识到：‘我最好不要把*检入进去。’”这也反映了团队中的所有人都是平等的，只要它们辛苦地工作。cutler坚信，在小组中的威力“来自于你的成就”，而不是头衔和才能。

• “永远不要草率地删除安全拷贝。”

• “如果有人把*检入进来，那么我会打电话将他抓过来，把他嚼烂。”

• 用香农的话来说：“微软的理论是如果一个工作需要两个人去做，那么雇佣一个人。这是公司规定的政策。被称为N减一政策。”

• 编写软件是很耗时间的。很多工程师都低估了编程的难度，直到多年后他们才开始把它看作是最复杂的人类活动之一。

• 写代码是一个人就可以做的事，但是设计和把不同的片段整合到一起需要合作和协商。一个大的团队拆分成很多个小组，小组之间和小组内部的沟通需要大量的来来去去。电子邮件减少了费时间的面对面接触，但是却不能完全代替面对面的交谈。许多人在一起讨论对寻找和修正瑕疵这样的关键任务很有好处。

• 编写代码的人不能忍受频繁的打扰。即使是那些纪律性最强的人，他们也最多花一半时间来写代码，其余时间用来写笔记、问答题问、检查以前做的工作或者学习新的技能。

• 编程这样的事情天生就不适合自动化。

• “计算机是一个残忍而且吹毛求疵的批评家。”其他设计师的好坏是由同行来评定的，但是程序员的好坏最终是由机器来衡量的。

• 优秀的程序员善于抽象和通过符号来观察问题。

• 只看代码行数根本不能说明代码的质量。好的程序员抓住问题就绝不放松，一直向前推进寻找答案，即使干扰了其他快乐。不论他们的经验多少和竞争热情如何，他们都认可发现新奇事物的能力，他们倾向于把自己看做是艺术家而不是工匠。

• 对测试员来说，他们总是担心表面之下潜藏着祸患，尽其所能将所有隐藏的瑕疵暴露出来。他们唯一的防御策略就是：永远不要停止测试。

• “在疲倦的状态下工作不会有很高的效率。”有些人浪费时间或者不能很好地安排他们的时间。与一般的工程师一样，程序员们很容易被有趣但不相关的难题吸引而转移目标，脱离正规。

• 计算机本身可以对人类施加一种很强的占有力，提供了一种甜美的方式来取代人类的友谊。

• 现实世界中充满了模棱两可和冲突的观点，肯定的答案非常少，与此相比，计算机分离好（工作）、坏（工作）软件的能力让程序员们像被催眠了般的着迷。令人感到格外惊奇的是，创造程序——一种人类写给机器的消息——对一些人来说如此神圣。

• 如果老兵要花费时间来辅导新手，那么他们就无法保证自己的工作。等到了新手们学会了足够多的东西能真正帮上忙时，这个小组已经错过了最后期限。“这就好像是，”皮亚佐利说，“即使你再多给你的老婆两个人，她也不会在三个月内生出一个小孩。”

第九章 臭虫缠身

• 关键的问题是大小和性能。在衡量计算机软件的这对孪生指标中，每一个都可能产生“额外”的成本。很显然，没有人喜欢等待计算机做事情。

• 弗雷德。布鲁克斯在《The Mythical Man-Month》中写到，“在大多数项目中，构建出的第一个系统很少是可用的。他可能太慢、太大、难以使用或者这三个缺点都有。”

• cutler的观点是：“总是要先把事情做对，让其可靠，然后再顾及性能。一边向前走一边逐渐加入修饰和润色，这是我所喜欢的做法。”尽管这些话听起来有道理，但是cutler的原则回避了最关键的的时间问题。

• 多次延迟在杀伤团队的士气。

• 艾布拉斯有着超强的自学能力，喜欢完全靠自己来掌握某一领域的知识。他赞扬“思想灵活”的重要性，相信要成为一个编写代码的高手“主要是靠自学，而不是让别人教会自己”。尽管经验可以让人明智，但是某些思考习惯也起着非常重要的作用。“不要假定任何东西，我如何强调着一点都还觉得不够。”

• “对于某些问题，你坐在那里想是解决不了的，”艾布拉斯说，“四处走走，可能一个答案突然就闪现在你的脑海中。”

• “我们必须像戴夫那样。我们必须实干。我们不能只是空谈。我们必须把事情完成。”

• “这件事告诉我们如何解决问题。最不能接受的是人们都对着问题发牢骚，而不去找解决方法。”

• 用艾布拉斯的话来说：“优化速度的秘密是问自己，‘这个代码到底需要做什么？要解决这个问题我能做的最少的工作是什么？’”

• 在观念和风格方面的冲突会慢慢激发成为创新的源泉。因为程序员做设计时主要依赖逻辑和数学，所以他们在做技术决策时常常小看了人性的作用。使用一成不变的方法做出创造性的发明只是幻想。总是有很多种方法来达到大体相同的技术目标。技术方向的选择经常是与人相关的。尽管商业方面的考虑会影响技术决策，但是技术决策仍反映了人的价值观念和心理状态。

• 雷斯特解释他的方法背后的“关键思想”：事实上，你可以使用相对来说数量很少的基本抽象构建出一个系统。可以是那些抽象在一起工作。你可以构建出一个机器无关的（可移植的）系统而且不用支付性能方面的罚单。最后一点是，你可以依赖基本内核之上的代码层而不必像以前那样付出那么多代价。

• cutler还在进行另一场战斗，那就是反对那些在大型项目的改进阶段跑出来转移团队注意力的各种干扰。他必须分辨出哪些动作可以缓解压力，哪些只是浪费时间。如关于正确使用“who”和“whom”这两个单词。“不然我会冲破墙壁走过来。”

• “我们几乎就要到达彼岸了，”cutler告诉整个团队，“我们不能在这个时候放弃。”

第十章 观止

• 布鲁斯歌手妮娜。西蒙：我想要在我的碗里放一点糖。我想要我的灵魂中有一点甜。我可以忍受一些爱，哦，如此无奈。我感觉如此滑稽，我感觉如此悲哀。

• 观止类（Showstopper）错误是最严重的，它们把演出停了下来，意味着不解决它们就一定会导致发布延迟。其次是“一号优先级”的错误。通常，NT的样本版本会包含几百个这样的错误。“二号优先级”的错误的严重性又低了一些，有时会有几千个。

• 关于大型软件的真理：软件可能导致灾难，这意味着代码编写者在做工作时必须坚信，任何差错都不可避免地会危害他们，如果不是现在那么就是将来的某一天。

• 改善性能好像是做外科手术，而修正臭虫则是直接教授的血腥格斗。

• 臭虫是不可避免的，它们出自人类的疏忽。要完全避免臭虫，“人必须做到完美无缺”，但事实上没有人能做到。在《编程的苦恼》（woes of the craft）一文中，计算机科学家弗雷德里克。布鲁克斯曾经写道：“如果这种咒语的一个字符，一个停顿没有符合规定的格式，那么这个戏法也不灵了。人类是不习惯于保持完美的，而且在人类活动的领域中很少有哪个需要这样。我认为适应这种达到完美的要求是学习编程时最困难的部分。”

• 对一个编写代码的人来说，修正自己的臭虫是例行的事。

• “当你自己都建这个框架时，你更了解他的前提，”一个程序员解释道，“最为一个外来者，尽管你可以读代码的注释，但是你根本不了解这个人所忧虑的地方。本来需要花十秒钟修改可能会花半天时间。”

• 在这段时间里，正像一个中立者所说的：“写代码的开发人员觉得测试的人都是白痴，而做测试的人觉得开发的人都不是好东西。分离不是解决问题和取得进展的办法。”

• 抵触源于双方优先要做的事情不同。程序员们急切地想把他们的通用模型做的更精致，不想分散精力去铲除臭虫。而测试员要做测试，如果一周有一周始终看到同样的臭虫，那么测试就没什么意思了。解决方法：大卫。维尔德呼吁大家要把对方看做与自己是同一个单元。定期地把测试员和程序员找到一起做*讨论。这种方法很有效。让测试员们感觉到他们是这个家庭的一部分，而程序员们则正如他们中的一个人所说的“成了臭虫的奴隶”。

• “那种沿着自己设定的轨道前进的感觉是无与伦比的，你毫无疑问地知道你前进的方向。”他会非常怀念这种“没有管理者来管闲事，有目标、有*来做完一件事”的感觉。

• “美好的旧日时光”

《观止-微软创建NT和未来的夺命狂奔》 语录摘抄