程序员修炼之道——第一章 注重实效的哲学

前言与收获： 书接上回做有实效的程序员，读者认为需要：多进行思考、快速接受新的事物、坚持。
本章节都是精华，以后好好阅读。

摘要：

1. “我的源码让猫吃了"讲对于自己做的每一件事进行负责，因为负责不会让项目土崩瓦解。
2. “软件的熵” 讲如何将项目保持整洁。
3. “石头汤与煮青蛙” 讲如何对待变化。
4. “足够好的软件” 讲如何平衡完美软件的 各种权衡
5. “你的知识资产” 讲学习是一个持续不断地过程，我们将讨论一些策略，让你开足马力。
6. “交流” 讲 如何和他人交流

注重实效的哲学

1.我的源码让猫给吃了

在所有的弱点中，最大的弱点就是害怕暴漏弱点。
对于我们的错误和缺点——必须诚实的面对。

负责

责任是你主动担负的东西。承诺确保某件事正确完成，但你不一定能控制事情的每一方面，除了尽你所能以外，你必须分析风险是否超出了你的控制，对于不可能做到的事情或是风险太大的事情，你有权不去为之负责、你必须基于你自己的道德准则和判断来做出决定。
如果你确实同意要为某个结果负责，你就应切实负起责任。当你犯错误(就如同我们所有人都会犯错误一样)、或是判断失误时。诚实的承认它，并设法给出解决的各种选择。
不要责备别人或别的东西。或者拼凑借口。**不要把所有问题都归咎于供应商、编程语言、管理部门、或者是你的同事。**或许他们全体或是某几方在其中扮演了某种角色，但你可以选择提供解决方法，而非找借口。

提供各种选择，不要找蹩脚的借口
在你走向任何人，告诉他们为何某事做不到，为何耽搁，为何出问题之前，先停下来，听一听你心里的声音，与你的显示器上的橡皮鸭交谈，或者与猫交谈。你的辩解听起来合理？还是愚蠢？在你老板听来又是怎样？
在你的头脑里把谈话预言一遍

2.软件的熵

熵来自于物理的一个量，指的是是某个系统中的“无序的总量”，但对于软件中的无序增长，一般被称为“软件腐烂”。

有很多因素促使软件腐烂。 其中最重要的一个似乎是开发项目时的心理（或文化），即使团队只有一个人，你开发项目时的心理也可能是十分微妙的事。尽管制定了最好的计划，拥有最好的计划，拥有最好的开发者，项目在其生命周期仍可能遭受毁灭和衰败，而另外有一些项目尽管遇到巨大的困难和接连而来的挫折，却成功地自然击败自然的无序倾向，设法获得相当好的结果。

是什么造成了这些不同的结果？

破窗户理论：

不要留破窗户，因为只要有一段时间不去修理这个窗户，就会给人一种废弃感。于是出现了有一扇破窗户，人们开始乱丢垃圾，出现乱涂乱画，严重的结构损坏开始了。在相对很短的一段时间里，建筑就被损坏到超出业主愿意修理的程度。

破窗户理论给纽约市和其他的警察启发，对于一些轻微的案件严加处理，以防大案的发生。这起到了管理破窗户的，乱涂乱画和其他轻微违法事件，以减少严重的案件发生。

启示： 在软件中，在一开始的时候就让项目组成员对错误重视起来，对于小错误绝不放过，不姑息。让项目组成员建立起有错误就要处理，不要留到明天，不要因为错误小，而不去修改。（对于自己而言也一样，慎重的去挖掘错误背后的内容，为何会犯错？;这个错误会导致什么样的结果，越严重越好，这样会有深刻的印象，下次将不会犯同样的错误；怎样去修复它）

不要留着低劣的“破窗户”（低劣的设计，错误的决策，或是糟糕的代码）不修，发现一个就解决一个，如果没有足够的时间进行适当的修理，就用木板把它订起来，或许你可以把出问题的代码放入注释（comment out），或是显示“未实现”消息，或是用虚设的数据（dummy data）加以替代。采取某种行动防止进一步的损坏，并说明情况处于你的控制之下。

