研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

21 | 高效工作:Facebook的10x程序员效率心法

葛俊 2019-10-09
你好,我是葛俊。从今天这篇文章开始,我们就正式进入个人效能模块了。今天,我要和你分享的主题是,程序员如何高效地进行开发工作。
最近比较流行的一个说法是 10x 程序员,也就是 10 倍程序员,意思是一个好的程序员,工作效率可以达到普通程序员的 10 倍。要做到这一点并不容易,我们需要在编程技术、工作方式、工具使用等方面全面提高。
今天这篇文章,我将聚焦于如何提高自己的编程技术,给出在实践中被证明有效的 3 条原则,包括抽象和分而治之、快速迭代,以及 DRY(Don’t Repeat Yourself),并针对每条原则给出几个高效实践。而关于工作方式、工具使用等方面的内容,我会在后面几篇文章中与你详细讨论。

第一条原则:抽象和分而治之

虽然我们面对的世界非常复杂,但大脑只能同时处理有限的信息,那怎么平衡这个有限和复杂之间的矛盾呢?
最好的办法是,把一个系统拆分为几个有限的子系统,每个子系统涵盖某一方面的内容,并将其复杂性隐藏起来,只对外暴露关键信息。
这样,我们在研究这个系统的时候,就无需考虑其子系统的细节,从而对整个系统进行有效的思考。如果我们需要深入了解某一个子系统,再打开这个子系统来看即可。
以此类推,如果这个子系统还是很复杂,我们可以再对其进行拆分。这样一来,在任何时候,我们思考时面对的元素都是有限的,复杂度也下降到了大脑的能力范围之内,从而完成对一个复杂系统的理解和处理。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • Jxin
    1.应该是提高个人效能的实践,哪个更有体会吧?

    2.关于追求完美,我有点体验。原本我也是事事追求完美。但在跟完郑烨老师的<10x程序员工作法>后,我认可了一个观点。过分的追求完美是在核心价值思考上的偷懒。所以后面对完美的追求就变成了边际成本投入和边际收益的平衡上,依旧是追求更好,但力度更小更精准,每一行代码在写上去前都有过斟酌。

    3.关于自动化,我也有点体验。我曾抱怨过项目完全没有自动化测试这一块,但测试同学都是业务测试,很无奈,然后我就自己干,结果根本撑不起来,自动化case的添加都赶不上功能需求的添加。而后,经过和测试同学的讨论,我们采用了定时任务维护测试环境数据,加半自动case覆盖(部分需要人工验证)的方式,将回归测试case集先弄起来了。从中我吸取了一个经验,一切的目的是对任务close的追求,自动化只是常用的方式,编码只是工具。不一定都要自动化,也可以说完全自动化的追求亦是一种完美追求,不利于落地。采用优先落地持续迭代才是比较科学的方案,毕竟,这样能更早的享受到回归case的好处,虽然它一开始并没有那么好用。

    4.我不建议采用太多设计模式,除非非常有把握或者说这么用基本是编程泛式,不然简单才是硬道理。我在重构时,为了结构优雅去重啥会引入一些设计模式。在针对某块业务性能调优时会引入。但往往快速迭代时都只是适当做下领域抽象就上了。

    5.除了高效,感觉价值导向也很重要。程序员需要持续学习,而我现在的持续学习不大一样。我现在的持续学习,往往都是工作中有什么难点,然后针对性去学习,我的目标是自己的成长要在工作中产生价值,也就是随着自己的成长团队可以持续受惠。为此,我学习管理学,okr,来科学管理团队,学习软件工程和项目管理来把控开发过程,学习市场运营和产品设计来追求价值最大化和产品合理性,学习增长思维和经济学来对齐企业战略,导向团队和项目发展。但这么做有个很大弊端,沉默成本太多,大多是专用资源,在基本只看通用资源的当下面试场景太吃亏。而且越有价值越吃亏,和企业绑太死,发现太依赖企业成长情况,对个人职业发展也道不清是利是弊。对于这种尴尬的情况,老师您有什么见解?

    作者回复: 不好意思这两天特别忙,回复晚了一些。

    每次@Jxin的发言都很高质量。这次一样。我逐条讲一下我的看法。

    1. 我原先就是想问问看大家对我在"抽象和分而治之"部分提到的方法,哪一个你觉得有用。不过现在看来看,的确是"提高个人效能的实践,哪个更有体会"这个问题更能激发大家的思考 :)

    2. "过分的追求完美是在核心价值思考上的偷懒"讲的真好!

    3. 这个是实用主义的体现。完成目标才是最重要的。

    4. 这是设计模式和简单化的权衡的问题。使用设计模式和简单化,都是方法而不是目的。目的是质量、性能、和可维护性这些东西。要根据目的选择方法。不过一般来说我会稍微偏向简单化一些。

    5. 我等一下另外回复。

    2019-10-11
    6
    8
  • 日拱一卒
    DRY对于日常工作来说也很重要,尤其是当你的工作和运维相关时,比如
    1. 编译打包部署整个流程,不使用DevOps的话,会有大量的没有什么价值的重复工作。
    2. 各种日常报表的生成和维护,可以自己开发程序或者用Excel宏来生成。

    作者回复: 是的。运维相关工作很多不需要界面,重复性也比较明显。DRY合适。我的经验,python和nodejs挺适合写一些自动化的小工具的。

    2019-10-12
    1
  • 日拱一卒
    很久以前看到的一句话,也是经常给团队说的一句话:没有什么问题是分层不能解决的,如果不能解决,那再加一个分层。

    抽象和分而治之是从事这个行业的基本素质。

    作者回复: 👍👍👍

    2019-10-12
    1
  • 杜林
    老师你提到了「Code Complete」这本书,真好最近买了,当我收到快递,看到这本书的厚度时,我已经傻眼了,基本上是一张身份证的宽度

    所以希望您能给我一些建议,怎么来读这本书

    作者回复: 我当时花了蛮多时间慢慢看的。没有什么具体的方法。

    现在回过头看,可以参考一些别人写得Summary,看看哪些部分最感兴趣,也可帮助自己更快掌握全局:
    - https://github.com/mgp/book-notes/blob/master/code-complete.markdown
    - https://medium.com/@crossphd/code-complete-review-chapter-1-welcome-to-software-construction-3284e15b0a4

    2019-10-11
    1
  • 兴国
    代码重复是在写代码时比较反感的地方,常量重复、逻辑重复等都会造成后期的难以维护。
    代码提交前没有充分自测,提交后阻塞别人开发。这点也是平常需要加强的。
    抽象和分而治之这点,有时在接到新需求时,也要考虑对现有的系统的影响范围以及是否能够在原来的系统上和代码上再次抽象,不只是新增代码。

    作者回复: 👍👍👍

    2019-10-11
    1
  • 李双
    抽象和分而治之!

    作者回复: Code Complete 这本书当年给我印象最深刻的一点就是关于复杂度处理的讨论。这么些年工作下来,的确程序写得好就是复杂性处理得好。

    2019-10-11
    1
  • 极客不落🐒
    《Kubernetes Patterns》已开源可免费下载:https://k8spatterns.io/

    作者回复: 谢谢分享!

    2019-12-11
  • qeesung
    我认为TDD是一个高效的原则。在以往的开发过程中,总是先实现代码,然后再进行测试,最后发现无法测试,代码的抽象不够,耦合太严重,浓浓的坏代码的味道。

    通过TDD:
    1. 至少代码是可以测试的,后面如果重构,修改需求也可以很快迭代
    2. 测试来驱动代码设计。整个开发过程反了过来,先写测试,然后再去开发,那么就会强迫你去让你的代码可测试,耦合严重的代码可没那么容易测试,那么在一定程度上可以减少代码耦合度,提升抽象度

    作者回复: Kent Beck 的这个Quora回答,推荐你看看。https://www.quora.com/Does-Kent-Beck-use-TDD-at-Facebook-How/answer/Kent-Beck

    我很赞同他说的第一性原则:你对你的代码质量负责。TDD是实现这个目标的一个工具。适当的地方使用非常好!

    2019-11-08
  • 💪😊
    每天来学习的同事主要学习技术,方法论还是工具呢?

    作者回复: 嗯,没人回答。你自己呢?

    2019-10-14
    2
收起评论
9
返回
顶部