关于效率、程序与生活的一些思考

IT客你是第1813个围观者 0条评论供稿者：zhaorong 标签：效率, 程序

前一段时间看了两本书《高效程序员的45个习惯——敏捷开发修炼之道》和《高效能程序员的修炼》。书名很相似，读完这两本书花的时间也差不多，都是两个星期左右。两本书内容差别却不小。不过，总结起来一句话：都是好书！

“变”——读《高效程序员的45个习惯》所想到的

《高效程序员的45个习惯》原名Practices of an Agile
Developer，所以这本书主要是讲敏捷开发方法与实践的。由于对团队和协作没什么清晰的概念，而且书中大多是以团队开发为实例的，看完以后有好多地
方没太明白。所以，这本书不太适合大一的读，估计我还需要两年后再读一次。

但是还是有很多收获的，作者Andy Hunt和Venkat Subramaniam在书中传授了很多敏捷开发的思想，不但适用于团队，而且对独立开发者也有很大借鉴意义。在这里总结一下：

不管路走了多远，错了就要重新返回——要快速适应变化。
开发要持续不断，切勿时续时断。
态度决定一切。
指责不能修复bug——出现了问题以后，首先要做的不是追究责任，而是解决问题。（原文更经典一些：Blame doesn’t fix
bugs. Instead of pointing fingers, point to possible solutions. It’s the
positive outcome that counts. ）
过程符合标准不意味着结果是正确的。结果重于过程（“结果不重要”向来都是说给失败者的）。
如果你没有犯过任何错误，说明你可能没有努力工作。
你不需要很出色才能起步，但是你必须起步才能变得很出色。——Les Brown
能容纳自己并不接受的想法，表明你的头脑足够有学识。——亚里士多德
如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。——约翰·冯·诺依曼
代码清晰程度的优先级应该排在执行效率之前。
跟踪技术变化。
习惯很可能造就一个专家，但同样也能毁了这个专家（自己想的，有点扯）——打破旧习惯很难，更难的是自己还没有意识到这个问题。
选定了要走的路，就是选定了它通往的目的地。

虽然这是一本关于项目开发方法的书，作者也通篇在讲开发中需要注意规避和正确的做法与心态，但是我却从中看到了更多程序以外的东西。

作者在第一章就总结说，敏捷开发要不断地使用反馈进行自我调整和完善。这句话真的很好，只有不断的调整和完善才能跟上技术和设计的步伐，不至于项目

交付时拿出来的是一个脱离了潮流甚至充满错误设计的东西。其实对生活也是这样。经常总结自己，当发现生活偏向某个极端时，就做一下调整，就像航海时发现偏

离航线了要及时调整航向一样，否则因为反应迟钝带来的痛苦与损失是要付出很多代价的，而且付出的代价往往与问题发现的时间成正比。越早发现问题，就越容易
修复问题。

管理大师德鲁克说∶“世界唯一不变的是变化。”真正的敌人是变化，而且你不可能打败变化，你所能做的就是适应变化。看完这本书，个人感觉，其实就一

个字就能把这本书想说的敏捷开发给概括，那就是“变”。如果能在变化中使自己变化以适应变化，见机行事，随机应变，你就达到了“敏捷”（相关内容可以看我
之前写的All Over Again）。

另外，书中《使用短迭代，增量发布》一文给我留下很深印象。短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。严格的最终期限迫使
你做出一些艰难的决策，没有遗留下长期悬而未决的问题。如果每个迭代时间都不够用，要么是任务太大，要么是迭代的时间太短。把握好自己的节奏。

重构生活

你要不断从自己写的代码中得到反馈，并且使用自动化工具不断地构建和测试系统。在前进的过程中，你都会有意识地修改一些代码：在功能不变的情况下，重新设计代码，改善代码质量。这就是所谓的重构。

当你把这段话中的“代码”换成“生活”时，你会发现它同样是对的。所以，就像团队需要隔段时间重构自己项目的某些代码以减少bug、精简代码一样，你也要学会重构自己的生活，来提高生活质量。

所以说，世界著名程序员中有很多是哲学家_自己想的。

你所需要的仅仅是一个新的习惯。

“快乐”与“热情”——《高效能程序员的修炼》教给我的

另一本，是Stack Overflow创始人之一Jeff Atwood的《Effective Programming: More Than Writing Code》。这本书类似于《黑客与画家》，文章主要取自作者的博客CodingHorror。看完之后，与上一本不同的是，这本书浅显易懂，而且处处体现出作者积极向上的幽默，通过各种实例，阐述了自己对程序员应有的态度、学习方法、技能的看法，最后还谈到了职业规划和程序员的幸福，很适合初级程序员和学生读。

下面是我对书中主要内容的一些笔记（主要是自己总结的，想了解更多还是去看书吧）：

