如何成为高效率的工程师

最近看了一本书，叫做《 The Effective Engineer 》，中文名翻译过来大概就是《高效率工程师》这种吧。收益良多，决定写一下读书笔记，因为书里面的 Engineer 大部分指的就是从事开发的程序员，所以后面我多数会用研发，程序员来表示了。

选择正确的思维模式

关注高杠杆率事项

阿基米德曾经说过『给我一个支点，我能翘起地球』，当然，这话他到底说过没有，我们先不纠结，这里要表述的意思很明确，就是杠杆的力量。对于高效率来说，可以用如下的公式来表示：

杠杆 = 产生的影响力 / 投入的时间

作为一个工程师，要做高效率的事情，自然将事情做到高杠杆率，做法就可能有三种：

减少完成这件事情的时间
提升这件事情的影响力
切换到另一个有更高杠杆率的事情上

上面列出来的几个方法，已经非常的直白容易实施了，譬如对于数据库的优化，我们可以这么做：

使用更好的工具来定位性能问题，如常用的 perf，VTune 这些，减少定位性能问题的时间。
深刻的理解 workload，知道哪些请求是高频率的，或者哪些请求是最消耗资源的，解决这些大头问题。
发现搞不定，让业务去调整代码，譬如加个索引啥的，短期不做无谓的优化了。

优化学习方式

俗话说，活到老，学到老，我们其实需要不断的学习，不断去提升精进自己。不过要接受这个，首先得让我们具备成长型思维。大家应该的听说过固定型思维和成长型思维，没有的话可以看看《终生成长》这本书，大概了解一下。总的来说，就是我们需要构建一个成长型的思维模式，如何做这个，网上其实有很多方式，譬如：

承认并且接受自己的不完美
勇敢的面对挑战，视挑战为机会
尝试不同的学习策略
。。。。。。

当有了成长型思维之后，下一个要做的就是投资我们的学习率。大家应该都听过复利，在投资的早期，收益其实是很低的，但随着时间的推移，收益率会越来越高。其实学习也是类似的情况，所以越早学习，学得越多，后面学习新的东西就会越容易。

当然，对于工作的我们来说，最好的做法就是能在工作中学习，如果我们能加入一个快速成长的公司（譬如 PingCAP ），你在里面能接触各种各样有挑战的事情，能快速的学习成长。如果一个公司里面有很多牛人（再一次，譬如 PingCAP ），你也可以通过从他们身上学习到很多事情，譬如你可以看他们写的代码，或者让他们帮你去 review 你的代码，或者你的设计，这些都是能提升自己的方式。

当然，在工作之外，其实也是需要学习的，虽然很多人讲究生活和工作的平衡，但有时候，我还是希望大家能在业余时间多花时间来提升自己。我们可以多看几本书，多学习一门新的语言，这些都是能让我们变成一个更高效工程师的方式。

习惯优先排序

当我们开始关注高杠杆事情之后，自然会面对事情优先级的问题。这方面其实相关的书籍也不少，譬如著名的《高效能人士的七个习惯》这本书，就把事情分成了四象限：

象限 1 - 紧急 + 重要
象限 2 - 不紧急 + 重要
象限 3 - 紧急 + 不重要
象限 4 - 不紧急 + 不重要

我们自然要尽量去避免做象限 3 和 4 的事情，但有时候，我们会大量的精力去处理象限 1 的事情，但实际，我们最应该放精力的是象限 2，也就是重要不紧急的事情，这样才能让我们长期成长。

另外，在做事情的时候，我们还会面临一个问题，就是拖延，人都是有惰性的，要战胜惰性，有一个简单的方法可以试试，这个就是 if-then，如果我们要进行一项任务，可以在它之前设定一个场景开关，也就是如果发生了什么事情，那我就应该干这项任务了。这样没准能战胜拖延了。

执行，执行，执行

投资迭代速度

只有跑的更快，才能学习的更快，在这个世界上，唯一不变的只有变化。对于程序员，或者 team，或者公司来说，要让自己的效率更高，一个很重要的点就是：『工欲善其事必先利其器』。

工具对程序员的重要性毋庸置疑，但恰恰很多程序员忽略了工具的重要性，他们疲于开发，总觉得自己写得多就代表着效率高，但实际确是在不断的给自己挖坑。

PingCAP 可以算是一个非常重视工具的公司，我们相信能自动化用工具去解决的，绝对不依靠人力来弄，这样才能保证整个研发团队的高效率。譬如，我们研发了 Chaos 自动化测试平台，帮我们发现不少稳定性问题，引入了 Fuzzing 工具，来保证 SQL 的 logic 都能正确处理，这些工具很好的保证了我们整个产品的快速迭代。

那么对于程序员来说，除了有意识的要重视起工具，一些简单的方法也可以尝试：

更好的熟悉 IDE 的快捷键，毕竟打字的速度还是比移动鼠标快多了
学至少一门高级的脚本语言，来简化自己很多流程化工作。
熟悉并且掌握 shell，尤其是数据处理，通过 shell 比自己手工来搞方便太多
。。。。。。

当然，程序员不能只盯着自己的技术，在其他方面，也需要提升，只有全面发展了，才可以迭代的更快。这里可以看看《软技能：代码之外的生存指南》这本书，来学习如何提升自己的软技能。

测量我们想提升的事项

如果我们要迭代，一个自然的问题，就是如何衡量我们的迭代是有效的。这里，就可以使用最常用的办法 - metrics。

大家在做性能优化的时候，通常也会在一些关键的地方加上 metrics，然后通过 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 的事情，但恰恰研发是最应该懂测试的。