置之不理会使软件更快的加速腐烂的进程。

灭火

作为对照，让我们讲述Andy的一个熟人的故事，他是一个富的留油的富翁，拥有一所完美的，漂亮的房子，里面是无价的古董，艺术品，以及诸如此类的东西。有一天，一幅挂毯挂的离他的卧室太近了，着了火，消防人员进来灭火–和他的房子 但他们拖着粗大的水管到房门口停住了–火在咆哮，他们要在前门和着火处铺上垫子。他们是不想弄脏地毯。

这是一个极端的例子，但是我们对待软件的态度应该如此，如果你发现你所在的团队和项目的代码十分漂亮–编写整洁，设计良好，并且还很优雅–你就很可能会格外注意不去弄脏他，即使有火在咆哮（最后期限，发布日期，会展等），你会不想成为第一个弄脏他的人。

挑战：

• 通过调查你周围的计算“环境”，帮助增强你的团队的能力，选择“两三扇破窗” ，与同事进行讨论问题何在，以及如何修复他。
• 你能说出某扇窗是何时破的？你的反应是什么？如果是其他人的决策所致，或者是管理部门的指示，你是如何处理的？

3.石头汤和煮青蛙

三个士兵从战场返回家乡，在路上饿了。他们看到前面有村庄，就来了精神，他们相信村民会给他们一顿饭吃。但他们到达那里，却发现门锁着，窗户也关着。经历了多年战乱，村民们粮食缺乏，并把他们仅有的一点粮食藏了起来。
士兵们并不气馁，他们煮开一锅水，小心的把三块石头放了进去，吃惊的村民走出来望着他们。
“这是石头汤”士兵解释说。“就放石头吗？”村民们问。“一点也没错–但有人说加一点胡萝卜味道会更好”一个村民跑开了，又很快带着他储存的一些胡萝卜回来了。
几分钟后又有村民问：“就这些了吗？”。
“哦”士兵们说。“几个土豆会使汤的味道更好。”又一个村民跑开了，回来带着他的土豆。
再接下来的一个小时内，士兵列举了更多让汤变得更鲜美的配料：牛肉、韭菜、盐还有香菜。
每次都有一个村民拿出自己私自藏的私人物品。
最后他们煮出一锅鲜美的热气腾腾的汤。士兵们拿掉石头，和所有村民一起享用了一顿美餐。这也是几个月内他们所有人第一次吃饱饭。

士兵充当催化剂，把村民们团结起来，和他们一起做到了他们自己本来做不到的事——一项协作的成果，最后大家都成为了成功者。

在有些情况下，你也许确切地知道需要做些什么，以及如何去做。整个系统就在你眼前——你知道他是对的。但请求许可时你会遭到拖延和漠然。大家要设立委员会，预算需要批准，事情会变得复杂。每个人都会护卫他们自己的资源，有时候，这被称作启动杂役。
这正是拿出石头的时候，设计出你可以合理要求的东西，好好开发它。一旦完成。就拿给大家看看，让他们大吃一惊。然后说：“要是我们增加…可能会更好。”假装那并不重要。坐回椅子上，等着他们开始要你增加你本来就想要的功能。人们发现，参与正在发成的成功要更容易些。让他们瞥见未来。让他们聚集到你周围。
做变化的催化剂。

村民的角度

另一方面，石头汤的故事也是温和而渐进的欺骗的故事。它是讲述的是过于集中的注意力。村民想着石头忘却了世界的其他部分。我们都是这样。每一天事情会悄悄爬在我们身上。

我们都看见过这样的症状。项目慢慢地，不可改变的完全失控。大多数软件都是从微不足道的小事情开始的，大多数项目的拖延都是一天一天的发生的，系统一个特性一个特性的偏离其规范，一个又一个补丁被打到某段代码上。知道最初的代码一点也没有留下，常常是小事情的累积破坏了事情和团队。
记住大景图
我们没有做过这些——有人说过，如果你抓一只青蛙放在沸水中，它会一下子跳出来。但是把青蛙放在冷水中，然后慢慢加热，青蛙不会注意到温度的变化，会呆在锅中，一直被煮熟。

