V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
qiuyesuifeng
V2EX  ›  酷工作

如何成为高效率的工程师 && 召集志同道合的小伙伴

  •  
  •   qiuyesuifeng · 2019-11-24 19:26:15 +08:00 · 1611 次点击
    这是一个创建于 1586 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如何成为高效率的工程师

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

    选择正确的思维模式

    关注高杠杆率事项

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

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

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

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

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

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

    优化学习方式

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

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

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

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

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

    习惯优先排序

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

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

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

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

    执行,执行,执行

    投资迭代速度

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

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

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

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

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

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

    测量我们想提升的事项

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

    大家在做性能优化的时候,通常也会在一些关键的地方加上 metrics,然后通过 metrics 来衡量优化是否有效果,对于我们自己也是一样。当然,我们要先选对 metrics,毕竟错误的 metrics 反倒是会让我们变得更加不高效,譬如如果我们用每周工作时长来衡量一个程序员的产出,那么最后就会变成大家为了看起来产出高,而在工作的时候混日子,拖时间。要选择一个正确的 metrics,通常可以关注以下几个指标:

    1. 最大影响,就跟优化一样的,我们通常会首先关注开销最大的地方。
    2. 可执行,也就是这些 metrics 的提升真的是因为我们的努力而变化的。
    3. 可反应,这些 metrics 能很直观对变化给与正负反馈。

    当我们有了计划,有了 metrics,自然就可以去执行,去实施,不过需要注意的是在实施的时候也需要时刻知道事情的进展,别偏离方向。我们可以使用工具来记录,譬如对于我们自己系统,可以使用 Prometheus 来保存 metrics,这样我们就能知道整个历史的变化了。

    不过最重要的一点,就是记录的数据一定要是真是的,错误的数据甚至比没有数据还要糟糕,因为这可能会让我们进行错误的决策。

    更快,更频繁的去验证我们的想法

    要迭代的更快,一个必要的事情就是要更快的去验证我们的想法。这里有一个词,叫做 MVP - Minimum viable product,也就是最小化的可行产品。我们需要很多小的工作,来收集数据,从而验证我们的假设和目标。

    要对产品迭代,通常一个比较好的做法就是进行 A/B testing,同时建立起来完善的反馈循环,让我们知道每一次决定是不是对的。

    增强我们项目评估技能

    对于工程师来说,还需要锻炼的一个能力就是项目评估技能,程序员向来喜欢高估自己的能力,低估事情的复杂度,项目时间通常预估不准,导致项目延期。所以我们需要使用更加精确的预估手段来推进项目,下面是一些可行的方案:

    1. 将项目拆分成更加细粒度的任务,
    2. 基于任务实际会耗时多久来评估,而不是基于我们或者其他人觉得要花多久时间
    3. 基于概率统计来评估,而不是基于最好的情况来
    4. 让实际做任务的人来进行评估
    5. 使用多种方式来评估同一个任务
    6. 通过历史数据来验证评估是否合理
    7. 使用时间窗口来限制任务的时间
    8. 允许其他人来质疑我们的评估

    最后,无论我们选择了什么方案,一点需要注意的是,一定要给未知的东西预留时间,也就是要给自己留点 buffer,随时应变。

    当我们评估完成时间之后,需要设置好清晰的计划,以及可衡量的里程碑,让我们尽量走在正确的道路上。这里几点要注意:

    1. 要尽快的减少并且规避风险,甚至需要先把风险最高的事情搞定
    2. 对于从头造轮子,要保持足够的警觉
    3. 要懂得项目是跑马拉松,不要再中途就多次冲刺,保持合理的节奏,当然有时候稍微提速也是可以的

    构建长期价值

    务实的平衡品质

    有时候,项目的快速发展跟品质是有冲突的,所以这里我们需要好好的平衡两者的关系。

    首先,我们需要建立 code review 的文化,不允许大家随意的增加功能,随意的合并代码。虽然这个可能会影响产品进度,但好处不言而喻。在 PingCAP,我们有着严格的 code review 流程,一个程序员如果要开发一个新的功能,他需要提交 RFC,只有 RFC 被通过了,才能进行开发,当然,他也可以先自己做点原型验证,让 RFC 更容易被通过。每个 PR,我们至少需要两个人 review 并且 approve 才能 merge。

    在代码层面,我们需要鼓励抽象,使用抽象来封装复杂的逻辑,保证代码容易学习,容易使用,容易扩展。代码的测试一定要跟上,一定要重视自动化测试,这个很多研发都不喜欢写测试,觉得那是 QA team 的事情,但恰恰研发是最应该懂测试的。

    最小化操作负担

    对于一个产品来说,易用性是非常关键的,我们一定要保证操作的简单,所以非常欢迎大家加入帮助我们一起来改进,如果你有任何易用性上面的问题,欢迎联系我。

    投资整个 team 的成长

    当然,除了要关注产品价值,整个 team 也是要仔细考虑的,毕竟得先有人,才能做出来产品。要保证 team 不断的成长,所以我们需要建立一个不错的工程师文化,主要包括:

    1. 不断的优化迭代速度,实施 MVP
    2. 自动化,自动化,自动化
    3. 对代码进行正确的抽象
    4. 关注代码质量,强制 code review
    5. 建立一个有尊严的工作环境
    6. 培养一个持续学习的文化,并不断的完善
    7. 给自己分配一点做研究的时间,譬如每周 20% 时间,或者通过 hackathon
    8. 。。。。。。

    写在最后

    好了,说了这么多,我们一直在聊的是高效,上面只是我的一些对照书的简单总结。如果你能看到这里,我表示很佩服,因为现在要说重点的东西了。

    作为一个程序员,高效是需要融入到自己骨子里面的,但是,很多同学一定会很苦闷到底如何才能变得高效?自然,一个很简单的办法就是加入一个高效率的公司。如果一个公司从上到下都是推崇的高效率工程师文化,待在里面,自然也就能潜移默化的变得高效了。很自豪的说,PingCAP 就是这样一家公司 :-)

    不过,这里我还会更进一步,在 PingCAP 里面,有一只神秘的特种部队,天生是为高效而生的,它的名字就是 Effective Tool Team,简称 ET Team,没错,这个就是致敬 E.T. 外星人的。

    在 ET team 里面,我们立足于使用最少的资源来解决最大的问题,也就是会关注于杠杆的那个支点。在 ET team,你会:

    • 研究不同的测试技术,譬如 Chaos,Fuzzing,Performance regression,来不断的去提升 TiDB 的质量。
    • 研究不同的 bot 技术,让 PingCAP 的整个工作流自动化运转。
    • 研究各种诊断工具,通过开发 ftrace,bcc,eBPF,perf 等工具来让整个系统的运转在你的面前了无秘密。你甚至可以去 hack Linux 内核。
    • 参与到 TiDB 的研发,尤其是涉及到性能,稳定性相关的模块,你都可以肆意的去贡献,去完善。
    • 任何能提升团队效率的事情

    在 ET team,你可以不断的去突破你的想象力,我们一直相信『天空才是你的极限!』,如果你愿意加入,欢迎联系 [email protected]

    2 条回复    2019-11-25 13:29:29 +08:00
    Ge4Los
        1
    Ge4Los  
       2019-11-24 19:45:07 +08:00   ❤️ 1
    涉及到成长型思维的书应该是 《终身成长》 这本,《终生成长》是另外一本。
    qiuyesuifeng
        2
    qiuyesuifeng  
    OP
       2019-11-25 13:29:29 +08:00
    @Ge4Los 感谢指正:)
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1430 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 44ms · UTC 17:27 · PVG 01:27 · LAX 10:27 · JFK 13:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.