问自己：“你究竟想过怎样的生活？”
人们需要花一生的时间去学习如何有效地写作。而且这事没有捷径。
程序员应该通过读书或阅读博客来磨快自己的“锯子”。
避免同时做多个项目，不要高估自己的能力。
出现问题时，尽量认为是自己的错。
自己是阻止自己进步的罪魁祸首。
就像不要写没用的代码一样，不要写没用的注释。
当你需要写注释的时候，先看看自己能不能把代码写得更易懂一些。
学会阅读源代码，不管是自己的还是别人的。
对于创意来说，执行是一个增倍器。它能放大创意的价值，甚至更多。（闲扯一下，你如果在07年之前说你有一个关于手机的棒极了的点子：它有
一个智能系统，可以装应用；还有一个触摸屏，可以用手触摸，还可以用多个手指！这个点子真是太棒了，好，给你10块钱上一边去！因为这只是个点子，不是
iPhone）
性能是成功产品的必备属性。对一个网站来说，要么很快，要么死去。
很多程序员不会编程。Are you one of them?
软件开发者最擅长的就是学习。
工作经验年数与编程技能之间是没有必然联系的。
不管出了什么问题，都是人的问题。
程序员就像“吸血鬼”，而系统管理员就像是“狼人”。（很有意思的比喻，可以看这篇博客Vampires (Programmers) versus Werewolves (Sysadmins)）
尝试结对编程。（与作者在书中的观点不太一样，作者是结对编程的忠实拥护者）
会议是浪费工作时间的绝佳去处。（加入学生会的人应该深有感触）
高效的程序员都有绝佳的工作环境。（这一点很重要）
程序是所有微小细节的集合，而细节决定成败。
难以使用本身就是一个大bug。
第一版做的不好，但照样发布。
倾听用户的声音，但别被他们牵着鼻子走。
……最难的事，要搞明白你没日没夜地拼命工作到底是为了什么。

提问的艺术——你喜欢问“为什么”，这很好。但你为什么问”为什么”?

两本书都提到了一点，在问“为什么”之前，一点要想好自己为什么问这个问题。当你问“为什么“的时候，也许你会被反问：“为什么你问这个问题？”所以在提问之前，想好你提问的理由，这会有助于你问出恰当的问题。

在提问之前，一定要确定：

问题是什么？
你为这个问题做了什么尝试？
你为什么需要答案？

归根结底，这关乎公平：如果你想要别人花上宝贵的时间来帮助你，只有在你也花了相当的宝贵时间酝酿出一个合格的问题时才算公平。帮助别人就是帮你自己！

如果你能完全投入地向一个假想中的人或者是没有生命的物体问一个透彻而详尽的问题，你往往会在最后认识到你犯了某中愚蠢的错误，于是问题不再是问题，你也因此如释重负。

如果你读到这里了，强烈建议你看下这篇Rubber Duck Problem Solving

唯快不破

“沿着那条路走下去，一定要快。如果有什么东西挡住了你的去路…绕开它！”

其实，作者在建立Stack Exchange时也用到了敏捷方法，而且“快”是Stack Overflow的制胜法宝。第一版做的不好，但照样发布，然后在不断的用户反馈中获得灵感与思路，在快速迭代中完善产品。

idea就是shit

在国内App创业浪潮中，很多人都强调了创意的重要性，甚至认为有了一个想法（先不说它的好坏）就有了一点，整天把“idea”挂在嘴边，认为自己

就是下一个乔布斯。但其实idea一文不值，重要的是去实现它。因为你要相信，你能想到的，别人也能想到（同样先不说它的好坏），但你能做到的，别人不一
定能做到。

如何应对初见成功后出现的复制品

当遇到自己产品的复制品时，该怎么做呢？很多人发现有类似自己的网站或是模仿自己的App上线时，都变得很疯狂，在各种社区、论坛或是问答网站表达

无奈和委屈，以博得同情，或是大骂山寨者，引起众怒。但其实这一点用也没有，当你在哭爹喊娘的时候别人已经超过你了。我现在还没听说哪个开发者把山寨货告
上法庭并打败对方的事。看看Jeff在面对Stack Overflow的复制品时是怎么做的，

现在市面上已经出现了一些Stack
Overflow引擎的复制品。我想说他们干的不错！……我们的使命是让互联网变得更好（哪怕我们只能带来一些细微的改进）。……我们没曾想过要推翻谁或
者占有什么东西。所以在这个过程中，如果有任何东西挡住了我们的路，请放心，我们不会大打出手。我们会绕开。然后继续向前，快速进步。因此，如果那些抄袭者想要跟上我们的话，他们也得行动快点。

懂了吗？就是一个字——“快”。只有比你的对手快，你才能打败那些山寨者。Chrome为什么会在短短几年打败IE（但人家仍是市场份额老大）和Firefox，就是因为它极速的迭代速度。

前几天在知乎上看到有人问“如何在国内盗版横行的Android市场上存活”，我是这样回答的