注意青蛙问题和前面的破窗户问题不同，在破窗户问题中，人们失去与熵战斗的意愿，是因为他们觉察到没有人会在意，而青蛙只是没有注意到变化。
不要像青蛙那样，而要留心大景图，要持续观察周围发生的事情，而不只是你自己在做的事。

4.足够好的软件

欲求更好，可能把好事变糟。——李尔王
有一个古老的笑话，说一家美国公司向一家日本制造商订购了100000片集成电路，规格上说明有次品率：一万片中只能有1片，几周后订货到了：一个大盒子内里面装着数千片IC，还有一个小盒子，里面装着10片IC，在小盒子上写着这些是次品。
要是我们真能这样控制质量就好了。但现实世界不会让我们造出十分完美的产品，特别是不会出错的软件。时间、技术和急躁都在合谋反对着我们。
但是，这并不一定让人气馁。如Ed Yourdon 在IEEE上发表的一篇文章，你可以训练自己，编写出足够好的软件——对你的用户、对未来的维护者、对自己内心的安宁来说足够好，你就会发现，你变得更多产，而你的用户也会变得更高兴，你也许会发现，因为“孵化期”更短，你的程序实际上会更好了。
在继续前进前，我们要对足够好进行限定、短语“足够好”并非意味着不整洁或者糟心的代码。所有系统必须满足其用户的需要，才能取得成功，我们只是在宣扬，应该给用户机会，让他们参与决定你做的东西何时已足够好。

让你的用户参与权衡

通常你是为别人编写软件。你尝尝需要从他们哪里获取需求、但你是否常问他们、他们想要的软件有多好？有时并不存在。如果你的工作对象是心脏起搏器、航天飞机、或者被广泛传播的底层库、需求就会更加苛刻，你的选择就会更有限。 但是你工作的对象是全新产品，你就会有不同的约束，市场人员有需要信守的承诺，最终用户也许已基于交付时间表制定了各种计划，而你公司有现金流的方面的约束，无视这些用户需求，一味地给程序增加新的特性，或是一次又一次的润饰代码。这不是有职业素养的做法。我们不是在提倡慌张：许诺不可能兑现的时间标度，为赶最后的期限而削减基本的工程内容，这样同样也不是有职业素养的做法。

知道何时止步

在某些方面，编程就像绘画。你从空白的画布和基本的原材料开始，通过知识，艺术和技艺的结合去确定前者做些什么。你勾画出全景，绘制背景，然后填入各种细节。你不时地后退一步，用批判的眼光观察你的作品。常常，你会扔掉画布，重新再来。
但艺术家们会告诉你，如果你不懂得何时止步，所有的辛苦劳作就会遭到毁坏，如果一层又一层，细节复细节反复的添加，绘画就会迷失在绘画之中。
不要因为过度修饰和过于求精而损毁完好的程序。继续前进，让你的代码凭借着自己的质量站一会儿。它也许不完美，但不用担心：它不可能完美。

5.你的知识资产

知识上的投资总能得到最好的回报
——本杰明 富兰克林
哦，好样的老富兰克林——从不会想不出精炼的说教，为什么，如果我们能够早睡早起，我们就是了不起的程序员——对吗？早起的鸟儿有虫吃，但早起的虫子呢？
然而在这种情况下，Ben确实命中了要害，你的知识和经验是你最重要的职业财富。
遗憾的是，他们是有时效性的财产，随着新技术的、语言及环境的出现，你的知识会变得过时，不断变化的市场驱动力也许会使你的经验变得陈旧或者无关紧要，考虑到“网年”的飞逝速度，这样的事情可能会非常快的发生。
随着你知识价值的降低，对你的公司和客户来说，你的价值也在降低，我们想要阻止这样的事情，绝不能让他发生。

你的知识资产

我们喜欢把程序员所知道的关于计算技术和他们所工作的应用领域的全部事实、以及他们所工作的应用领域的全部事实、以及他们的所有经验视为他们的知识资产。管理知识资产与管理金融资产十分类似：

