最近看了一本书，叫做 《 The Effective Engineer 》，中文名翻译过来大概就是《高效率工程师》这种吧。收益良多，决定写一下读书笔记，因为书里面的 Engineer 大部分指的就是从事开发的程序员，所以后面我多数会用研发，程序员来表示了。
阿基米德曾经说过『给我一个支点，我能翘起地球』，当然，这话他到底说过没有，我们先不纠结，这里要表述的意思很明确，就是杠杆的力量。对于高效率来说，可以用如下的公式来表示：
杠杆 = 产生的影响力 / 投入的时间
作为一个工程师，要做高效率的事情，自然将事情做到高杠杆率，做法就可能有三种：
上面列出来的几个方法，已经非常的直白容易实施了，譬如对于数据库的优化，我们可以这么做：
俗话说，活到老，学到老，我们其实需要不断的学习，不断去提升精进自己。不过要接受这个，首先得让我们具备成长型思维。大家应该的听说过固定型思维和成长型思维，没有的话可以看看《终生成长》这本书，大概了解一下。总的来说，就是我们需要构建一个成长型的思维模式，如何做这个，网上其实有很多方式，譬如：
当有了成长型思维之后，下一个要做的就是投资我们的学习率。大家应该都听过复利，在投资的早期，收益其实是很低的，但随着时间的推移，收益率会越来越高。其实学习也是类似的情况，所以越早学习，学得越多，后面学习新的东西就会越容易。
当然，对于工作的我们来说，最好的做法就是能在工作中学习，如果我们能加入一个快速成长的公司（譬如 PingCAP ），你在里面能接触各种各样有挑战的事情，能快速的学习成长。如果一个公司里面有很多牛人（再一次，譬如 PingCAP ），你也可以通过从他们身上学习到很多事情，譬如你可以看他们写的代码，或者让他们帮你去 review 你的代码，或者你的设计，这些都是能提升自己的方式。
当然，在工作之外，其实也是需要学习的，虽然很多人讲究生活和工作的平衡，但有时候，我还是希望大家能在业余时间多花时间来提升自己。我们可以多看几本书，多学习一门新的语言，这些都是能让我们变成一个更高效工程师的方式。
当我们开始关注高杠杆事情之后，自然会面对事情优先级的问题。这方面其实相关的书籍也不少，譬如著名的《高效能人士的七个习惯》这本书，就把事情分成了四象限：
我们自然要尽量去避免做象限 3 和 4 的事情，但有时候，我们会大量的精力去处理象限 1 的事情，但实际，我们最应该放精力的是象限 2，也就是重要不紧急的事情，这样才能让我们长期成长。
另外，在做事情的时候，我们还会面临一个问题，就是拖延，人都是有惰性的，要战胜惰性，有一个简单的方法可以试试，这个就是 if-then，如果我们要进行一项任务，可以在它之前设定一个场景开关，也就是如果发生了什么事情，那我就应该干这项任务了。这样没准能战胜拖延了。
只有跑的更快，才能学习的更快，在这个世界上，唯一不变的只有变化。对于程序员，或者 team，或者公司来说，要让自己的效率更高，一个很重要的点就是：『工欲善其事必先利其器』。
工具对程序员的重要性毋庸置疑，但恰恰很多程序员忽略了工具的重要性，他们疲于开发，总觉得自己写得多就代表着效率高，但实际确是在不断的给自己挖坑。
PingCAP 可以算是一个非常重视工具的公司，我们相信能自动化用工具去解决的，绝对不依靠人力来弄，这样才能保证整个研发团队的高效率。譬如，我们研发了 Chaos 自动化测试平台，帮我们发现不少稳定性问题，引入了 Fuzzing 工具，来保证 SQL 的 logic 都能正确处理，这些工具很好的保证了我们整个产品的快速迭代。
那么对于程序员来说，除了有意识的要重视起工具，一些简单的方法也可以尝试：
当然，程序员不能只盯着自己的技术，在其他方面，也需要提升，只有全面发展了，才可以迭代的更快。这里可以看看《软技能：代码之外的生存指南》这本书，来学习如何提升自己的软技能。
如果我们要迭代，一个自然的问题，就是如何衡量我们的迭代是有效的。这里，就可以使用最常用的办法 - metrics。
大家在做性能优化的时候，通常也会在一些关键的地方加上 metrics，然后通过 metrics 来衡量优化是否有效果，对于我们自己也是一样。当然，我们要先选对 metrics，毕竟错误的 metrics 反倒是会让我们变得更加不高效，譬如如果我们用每周工作时长来衡量一个程序员的产出，那么最后就会变成大家为了看起来产出高，而在工作的时候混日子，拖时间。要选择一个正确的 metrics，通常可以关注以下几个指标：
当我们有了计划，有了 metrics，自然就可以去执行，去实施，不过需要注意的是在实施的时候也需要时刻知道事情的进展，别偏离方向。我们可以使用工具来记录，譬如对于我们自己系统，可以使用 Prometheus 来保存 metrics，这样我们就能知道整个历史的变化了。
不过最重要的一点，就是记录的数据一定要是真是的，错误的数据甚至比没有数据还要糟糕，因为这可能会让我们进行错误的决策。
要迭代的更快，一个必要的事情就是要更快的去验证我们的想法。这里有一个词，叫做 MVP - Minimum viable product，也就是最小化的可行产品。我们需要很多小的工作，来收集数据，从而验证我们的假设和目标。
要对产品迭代，通常一个比较好的做法就是进行 A/B testing，同时建立起来完善的反馈循环，让我们知道每一次决定是不是对的。
对于工程师来说，还需要锻炼的一个能力就是项目评估技能，程序员向来喜欢高估自己的能力，低估事情的复杂度，项目时间通常预估不准，导致项目延期。所以我们需要使用更加精确的预估手段来推进项目，下面是一些可行的方案：
最后，无论我们选择了什么方案，一点需要注意的是，一定要给未知的东西预留时间，也就是要给自己留点 buffer，随时应变。
当我们评估完成时间之后，需要设置好清晰的计划，以及可衡量的里程碑，让我们尽量走在正确的道路上。这里几点要注意：
有时候，项目的快速发展跟品质是有冲突的，所以这里我们需要好好的平衡两者的关系。
首先，我们需要建立 code review 的文化，不允许大家随意的增加功能，随意的合并代码。虽然这个可能会影响产品进度，但好处不言而喻。在 PingCAP，我们有着严格的 code review 流程，一个程序员如果要开发一个新的功能，他需要提交 RFC，只有 RFC 被通过了，才能进行开发，当然，他也可以先自己做点原型验证，让 RFC 更容易被通过。每个 PR，我们至少需要两个人 review 并且 approve 才能 merge。
在代码层面，我们需要鼓励抽象，使用抽象来封装复杂的逻辑，保证代码容易学习，容易使用，容易扩展。代码的测试一定要跟上，一定要重视自动化测试，这个很多研发都不喜欢写测试，觉得那是 QA team 的事情，但恰恰研发是最应该懂测试的。
对于一个产品来说，易用性是非常关键的，我们一定要保证操作的简单，所以非常欢迎大家加入帮助我们一起来改进，如果你有任何易用性上面的问题，欢迎联系我。
当然，除了要关注产品价值，整个 team 也是要仔细考虑的，毕竟得先有人，才能做出来产品。要保证 team 不断的成长，所以我们需要建立一个不错的工程师文化，主要包括：
好了，说了这么多，我们一直在聊的是高效，上面只是我的一些对照书的简单总结。如果你能看到这里，我表示很佩服，因为现在要说重点的东西了。
作为一个程序员，高效是需要融入到自己骨子里面的，但是，很多同学一定会很苦闷到底如何才能变得高效？自然，一个很简单的办法就是加入一个高效率的公司。如果一个公司从上到下都是推崇的高效率工程师文化，待在里面，自然也就能潜移默化的变得高效了。很自豪的说，PingCAP 就是这样一家公司 :-)
不过，这里我还会更进一步，在 PingCAP 里面，有一只神秘的特种部队，天生是为高效而生的，它的名字就是 Effective Tool Team，简称 ET Team，没错，这个就是致敬 E.T. 外星人的。
在 ET team 里面，我们立足于使用最少的资源来解决最大的问题，也就是会关注于杠杆的那个支点。在 ET team，你会：
在 ET team，你可以不断的去突破你的想象力，我们一直相信『天空才是你的极限！』，如果你愿意加入，欢迎联系 tl@pingcap.com 。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.