《程序员修炼之道》读书笔记
注重实效的哲学
这一章中，作者从六个相互独立的主题来阐述程序员应该从哪几个方面来注重实效，为注重实效的哲学奠定了基础。
责任
注重实效的程序员对他/她自己的职业生涯负责，并且不害怕承认无知和错误。
责任是你主动负担的东西。你承诺确保某件事情正确完成，但你不一定能直接控制事情的每一个方面。除了尽你所能以外，你必须分析风险是否超出了你的控制。对于不可能做到的事情或者风险太大的事情，你有权不去为之负责。你必须基于你自己的道德准则和判断来做出决定。
如果你确实同意要为某个结果负责，你就应切实负起责任。当你犯错误、或者判断错误时，诚实地承认它，并设法给出各种选择，而不是选择去责备别人或别的东西、或者拼凑借口。
在你走向任何人，告诉他们为何某事做不到、为何耽搁、为何出问题之前，先停下来，听一下你心里的声音。在你的头脑中把谈话预演一遍。其他人可能会说什么？你将怎样回答？在你去告诉他们坏消息之前，是否还有其他你可以再试一试的办法？有时，你其实知道他们会说什么，所以还是不要给他们添加麻烦吧。
软件的熵
熵，指的是系统中的“无序”的总量。在热力学定律中，保证了宇宙中的熵倾向于最大化，而在相似的环境中，当软件正在无序、野蛮的增长时，程序员称之为“软件腐烂”。
破窗户理论：一扇破窗户，只要有那么一段时间不去修路，就会渐渐给建筑的居民带来一种废弃感——一种职权部门不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂图画。严重的结构损坏开始了。在相对较短的一段时间里，建筑就被损毁得超出了业主愿意修理的程度，而废弃感就成了现实。
从“破窗户理论”中，我们可以得知，当项目中出现了类似于低劣的设计或者糟糕的代码，倘若程序员不及时去修复时，放着不管，就容易使得负责该项目的人员产生一种随意感，这样做的后果往往会是项目失败的一个较大的原因。
所以，在项目开始时，不要留着”破窗户”不修。发现一个就修复一个。如果没有足够的时间进行适当的修理，就做一个 to-do-list，亦或者在问题的代码上放入具有警示性的注释，亦或者用虚设的数据（dummy data）加以替代。采用某种行动防止进一步的损坏，并说明情势仍处于你的控制之下。
若项目中的每个人员都注重于自身设计的简约，代码的工整，使得项目的结构合理得体，那么身为项目中的一员的你也不愿意去玷污这个工程，即使在项目的最后期限（deadline），也不愿成为第一个弄脏东西的人。
石头汤与青蛙
这一章中的故事主要讲述了三个士兵利用人的好奇心，用石头汤换来一顿美味的大餐。
从士兵的角度思考整个故事
士兵的角度解析这篇故事有两层寓意。士兵戏弄了村民，他们利用村民的好奇，从他们那里弄到了食物。但更重要的是，士兵充当了催化剂，把村民们团结起来，和他们一起做了他们自己本来做不到的事情。
在有些情况下，你也许确切地知道需要做什么，以及怎么样去做。整个系统就在你的眼前——你知道它是对的，但请求许可去处理整个事情，你会遇到拖延和漠然。每个人都会护卫他们自己的资源，不轻易去协助，甚至让步。
这正是拿出“石头”的时候。设计出你可以合理要求的东西，好好开发它。一旦完成雏形之时，可以与人分享，引起他们兴趣，人就自然而然会来帮助你。人们发现，参与正在发生的成功要更容易。让他们瞥见未来，你就能让他们聚集在你周围。
从村民的角度思考整个故事
从故事中，我们知道村民们注意力过度集中，只想着石头，而忘却了自己身处的环境（贫困饥饿）。这种事情就好比温水煮青蛙一般，程序员如果没有观察到项目中的细小变化，而被一些微不足道的事情逐步侵蚀，最终的后果是灾难性的。
在项目开发中，不要像温水中青蛙一样。要留心大局（big picture）。要持续不断地观察周围发生的事情，而不只是你自己在做的事情。
足够好的软件
欲求更好，常把好事变糟。 —— 李尔王
在现实世界中，我们无法制作出完美的产品，特别是没有任何差错（bug）的软件。但是我们可以训练自己，编写出足够好的软件——对你的用户（功能）、对未来的维护者（文档）、对你自己内心的安宁（满足）来说足够好。
在编写软件的过程中，我们应当接纳用户的各种各样的意见，让他们参与权衡之中。无视用户的需求，一味地给程序增加新特性，闭门造车，或是一次又一次润饰代码，这不是有职业素养的做法。
在项目开发过程中，我们应该将项目的范围与质量作为项目需求的一部分规定下来，使之成为需求问题，一步步满足完善。但是同时，我们也不该过度修饰和过于求精而损毁完好的程序。继续前进，让你的代码凭着自己的质量（高可用）站立。它也许不完美，但你也不用担心，它不可能完美。
你的知识资产
在程序员的职业生涯中，知识和经验是你重要的职业财富。遗憾的是，它们是有时效的资产（expiring asset）。随着新的技术、语言及环境的出现，你的知识可能会变得过时。不断变化的市场驱动也许会使你的经验变得陈旧或无关紧要。随着你的知识的价值降低，对你的公司或者你的客户来说，你的价值也在降低。
作为程序员，我们将所知道的关于计算技术和他们所工作的应用领域的全部事实，以及他们的所有经验视为他们的知识资产。管理知识资产与管理金融资产非常相似：
严肃的投资者定期投资。
就像金融投资一样，你必须定期地为你的知识资产投资。即使投资量很小，习惯自身也和总量一样重要。可以通过几种途径累积自己的资本：
- 每年至少学习一种新语言。不同语言以不同的方式解决相同的问题。通过不同的语言，有助于拓宽思维，并避免墨守成规。
- 每季度阅读一本技术书籍。起码至少一个月读一本书。
- 也要阅读非技术书籍。
- 上课。
- 试验不同的环境。
- 跟上潮流。了解时事，抓紧下一次流量窗口。
多元化是长期成功的关键。
你知道的不同的事情越多，你就越有价值。作为底线，你需要知道你目前所用的特定技术的各种特性。但不要就此止步。计算技术的面貌变化地很快——今天热门技术明天就可能变得近乎无用。
聪明的投资者在保守的投资和高风险、高回报的投资之间平衡他们的资产。
从高风险、可能有高回报，到低风险，低回报，技术存在于这样一条谱带中。把你所有的金钱都投入到可能突然崩盘的高风险股票并不是一个很好的主意；你也不应太过于保守，错过可能的机会。不要将你所有的技术鸡蛋放在一个篮子中。
投资者设法低买高卖，以获得最大回报。
在新型的技术流行之前学习它可能就和找到被低估的股票一样困难，但所得到的就会像那样的股票带来的收益一样。
应周期性地重新评估和平衡资产。
充分评估自身所拥有的资产（技术栈），并不断地丰富自己的技术栈，有助于自身的发展。
批判地思考你读到的和听到的。
所见非所得，你需要对不同途径获取的信息，进行批判性地思考，对接受的内容持有怀疑态度，直至被自己证实。
交流
作为开发者，我们必须在许多层面上进行交流。我们把许多小时花在开会、倾听和交谈上。我们与最终用户一起工作，设法了解他们的需要。我们编写代码，与机器交流我们的意图；把我们的想法变成文档，留给以后的开发者。我们撰写提案和备忘录，用以申请资源并证明其正当性、报告我们的状态、以及提出各种新的办法。我们每天在团队中工作，宣扬我们的主意、修正现有的做法、并提出新的做法。我们的时间有很大一部分都花在交流上，所以我们需要把它做好。
知道你想说什么。
规划你想要说的东西。写出大纲。然后问你自己：”这是否讲清了我要说的所有内容？“提炼它，直到确实如此为止。
了解你的听众。
只有当你是在传达令人能够理解的信息时，你才是在进行交流。为此，你需要了解你的听众的需要、兴趣、能力。要在脑海里形成一幅明确的关于你的听众的画面。
| WISDOM | 译文 |
|---|---|
| What do you want them to learn? | 你想让他们学到什么？ |
| What is their interest in what you’ve got to say? | 他们对你讲的什么感兴趣？ |
| How sophisticated are they? | 他们有多少经验？ |
| How much detail do they want? | 他们想要多少细节？ |
| Whom do you want to own the information? | 你想要让谁获得这些信息？ |
| How canyou motivate them to to listen to you? | 你如何使他们听你说话？ |
选择时机。
为了了解你的听众需要听什么，你需要弄清楚他们的”轻重缓急“是什么。要让你所说的适得其时，在内容上切实相关，满足听众需求。
选择风格。
调整你的交流风格，让其适应你的听众。有人要的是正式的会议简报。另一些人喜欢在进行正题之前高谈阔论一番。
让文档美观。
你的主意固然重要，但是结构良好，思路清晰的文档更容易地让听众接受。
让听众参与。
在项目开发过程中，在尽可能的情况下，让你的读者参与到文档的早起草稿的制作。获取他们的反馈，并汲取他们的智慧。你将建立良好的工作关系，并很可能在此过程中制作出比原先更好的文档。
做倾听者。
如果你想要大家听你说话，你必须使用一种方法：听他们说话。在正式会议中，即使你掌握着全部信息，倘若你只管你自己讲话，是没有任何听众愿意听你讲话的。
鼓励大家通过提问来交谈，或者让他们总结你告诉他们的东西。把会议变成对话，你将能更有效地阐述你的观点。
回复他人。
及时、随时回复他人，会让他们更容易原谅你偶然的疏忽，并有助于维持一段较为良好的关系。