第9节

们不得不敲敲他的门：“威廉，做得怎样了？”里 面是一阵迟疑，然后听到他说：“还不错。”“什么时候可 以完成呢？”经过更长的停顿，我们几乎听到泪水流下的声音，威廉哽咽着回答：“就快了。” 我们知道他说的“快”，其实还早得很。现在全公司的人都只能呆呆站着干等，一点也帮不上忙。而我，身为 主管和项目负责人，面临了困难的抉择：我可以开除威廉， 但考虑到他是惟一能够解救我们的人，惟一真正了解当前 困难之所在的人，所以我不加思索地决定，让威廉继续完 成他的工作，他毕竟是团对中最优秀的人才，也是团队中 惟一能够掌握这个问题里里外外的人。

我惟一能做的，只有替他买更多的可乐。

另一个比较好的方法是给他加点压力，让他搞清楚自 己身系团队的危急存亡，所有组员和他们的家庭都指望他 不凡的脑袋和飞快的手指，我们得催逼他做出个像样的东 西出来。但我稍微三思，就觉得这也不是个好办法，对生产力 没有帮助。我没有办法摆脱这个困境了，我只能往好的方 面想：威廉会完成他的工作的，只要他没死或离职。经过 这次教训，他大概再也不敢为我工作了。现在我惟一能做 的事只有帮他买更多的可乐，其他什么办法都没有！当然，如果你有一位大天才关起房门埋头苦干，你或 许会有更具独特创意的结果，一种是健康型，一种是病态 型。病态型的闭关修炼是大天才无法在任何一关做出成品， 却能在期限的最后五分钟交出奇迹似的杰作；健康型的闭 关修炼是大天才免除一切世俗的干扰，全心致力于工作， 由于他的工作创意程度太高，完全得靠他的心理、情绪等法则31建留心没有检查点的组员

223内在的心智力量，这时候团队合作对他来说没有什么帮助， 反而有打扰之虞。像这种天才型的特殊程序设计师，为了清静而把自己 关在房间里很长的时间，而没有人知道他的工作进展，也 许是有发挥创造力的必要，但这对于如期推出产品而言是 冒着极大的风险，无论他多么优秀，领导者都不该把重要 的工作交托给他，除非让他与其他的开发人员一起接受定 期检查工作进度，而且对时限绝不宽贷。可惜有些天赋才 智恣意奔驰的人无法忍受这样的限制。在软件业中，这种 人确实存在，他可以做一些无法想象的创举（在实验室 里），掀起一波技术的飞跃，但他绝对不会出现在矢志如 期推出产品的开发团队中。不论是健康的或病态的闭关修炼者，允许一位开发人 员关在房间里没有人知道他的工作进度，结果通常会是开 发团队的致命伤。所以，一定得竭尽所能地避免这种情况， 绝对不要允许“没有检查点的组员”，否则你难逃失败。

法则 32

If you build it, it will ship 软件要经常建构，就 能顺利推出法则32建软件要经常建构，就能顺利推出

