最近看了一本书,叫做 《 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,你可以不断的去突破你的想象力,我们一直相信『天空才是你的极限!』,如果你愿意加入,欢迎联系 [email protected] 。
1
Ge4Los 2019-11-24 19:45:07 +08:00 1
涉及到成长型思维的书应该是 《终身成长》 这本,《终生成长》是另外一本。
|
2
qiuyesuifeng OP @Ge4Los 感谢指正:)
|