读《编程之道》-幽默背后的设计之要
第三篇：设计
编程大师如是说： “当程序被测试时，再修改设计方案就太迟了。”
在我看来，大师的这句话中的后半句表明设计方案是在写代码实现之前的，也就是说所编写的代码是基于已经完成的设计方法而进行的。
但是当程序被测试之后就真的不能再修改设计方案了吗？这与TDD（测试驱动开发）开发方法所倡导的“由测试来决定需要编写怎样的代码”有冲突吗？
近来在读的《测试驱动开发实用指南》一书中作者在前言中指出“测试驱动开发是极限编程中的一项主要的设计工具（另一项是重构）”，因此，暂时读不出大师的这句话有何含义…
3.1
曾经有个人去参加一次电脑展示会，每天当他进入展馆时，都对门卫说： “我是个大盗，我偷盗的本领是出了名的。事先警告你，这次展示会也在劫难逃。”
这番话让门卫坐立不安，因为里面有价值数百万美元的电脑设备，所以他紧紧地盯住这个人。但这个人只是从一个展摊逛到另一个展摊，嘴里轻轻地哼着小曲。 当这个人出门时，门卫把他拉到一边，搜查他的衣服，但一无所获。
第二天，这个人又来了，并对着门卫嚣张地嚷着：“昨天我满载而归，但今天的收获会更大。”于是，门卫盯他盯得更紧了，但仍一无所获。
大盗在第二天特地强调了“今天的收获会更大”，甚于“昨天”的“满载而归”，继续读完下面两段，似乎能够看出这位大盗有什么特点。
在展示会的最后一天，门卫再也抑制不住自己的好奇心了。“大盗先生，”门卫说，“我被你搞糊涂了，实在想不明白。请告诉我，你究竟在偷什么？” 这个人笑了。“我在偷想法。”他说。
大盗在“偷想法”，之所以在第二天向门卫强调“今天”与“昨天”的区别，我想应该是大盗在第一天回去之后肯定对“偷到”的想法认真思考过了，第二天才“有备而来”，也许是为了验证自己的某些观点，更可能是为了更加深入地发掘…
这也表明，一天要比一天有所得、有进步，就在于我们自身是否有思考。
由于第三章的主题是设计，而这第一个幽默故事是“偷想法”，那么我认为作者应该也是将设计理解成一种“想法”，即比较抽象的事物。我们“偷”不到别人优秀的源代码，但是我们可以“偷”（借鉴）别人优秀的设计、架构，也就是“想法”。
3.2
曾经有位编程大师，喜欢编写非结构化的编程。一位初学者试图模仿他，也开始编写非结构化的程序。当这位徒弟请师父评价他的进展时，师父批评了他的做法。他说：“对一位编程高手适合的，对初学者来说并不一定适合。在超越结构化之前，你必须先领悟道。”
这一个故事阐明的道理也就在大师的话语中了，“对一位编程高手适合的，对初学者来说并不一定适合”。这也说明了我们要脚踏实地学好扎实的基础知识，才能有所领悟。或许，软件设计的能力可以从我们平时的编程经验中逐渐获得。
3.3
曾经有位程序员被派到Wu的军机大臣手下工作。军机大臣问程序员：“设计一个财务软件包，和设计一个操作系统，哪一个更容易？”
“操作系统。”程序员回答说。
军机大臣立刻发生一种不信任的惊叹，“与一个复杂的操作系统，一个财务软件包简直是小巫见大巫。”他说。
“并非如此，”程序员说，“在设计一个财务软件包时，编程人员是作为一个中介者在观念各异的人们之间起作用的：这个软件必须如何操作，它的报表必须是什么形式，它必须如何与税法一致，等等。
相反，一个操作系统则不为其外观所限制。当设计一个操作系统时，编程人员只要在机器与人的思维之间寻找一种最简单的和谐就可以了。这就是为什么操作系统更容易设计。”
程序员是这样看待财务软件包和操作系统的，对于财务软件包，程序员只是作为中介者来协调、规范人与人之间的关系。我们知道，中介者的职责本来就是调停、协调，程序员这么理解也有理。
而对于操作系统则是和谐机器与人的思维之间的关系，而且这种和谐必须是最简单的。故操作系统更容易设计。看看下文。
军机大臣点点头，笑了。“说来也是。但要想检测和纠正其中的错误，哪个更容易呢？” 程序员没有回答。
一个让程序员无话可说的问题，为什么对操作系统进行调试、检错会更难呢？在这里好像并没有谈到应用软件是基于操作系统才能运作的。我认为，操作系统也是人类设计的，财务软件包也是人类设计的，区分两者的关键就在于它们所作用的对象是什么。
其实，我还是不理解作者的意图…
3.4
一位经理到编程大师那里，交给他一份有关一个新应用程序的需求说明。经理问编程大师：“如果我分配五个程序员给你，你需要多久能设计好这个系统？”
“那将花费一年的时间。”大师立刻回答。 “但我们马上就需要这个系统，甚至要求更快！如果我分配十个程序员给你，你需要多长时间？”
大师皱了皱眉头，“那样的话，需要两年。”
“如果我分配一百个程序员给你怎么样？”
大师耸了耸肩膀，“那么这项设计将永远无法完成。”他说。
很明显，程序员数量并不与项目的开发进度、员工的工作效率成正比。这里面应该不止涉及到设计方面，我认为更多的是项目管理。