对程序员最有影响每个程序员都该阅读的书程序员修炼之道中文版.doc
《对程序员最有影响每个程序员都该阅读的书程序员修炼之道中文版.doc》由会员分享,可在线阅读,更多相关《对程序员最有影响每个程序员都该阅读的书程序员修炼之道中文版.doc(70页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、【精品文档】如有侵权,请联系网站删除,仅供学习与交流对程序员最有影响每个程序员都该阅读的书程序员修炼之道中文版.精品文档.程序员修炼之道1 我的源码让猫给吃了32 软件的熵53 石头汤与煮青蛙74 足够好的软件95 你的知识资产116 交流!167 重复的危害218 正交性299 可撤消性3710 曳光弹4011 原型与便笺4412 领域语言4813 估算5414 纯文本的威力5915 shell游戏6416 强力编辑6817 源码控制7118 调试7419 文本操纵8120 代码生成器8421 按合约设计(1)8721 按合约设计(2)9222 死程序不说谎9923 断言式编程10124 何
2、时使用异常10425怎样配平资源1081 我的源码让猫给吃了 注重实效的程序员的特征是什么?我们觉得是他们处理问题、寻求解决方案时的态度、风格、哲学。他们能够越出直接的问题去思考,总是设法把问题放在更大的语境中,总是设法注意更大的图景。毕竟,没有这样的更大的语境,你又怎能注重实效?你又怎能做出明智的妥协和有见识的决策?他们成功的另一关键是他们对他们所做的每件事情负责,关于这一点,我们将在“我的源码让猫给吃了”中加以讨论。因为负责,注重实效的程序员不会坐视他们的项目土崩瓦解。在“软件的熵”中,我们将告诉你怎样使你的项目保持整洁。大多数人发现自己很难接受变化,有时是出于好的理由,有时只是因为固有的
3、惰性。在“石头汤与煮青蛙”中,我们将考察一种促成变化的策略,并(出于对平衡的兴趣)讲述一个忽视渐变危险的两栖动物的警世传说。理解你的工作的语境的好处之一是,了解你的软件必须有多好变得更容易了。有时接近完美是惟一的选择,但常常会涉及各种权衡。我们将在“足够好的软件”中探究这一问题。当然,你需要拥有广泛的知识和经验基础才能赢得这一切。学习是一个持续不断的过程。在“你的知识资产”中,我们将讨论一些策略,让你“开足马力”。最后,我们没有人生活在真空中。我们都要花大量时间与他人打交道。在“交流!”中列出了能让我们更好地做到这一点的几种途径。注重实效的编程源于注重实效的思考的哲学。本章将为这种哲学设立基础
4、。1 我的源码让猫给吃了在所有弱点中,最大的弱点就是害怕暴露弱点。J. B. Bossuet, Politics from Holy Writ, 1709依据你的职业发展、你的项目和你每天的工作,为你自己和你的行为负责这样一种观念,是注重实效的哲学的一块基石。注重实效的程序员对他或她自己的职业生涯负责,并且不害怕承认无知或错误。这肯定并非是编程最令人愉悦的方面,但它肯定会发生即使是在最好的项目中。尽管有彻底的测试、良好的文档以及足够的自动化,事情还是会出错。交付晚了,出现了未曾预见到的技术问题。发生这样的事情,我们要设法尽可能职业地处理它们。这意味着诚实和坦率。我们可以为我们的能力自豪,但对于
5、我们的缺点还有我们的无知和我们的错误我们必须诚实。负责责任是你主动担负的东西。你承诺确保某件事情正确完成,但你不一定能直接控制事情的每一个方面。除了尽你所能以外,你必须分析风险是否超出了你的控制。对于不可能做到的事情或是风险太大的事情,你有权不去为之负责。你必须基于你自己的道德准则和判断来做出决定。如果你确实同意要为某个结果负责,你就应切实负起责任。当你犯错误(就如同我们所有人都会犯错误一样)、或是判断失误时,诚实地承认它,并设法给出各种选择。不要责备别人或别的东西,或是拼凑借口。不要把所有问题都归咎于供应商、编程语言、管理部门、或是你的同事。也许他(它)们全体或是某几方在其中扮演了某种角色,
6、但你可以选择提供解决方案,而非寻找借口。如果存在供应商不能按时供货的风险,你应该预先制定一份应急计划。如果磁盘垮了带走了你的所有源码而你没有做备份,那是你的错。告诉你的老板“我的源码让猫给吃了”也无法改变这一点。提示3Provide Options, Dont Make Lame Excuses提供各种选择,不要找蹩脚的借口在你走向任何人、告诉他们为何某事做不到、为何耽搁、为何出问题之前,先停下来,听一听你心里的声音。与你的显示器上的橡皮鸭交谈,或是与猫交谈。你的辩解听起来合理,还是愚蠢?在你老板听来又是怎样?在你的头脑里把谈话预演一遍。其他人可能会说什么?他们是否会问:“你试了这个吗”,或是
7、“你没有考虑那个吗?”你将怎样回答?在你去告诉他们坏消息之前,是否还有其他你可以再试一试的办法?有时,你其实知道他们会说什么,所以还是不要给他们添麻烦吧。要提供各种选择,而不是找借口。不要说事情做不到;要说明能够做什么来挽回局面。必须把代码扔掉?给他们讲授重构的价值(参见重构,184页)。你要花时间建立原型(prototyping),以确定最好的继续前进的方式(参见原型与便笺,53页)?你要引入更好的测试(参见易于测试的代码,189页;以及无情的测试,237页)或自动化(参见无处不在的自动化,230页),以防止问题再度发生?又或许你需要额外的资源。不要害怕提出要求,也不要害怕承认你需要帮助。在
8、你大声说出它们之前,先设法把蹩脚的借口清除出去。如果你必须说,就先对你的猫说。反正,如果小蒂德尔丝(Tiddles,BBC在19691974年播出的喜剧节目“Monty Pythons Flying Circus”中的著名小母猫译注)要承受指责2 软件的熵尽管软件开发几乎不受任何物理定律的约束,熵(entropy)对我们的影响却很大。熵是一个来自物理学的概念,指的是某个系统中的“无序”的总量。遗憾的是,热力学定律保证了宇宙中的熵倾向于最大化。当软件中的无序增长时,程序员们称之为“软件腐烂”(software rot)。有许多因素可以促生软件腐烂。其中最重要的一个似乎是开发项目时的心理(或文化)
9、。即使你的团队只有你一个人,你开发项目时的心理也可能是非常微妙的事情。尽管制定了最好的计划,拥有最好的开发者,项目在其生命期中仍可能遭遇毁灭和衰败。而另外有一些项目,尽管遇到巨大的困难和接连而来的挫折,却成功地击败自然的无序倾向,设法取得了相当好的结果。是什么造成了这样的差异?在市区,有些建筑漂亮而整洁,而另一些却是破败不堪的“废弃船只”。为什么?犯罪和城市衰退领域的研究者发现了一种迷人的触发机制,一种能够很快将整洁、完整和有人居住的建筑变为破败的废弃物的机制WK82。破窗户。一扇破窗户,只要有那么一段时间不修理,就会渐渐给建筑的居民带来一种废弃感一种职权部门不关心这座建筑的感觉。于是又一扇窗
10、户破了。人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。在相对较短的一段时间里,建筑就被损毁得超出了业主愿意修理的程度,而废弃感变成了现实。“破窗户理论”启发了纽约和其他大城市的警察部门,他们对一些轻微的案件严加处理,以防止大案的发生。这起了作用:管束破窗户、乱涂乱画和其他轻微违法事件减少了严重罪案的发生。提示4Dont Live with Broken Windows不要容忍破窗户不要留着“破窗户”(低劣的设计、错误决策、或是糟糕的代码)不修。发现一个就修一个。如果没有足够的时间进行适当的修理,就用木板把它钉起来。或许你可以把出问题的代码放入注释(comment out),或是显示“
11、未实现”消息,或是用虚设的数据(dummy data)加以替代。采取某种行动防止进一步的损坏,并说明情势处在你的控制之下。我们看到过整洁、运行良好的系统,一旦窗户开始破裂,就相当迅速地恶化。还有其他一些因素能够促生软件腐烂,我们将在别处探讨它们,但与其他任何因素相比,置之不理都会更快地加速腐烂的进程。你也许在想,没有人有时间到处清理项目的所有碎玻璃。如果你继续这么想,你就最好计划找一个大型垃圾罐,或是搬到别处去。不要让熵赢得胜利。灭火作为对照,让我们讲述Andy的一个熟人的故事。他是一个富得让人讨厌的富翁,拥有一所完美、漂亮的房子,里面满是无价的古董、艺术品,以及诸如此类的东西。有一天,一幅挂
12、毯挂得离他的卧室壁炉太近了一点,着了火。消防人员冲进来救火和他的房子。但他们拖着粗大、肮脏的消防水管冲到房间门口却停住了火在咆哮他们要在前门和着火处之间铺上垫子。他们不想弄脏地毯。这的确是一个极端的事例,但我们必须以这样的方式对待软件。一扇破窗户一段设计低劣的代码、团队必须在整个项目开发过程中加以忍受的一项糟糕的管理决策就足以使项目开始衰败。如果你发现自己在有好些破窗户的项目里工作,会很容易产生这样的想法:“这些代码的其余部分也是垃圾,我只要照着做就行了。”项目在这之前是否一直很好,并没有什么关系。在最初得出“破窗户理论”的一项实验中,一辆废弃的轿车放了一个星期,无人理睬。而一旦有一扇窗户被打
13、破,数小时之内车上的设备就被抢夺一空,车也被翻了个底朝天。按照同样的道理,如果你发现你所在团队和项目的代码十分漂亮编写整洁、设计良好,并且很优雅你就很可能会格外注意不去把它弄脏,就和那些消防员一样。即使有火在咆哮(最后期限、发布日期、会展演示,等等),你也不会想成为第一个弄脏东西的人。相关内容:l 石头汤与煮青蛙,7页l 重构,184页l 注重实效的团队,224页挑战l 通过调查你周边的计算“环境”,帮助增强你的团队的能力。选择两或三扇“破窗户”,并与你的同事讨论问题何在,以及怎样修理它们。l 你能否说出某扇窗户是何时破的?你的反应是什么?如果它是他人的决策所致,或者是管理部门的指示,你能做些
14、什么?3 石头汤与煮青蛙三个士兵从战场返回家乡,在路上饿了。他们看见前面有村庄,就来了精神他们相信村民会给他们一顿饭吃。但当他们到达那里,却发现门锁着,窗户也关着。经历了多年战乱,村民们粮食匮乏,并把他们有的一点粮食藏了起来。士兵们并未气馁,他们煮开一锅水,小心地把三块石头放进去。吃惊的村民们走出来望着他们。“这是石头汤。”士兵们解释说。“就放石头吗?”村民们问。“一点没错但有人说加一些胡萝卜味道更好”一个村民跑开了,又很快带着他储藏的一篮胡萝卜跑回来。几分钟之后,村民们又问:“就是这些了吗?”“哦,”士兵们说:“几个土豆会让汤更实在。”又一个村民跑开了。接下来的一小时,士兵们列举了更多让汤更
15、鲜美的配料:牛肉、韭菜、盐,还有香菜。每次都会有一个不同的村民跑回去搜寻自己的私人储藏品。最后他们煮出了一大锅热气腾腾的汤。士兵们拿掉石头,和所有村民一起享用了一顿美餐,这是几个月以来他们所有人第一次吃饱饭。在石头汤的故事里有两层寓意。士兵戏弄了村民,他们利用村民的好奇,从他们那里弄到了食物。但更重要的是,士兵充当催化剂,把村民团结起来,和他们一起做到了他们自己本来做不到的事情一项协作的成果。最后每个人都是赢家。你常常也可以效仿这些士兵。在有些情况下,你也许确切地知道需要做什么,以及怎样去做。整个系统就在你的眼前你知道它是对的。但请求许可去处理整个事情,你会遇到拖延和漠然。大家要设立委员会,预
16、算需要批准,事情会变得复杂化。每个人都会护卫他们自己的资源。有时候,这叫做“启动杂役”(start-up fatigue)。这正是拿出石头的时候。设计出你可以合理要求的东西,好好开发它。一旦完成,就拿给大家看,让他们大吃一惊。然后说:“要是我们增加可能就会更好。”假装那并不重要。坐回椅子上,等着他们开始要你增加你本来就想要的功能。人们发现,参与正在发生的成功要更容易。让他们瞥见未来,你就能让他们聚集在你周围1。提示5Be a Catalyst for Change做变化的催化剂村民的角度另一方面,石头汤的故事也是关于温和而渐进的欺骗的故事。它讲述的是过于集中的注意力。村民想着石头,忘了世界的其
17、余部分。我们都是这样,每一天。事情会悄悄爬到我们身上。我们都看见过这样的症状。项目慢慢地、不可改变地完全失去控制。大多数软件灾难都是从微不足道的小事情开始的,大多数项目的拖延都是一天一天发生的。系统一个特性一个特性地偏离其规范,一个又一个的补丁被打到某段代码上,直到最初的代码一点没有留下。常常是小事情的累积破坏了士气和团队。提示6Remember the Big Picture记住大图景我们没有做过这个真的,但有人说,如果你抓一只青蛙放进沸水里,它会一下子跳出来。但是,如果你把青蛙放进冷水里,然后慢慢加热,青蛙不会注意到温度的缓慢变化,会呆在锅里,直到被煮熟。注意,青蛙的问题与第2节讨论的破窗
18、户问题不同。在破窗户理论中,人们失去与熵战斗的意愿,是因为他们觉察到没有人会在意。而青蛙只是没有注意到变化。不要像青蛙一样。留心大图景。要持续不断地观察周围发生的事情,而不只是你自己在做的事情。相关内容:l 软件的熵,4页l 靠巧合编程,172页l 重构,184页l 需求之坑,202页l 注重实效的团队,224页挑战l 在评阅本书的草稿时,John Lakos提出这样一个问题:士兵渐进地欺骗村民,但他们所催生的变化对村民完全有利。但是,渐进地欺骗青蛙,你是在加害于它。当你设法催生变化时,你能否确定你是在做石头汤还是青蛙汤?决策是主观的还是客观的?4 足够好的软件欲求更好,常把好事变糟。李尔王
19、1.4有一个(有点)老的笑话,说一家美国公司向一家日本制造商订购100 000片集成电路。规格说明中有次品率:10 000片中只能有1片。几周过后订货到了:一个大盒子,里面装有数千片IC,还有一个小盒子,里面只装有10片IC。在小盒子上有一个标签,上面写着:“这些是次品”。要是我们真的能这样控制质量就好了。但现实世界不会让我们制作出十分完美的产品,特别是不会有无错的软件。时间、技术和急躁都在合谋反对我们。但是,这并不一定就让人气馁。如Ed Yourdon发表在IEEE Software上的一篇文章You95所描述的,你可以训练你自己,编写出足够好的软件对你的用户、对未来的维护者、对你自己内心的
20、安宁来说足够好。你会发现,你变得更多产,而你的用户也会更加高兴。你也许还会发现,因为“孵化期”更短,你的程序实际上更好了。在继续前进之前,我们需要对我们将要说的话进行限定。短语“足够好”并非意味着不整洁或制作糟糕的代码。所有系统都必须满足其用户的需求,才能取得成功。我们只是在宣扬,应该给用户以机会,让他们参与决定你所制作的东西何时已足够好。让你的用户参与权衡通常你是为别人编写软件。你常常需要记得从他们那里获取需求2。但你是否常问他们,他们想要他们的软件有多好?有时候选择并不存在。如果你的工作对象是心脏起搏器、航天飞机、或是将被广泛传播的底层库,需求就会更苛刻,你的选择就更有限。但是,如果你的工
21、作对象是全新的产品,你就会有不同的约束。市场人员有需要信守的承诺,最终用户也许已基于交付时间表制定了各种计划,而你的公司肯定有现金流方面的约束。无视这些用户的需求,一味地给程序增加新特性,或是一次又一次润饰代码,这不是有职业素养的做法。我们不是在提倡慌张:许诺不可能兑现的时间标度(time scale),为赶上最后期限而削减基本的工程内容,这些同样不是有职业素养的做法。你所制作的系统的范围和质量应该作为系统需求的一部分规定下来。提示7Make Quality a Requirements Issue使质量成为需求问题你常常会处在须要进行权衡的情形中。让人惊奇的是,许多用户宁愿在今天用上有一些“
22、毛边”的软件,也不愿等待一年后的多媒体版本。许多预算吃紧的IT部门都会同意这样的说法。今天的了不起的软件常常比明天的完美软件更可取。如果你给用户某样东西,让他们及早使用,他们的反馈常常会把你引向更好的最终解决方案(参见曳光弹,48页)。知道何时止步在某些方面,编程就像是绘画。你从空白的画布和某些基本原材料开始,通过知识、艺术和技艺的结合去确定用前者做些什么。你勾画出全景,绘制背景,然后填入各种细节。你不时后退一步,用批判的眼光观察你的作品。常常,你会扔掉画布,重新再来。但艺术家们会告诉你,如果你不懂得应何时止步,所有的辛苦劳作就会遭到毁坏。如果你一层又一层、细节复细节地叠加,绘画就会迷失在绘制
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 程序员 有影响 每个 阅读 修炼 中文版
限制150内