程序员修炼之道-从小工到专家(摘录一)我的源码让猫给吃了,软件的熵

2018/01 08 17:01

在所有的弱点中,最大的弱点就是害暴露弱点。
–J.B.Bossuet,Politics from Holy Writ, 1709

依据你的职业发展、你的项目和你每天的工作,为你自己和你的行为负责这样一种观念,是注重实效的哲学的一块基石。注重实效的程序员对他或者她自己的职业生涯负责,并且不害怕承认无知或者错误。这肯定并非是编程最令人愉悦的方面,但它肯定会发生–即使是在最好的项目中。尽管有彻底的测试,良好的文档以及足够的自动化,事情还是会出错。交付晚了,出现了未曾预见到的技术问题。
发生这样的事情,我们要设法尽可能职业地处理它们。这意味着诚实和坦率。我们可以为我们的能力自豪,但对于我们的缺点–还有我们的无知和我们的错误–我们必须诚实。

负责

责任是你主动担负的东西。你承诺确保某件事情正确完成,但你不一定能直接控制事情的每一个方面。除了你尽你所能以外,你必须分析风险是否超出了你的控制。对于不可能做到的事情或是风险太大的事情,你有权不去为之负责。你必须基于你自己的道德准则和判断来做出决定。
如果你确实同意要为某个结果负责,你就应切实负起责任。当你犯错误(就如同我们所有人都会犯错误一样)、不要把所有问题都归咎于供应商、编程语言、管理部门、或是你的同事。也许他(它)们全体或是某几方面在其中扮演了某种角色,但你可以选择提供解决方案,而非寻找借口。
如果存在供应商不能按时供货的风险,你应该预先制定一份应急计划。如果磁盘垮了—带走了你的所有源码—而你没有备份,那是你的错。告诉你的老板“我的源码让猫给吃了”也无法改变这一点。
Provide Options,Dont’t Make Lame Excuses — 提供各种选择,不要找蹩脚的借口
在你走向任何人、告诉他们为何某件事做不到、为何耽搁、为何出问题之前,先停下来,听一听你心里的声音。与你的显示器上的橡皮鸭交谈,或是与猫交谈。你的辩解听起来合理,还是愚蠢?在你老板听来又是怎样?
在你的头脑里把谈话预演一遍。其它人可能会说什么?他们是否会问:“你试了这个吗?”,或是“你没有考虑那个吗?”你将怎样回答?在你去告诉他们坏消息之前,是否还有其它你可以再试一试的办法?有时,你其实知道他们会说什么,所以还是不要给他们添麻烦吧。
要提供各种选择,而不是找借口。不要说事情做不到;要说明能够做什么来挽回局面。必须把代码扔掉?给他们讲授重构的价值,你要花时间建立原型,以确定最好的继续前进的方式?你要引入更好的测试或自动化,以防止问题再发生?又或许你需要额外的资源。不要害怕提出要求,也不要害怕承认你需要帮助。
在你大声说出它们之前,先设法把蹩脚的借口清除出去。如果你必须说,就先对你的猫说。反正,如果小蒂德尔丝要承受指责。。。。
挑战
如果有人–比如银行柜台职员、汽车修理工或是店员—对你说蹩脚的借口,你会怎样反应?结果你会怎样想他们和他们的公司?

软件的熵

尽管软件开发几乎不受任何物理定律的约束,熵(entropy)对我们的影响却很大。熵是一个来自物理学的概念,指是的某个系统中的“无序”的总量。遗憾的是,热力学定律保证了宇宙中熵倾向于最大化。当软件中的无序增长时,程序员们称之为“软件腐烂”(Software rot)。
有许多因素可以促生软件腐烂。其中最重要的一个似乎是开发项目时的心理(或文化)。即使你的团队只有你一个人,你开发项目时的心理也可能是非常微妙的事情。尽管制定了最好的计划,拥有最好的开发者,项目在其生命期中仍可遭遇毁灭和衰败。而另外有一些项目,尽管遇到巨大的困难和接连而来的挫折,却成功地击败自然的无序倾向,设法取得了相当好的结果。
是什么造成了这样的差异?
在市区,有些建筑漂亮而整洁,而另一些却是破败不堪的“废弃船只”。为什么?犯罪和城市衰退领域的研究者发现了一种迷人的触发机制,一种能够很快将整洁、完整和有人居住的建筑变为破败的废弃物的机制。
破窗户。
一扇破窗户,只要有那么一段时间不修理,就会渐渐给建筑中的居民带来一种废弃感——一种职权部门不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。在相对较短的一段时间里,建筑就被损毁得超出了业主愿意修理的程度,而废弃感变成了现实。
“破窗户理论”启发了纽约和其它大城市的警察部门,他们对一些轻微的案件严加处理,以防止大案的发生。这起了作用:管束破窗户、乱涂乱画和其它轻微违法事件减少了严重罪案的发生。
Don’t Live with Broken Windows——不要容忍破窗户
不要留着“破窗户”(低劣的设计、错误决策、或是糟糕的代码)不修。发现一个就修一个。如果没有足够的时间进行适当的修理,就用木板把它钉起来。或许你可以把出问题的代码放入注释(comment out),或是显示“未实现”消息,或是用虚设的数据(dummy data)加以替代。采取某种行动防止进一步的损坏,并说明情势处在你的控制之下。
我们看到整洁、运行良好的系统,一旦窗户开始破裂,就相当迅速地恶化。还有其它一些因素能够促生软件腐烂,我们将在别处探讨它们,但与其它任何因素相比,置之不理都会更快地加腐烂的进程。
你也许在想,没有人有时间到处清理项目的所有碎玻璃。如果你继续这么想,你就最好计划找一个大型垃圾罐,或是搬到别处去。不要让熵赢得胜利。

 

灭火

作为对照,让我们讲述Andy的一个熟人的故事。他是一个富得让人讨厌的富翁,拥有一所完美、漂亮的房子,里面满是无价的古董、艺术品,以及诸如此类的东西。有一天,一幅挂毯挂得离他的卧室壁炉太近了一点,着了火。消防人员冲进来救火——和他的房子。但他们拖着粗大、肮脏的消防水管冲到房间门口却停住了——他们要在前门和着火处之间铺上垫子。
他们不想弄脏地毯。
这的确是一个极端的事例,但我们必须以这样的方式对待软件。一扇破窗户——一段设计低劣的代码、团队必须在整个项目开发过程中加以忍受的一项糟糕的管理决策——就足以让项目开始衰败。如果你发现自己在有好些破窗户的项目里工作,会很容易产生这样的想法:“这些代码的其余部分也是垃圾,我只要照着做就行了。”项目在这之前是否一直很好,并没有什么关系。在最初得出“破窗户理论”的一项实验中,一辆废弃的轿车放了一个星期,无人理睬。而一旦有一扇窗户被打破,数小时之内车上的设备就会被抢夺一空,车也被翻了个底朝天。
按照同样的道理,如果你发现你所在的团队和项目的代码十分漂亮——编写整洁、设计良好,并且很优雅——你就可能会格外注意不去把它弄脏,就和那些消防员一样。即使有火在咆哮(最后期限、发布日期、会展演示,等等),你也不会想成为第一个弄脏东西的人。

--转载请注明: http://blog.coolcoding.cn/?p=4