1. 严肃的投资者定期投资——作为习惯
2. 多元化是长期成功的关键
3. 聪明的投资者在保守的投资和高风险、高回报的投资之间平衡他们的资产。
4. 投资者设法低买高卖、以获取最大回报
5. 应周期性的重新评估和平衡资产

要在职业生涯中获得成功，你必须运用同样的指导方针管理你的知识资产。

经营你的资产

定期投资
就像金融投资一样，你必须定期为你的知识资产投资、即使投资量很小，习惯自身也和总量一样重要。
多元化
你知道的不同的事情越多，你就越有价值。作为底线，你需要知道你目前所用到的特定的技术的各种特性。但不要就此止步。计算技术的面貌变换很快——今天的热门技术明天就可能变得近乎无用（或至少不再抢手）、你掌握的技术越多，你就越能更好的调整，赶上变化。
管理风险
从高风险、可能有高回报，到低风险、低回报，技术存在于这样一条谱带上，把所有的金钱都投入可能突然崩盘的高风险股票并不是一个好注意；你也不应太保守，错过可能的机会。 不要把你所有的技术鸡蛋放在一个篮子里。（这里指的是一些技术，和基础的底层知识无关，那些就是你敢玩这些的基础，是入门的基本券。）
低买高卖
在新兴技术流行之前学习它可能就和找到被低估的股票一样困难，但所得到的收益也一样，Java刚出来就学习它可能有风险，但对于现在已经步入该领域的顶尖行列的早期采用者，这样做得到了非常大的回报。
重新评估和平衡
这是一个非常动荡的行业，你上月开始研究的热门技术现在也许已经像石头一样冰冷了。也许你需要重温你有一阵子没有使用的数据库技术，又或是，如果你之前试用过另一门语言，你就更有可能获得那个职位…
在这些指导方针中，最简单也是最重要的就是：
定期为你的知识资产投资

目标

关于何时以及增加什么到你的知识资产中，现在你已经拥有了一些指导方针，那么什么是获取智力资本，从而为你资产提供资金的最佳方式？这有一些建议。
每年至少学习一种新的语言
不同语言以及不同的方式解决相同的问题。通过学习若干不同的方法，可以帮助你拓宽你的思维，并避免墨守成规，此外，现在学习许多语言已经容易了许多，可以从网上自由的获取软件财富。
每季度阅读一本技术书籍
书店里摆满了许多书籍，讨论与你当前项目有关的有趣话题。一旦你养成习惯，就一个月读一本书，在你掌握你正在使用的技术之后，扩宽范围，阅读一些与你项目无关的书籍。
也许阅读非技术书籍
记住计算机时由人——你在设法满足其需要的人——使用的，这十分重要，不要忘记等式中人的这一边。
上课
在本地的学院或者大学、或者将要来临的下一次会展上寻找有趣的课程。
参加本地用户组织
不要只是去听讲，而是主动参加，与世隔绝对你的职业生涯来说是致命的；打听一下你们公司以外的人都在做什么。
试验不同的环境
如果你只在Windows上工作，就在家里玩一玩Unix,如果你只用过makefile和编辑器，就试一试IDE，反之亦然
跟上潮流订阅商务杂志和其他期刊，选择所覆盖的技术与你当前的项目不同的刊物。
上网想要了解某种新语言或其他技术的各种特性？要了解其他人的相关
经验，了解他们使用的特定的行话，等等，新闻组是一种很好的方式

学习的机会

于是你狼吞虎咽地阅读，在你的领域，你站在了所有突破性进展的前沿（这不是容易的事）。有人向你请教一个问题。答案是什么？你连最起码的想法都没有。你坦诚的承认了这一点
不要就止步于此，把找到答案视为对你个人的挑战：去请教Google去请教百度。
如果你自己找不到答案，就去找能找到答案的人，不要把问题搁在那里，与他人交谈可以帮助你建立人际网络，而因为在这个过程中找到了其他不相关问题的解决方案，你也许会大吃一惊。旧有的资产也在不断增长…
所有阅读和研究都需要事件，虽然事件已经很短缺，但是必须预先规划，让自己在空闲的片刻事件总有东西可读，花在等医生的时间是抓紧阅读的好机会——但一定得带上自己的杂志（也就是说是自己有计划的内容），否则则是无用功。
总结：
抓住空闲时间、学习要有计划、学习要坚持、对待没有做过的问题要请教他人。