225(软件通常是由许多许多程序组成的；程序写好 后，经过编译器产生执行码，这个动作叫 c o m p i l e， 通常如果是小而独立的程序，可选直接选择编译成可 执行档，但是以软件包或 C + +之类的大型软件而言， 程序数目都在数百个以上，通常每个程序都是编译成 对象文件，即object code，然后众多不同的程序依一 定的结构关系组合成一个软件，这个组合的动作叫作 建构，b u i l d，产生的结果是真正可执行的完整软件。 每一套软件的建构方式多多少少都有些不同，原则上， 被呼叫的程序或函数库要先b u i l d，主程序最后b u i l d。

—译者注）将程序建构成软件才能推出，这个自然，总不能卖给 顾客一个不可执行的原始程序代码吧！但我的意思是要能 够经常且定期地建构软件，并不是到了期限前一天才建构 那么一次。你必须随时都让整个软件的现状都能被大家看 见才行。(在很早以前曾经有过一个案例，各个程序都按 计划中的时间表进行撰写，个别程序的测试也完全正 确，但是到了最后却怎样也无法组合，各个程序就是 无法搭配。因为各个程序之间都有相互传递资料或先

后连结的关系，或是其中有一个程序内有个无伤大雅 的小瑕疵未被注意，但却在别的程序上造成大问题。 在写程序的过程中随时要注意我的程序能否跟其他所 有的程序相互配合，最好的办法就是常常 b u i l d，这 样才能做完整的测试。完整测试是 b u i l d最基本的目 的，所以作者就不刻意强调，但定期建构软件还有更 重要的益处。—译者注）你能想象几百位工匠蒙着眼睛盖一栋大楼吗？不知道 自己在盖大楼的那一部分，不知道这栋大楼现在盖到第几 层，只顾盖自己的部分，这种大楼怎会不垮呢？因此，经 常建构软件是非常必要的，这个法则的重点不仅是要在整 个开发过程中经常地、定期地建构软件，而且要尽可能建 构出现阶段最完整又最正确的软件，更重要的是建构出来 的结果要放在公开的地方，让每个人都能看到。软件也许不必每天都做建构，但是一定要经常且定期 做，而且不只是程序要做建构，安装程序和线上求助的部 分也要包括在内，然后将建构出来的结果放在公开的地方， 让品保人员可以评估每天的软件状况，也可以观察出它发 展的情形，或是陷于停滞。规律建构软件是一项最可靠的 指标，表示团队的运作是否正常，软件是否能够完成。

法则32建软件要经常建构，就能顺利推出

丑媳妇也要经常见公婆软件的建构需要时间，程序也很复杂，值得你为它仔 细研拟最适当的策略。在微软内部有很多开发团队采取每 日建构的策略，并有专门的小组（build master）负责这项 工作。建构程序是很重要的，必须确定软件能够建构得起

来，没有失败或中断。在每一只程序置入（ c h e c k - i n）开 发环境时，会产生这一只程序需要的建构程序（通常是配 合适当选项的c o m p i l e），然后整合在整体的建构程序中。 于是其中任何一段建构程序发生问题的话，很容易找到由 谁来负责，所以组员的责任心和荣誉感会促使自己一定要 做出至少能够合格的程序，而每天的软件建构就会非常顺 利。当然你可以做得更严格，以我的经验，一天建构一次 是最有效率的方式（请参考下一个法则）。(有些软件公司每次的建构都是把所有的程序都 c o m p i l e一遍，然后b u i l d起来，有些则是将修改过的 程序c o m p i l e，再b u i l d上已有的软件。由于全部b u i l d 一次所需的时间可能太长，所以大部分的公司都采取 第二种方式。说得更口语一些，就是把其中的一块挖 下来改一改再嵌回去。当这段程序被认为 O K了，就 做置入的动作，c h e c k - i n；每隔一定的时间，就有专 人把这些被改过的程序compile和build。—译者注）另一方面，项目经理应该是拟定最佳化的建构策略， 而不是绝对性的每隔几天做一次建构。不一定要每天做， 应该是采取对软件最适合又最小的间隔，重点是在能够建 构出软件的前题下，用最短的时间间隔建构出软件。

法则32建软件要经常建构，就能顺利推出

229老实说，我并不知道软件“应该”采取多长的建构周 期最好，但我非常相信大部分的软件公司在这方面都做得 不够。对某些开发团队而言，每天建构一次也许稍多，但 我很确定，对任何开发团队而言，每周建构一次绝对是最 起码的。项目经理一定要时常看见软件的整体状况，才能明 了现在正在做什么。即使你的工作分配和检查点设置得 非常好，各个组员之间的信任与承诺关系也非常理想， 但若是无法建构软件，则你对进度的掌握将仅限于想象 和猜测，而不是根据事实，所以你还是不能掌握软件开 发的真正状况。

每一次你建构软件，你就能算出错虫 数目有多少，你就能掌握软件开发的进度，你就能看见功能日益成形。

再者，为了让软件能够建构出来，程序必须维持在 一定的品质水准，太夸张的错误要立刻被发现，而且不 可能将软件倒回去重来。因此，每隔固定时间建构软件，

才能够维持软件有一定的秩序和品质，这一点要让大家 都知道。更重要的是，定期建构软件就像是团队的心跳一样， 每天五点（比方说），大家都看到今天整个团队的工作成 果，每天都看得到今天的进步，这对团队士气有很大的 鼓舞。如果有一天软件建构失败，或是为了某种原因而 不做建构，马上就会引起大家的注意和紧张，一定要找 出原因来改正。如果建构经常失败，这就是整个项目失 败的前兆。但请不要搞混了，我所谓的软件建构，不是程序设计 师在自己的P C上做的小规模的建构，而是指正式的、公 开的建构，将大大小小的程序结合成软件，而且是每个人 都能看见、能执行的软件。品保人员可以对它做初步的测 试（sniff test），看看它的基本功能大致上有没有错误。如 果你每天都做软件建构，你就很有把握它至少不会当得惨 兮兮，而且大家可以看见它朝着目标一天天地迈进，功能 特色一天天地成形；而且每个人都测试着相同的软件，对 于软件的现状也就会有相同的认知。

经常建构软件还有其他的好处：经常而公开地建构软件可以看出组员彼此之间真正法则32建软件要经常建构，就能顺利推出

231的信赖程度。只要有任何一个环节没有密合，软件 就建构不起来，检视建构的过程就像是检视组员之 间或是团队对外的关系，在任何地方发生问题都很 容易找到。 建构出来的软件可以显露出在设计时没有考虑到的 问题，例如执行效能、对象大小等等，这种问题万 一发现得太晚就来不及修改了。 软件的建构会很自然地让组员的脚步一致。一般 而言，建构软件最常见的问题是版本协调，最严重 的是各人有各人的版本，谁都不知道别人在做什么 版本，有了公开建构的软件，大家的版本就可以同 步了。 建构软件可以促使组员面对他想忽略的问题。团队 恒等于软件，所以目前的软件状态就是目前的团队 状态。当我遇到产品有问题时，我追问组员：“我 们软件建构的情况如何？”答案很多种，意思只有 一个：“我们花很多时间才能成功建构一次，有时 候长达两个星期，我们希望时间能够缩短，但是因 为某些某些原因，我们没有办法照计划来建构。” 是的，要频繁而规律地建构软件当然会有很多困难，

但是解决这些困难却能够带来健康的团队和顺利的开发。 开发人员必须得自律，自己仔细检查所有的功能都完善了 才把程序置入，程序不仅要在逻辑上执行正确，还得注意 体裁（程序段落清楚）和资源运用（内存用完了要释回）， 以及执行效能，如果个别的程序组件都很健全，就比较容 易建构软件，并且能够大大减少回溯检查的时间消耗。在开发过程中，很容易对软件的状况产生错觉，但 是如果你每天都建构一次软件，你看到的将会是具体的 事实。

法则 33

Get a known state and stay there掌握实际情况