批判的思考

最后一个要点是，批判地思考你读到的和听到的。你需要确保你的资产中的知识是准确的，并且没有受到供应商或媒体炒作的影响。
批判地分析你读到的和听到的

6.交流

我相信，被打量比被忽略要好。
没有交流，就算你拥有最好的主意、最漂亮的代码、或是最注重实效的想法、最终也会毫无结果。
没有有效的交流，一个好想法就只是一个无人关心的孤儿
作为开发者，我们必须在许多层面上进行交流。 我们把许多小时花在开会，倾听和交流上，我们与最终用户一起工作，设法了解他们的需求，我们编写代码，与机器交流我们的意图；把我们的想法变成文档，留给以后的开发者。我们撰写提案和备忘录，用以申请资源并证明其正当性、报告我们的状态、以及提出各种新的方法。我们每天在团队中工作，宣扬我们的主意、修正现有的做法、并提出新的做法，我们的时间有很大一部分都花在交流上，所以我们需要把它做好
知道你想要说什么
在工作中使用的更为正式的交流方式中，最困难的部分也许是确切地弄清楚你想要说什么，小说家在开始写作之前，会详细地构思情节，而撰写技术文档地人却常乐于坐在键盘前，键入“1.介绍…”,并开始敲入接下来在他们地头脑里冒出来地任何东西
规划你想要说地东西，写出大纲，然后问自己：“这是否讲清了我要说地所有内容？” 提炼它，直到确实如此为止。
这个方法不只适合撰写文档 当你面临重要会议、或是要与重要客户通电话时，简略记下你想要交流地想法，并准备好几种把它们讲清楚地策略。
了解你的听众
只有当你是在传递信息时，你才是在交流。为此，你需要了解你的听众的需要、兴趣，能力 我们都曾出席过这样的会议:一个做开发的滑稽人物在发表长篇独白，讲述某种神秘技术的各种优点，把市场部副总裁弄得目光呆滞，而只是空谈，让人厌烦的空谈。
要在脑海里形成一幅明确的关于你的听众的画面。
选择时机
这是星期五的下午六点，审计人员进驻已有一周，你的老板最小的孩子在医院里，外面下着滂沱大雨，这时开车回家肯定是一场噩梦。这大概不是向她提出PC内存升级的好时机。
为了了解你的听众需要什么先弄清轻重缓急
选择风格
调整你的交流风格，让其适应你的听众，有人要的是正式的"事实"简报 另一些人喜欢电子邮件 或备忘录 ，有人喜欢一句话讲清楚
让文档美观
你的主意很重要，它们应该以美观的方式传递给你的听众。
太多程序员在制作书面文档时只关心内容，我认为这是一个错误。任何一个厨师都会告诉你，你可以在厨房里忙碌几个小时，最后却会因为饭菜糟糕的外观而毁掉你的努力。
让听众参与
我们常常发现，与制作文档的过程相比，我们制作出的文档最后并没有那么重要，让你的读者参与文档的早期草稿额制作， 获取他们的反馈，并汲取他们的智慧，你将建立良好的工作关系，并很可能在此过程中制作出更好额文档。
做倾听者
如果你想要大家听你说话，你必须使用一种方法：听他们说话 即使你掌握着全部信息，即使那是一个正式会议，你站在20个衣着正式的人面前——如果你不停他们说话，他们也不会听你说话。
鼓励大家通过提问来交谈。
回复他人
如果你向别人提问，他们不做出回应，你会觉得他们不礼貌，但当别人给你发送电子邮件或备忘录、请你提供信息，或是采取魔种行动时，你是否忘记回复？ 即使再忙也要回一句”我稍后回复您“