21 | 高效工作：Facebook的10x程序员效率心法
该思维导图由 AI 生成，仅供参考
第一条原则：抽象和分而治之
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Facebook的10x程序员效率心法分享了如何提高程序员的工作效率。文章主要围绕抽象和分而治之、快速迭代两个原则展开。在抽象和分而治之方面，文章强调了将系统拆分为有限的子系统，隐藏复杂性，以及在实践中的模块定义和拆分实例。在快速迭代方面，文章提出了不追求完美、尽快实现功能、设置本地代码检验等实践。此外，还介绍了代码提交的原子性和频繁fetch origin/master的技巧。这些原则和实践有助于提高程序员的工作效率，对于读者快速了解提高编程效率具有指导意义。 文章还提到了DRY原则，即不要重复你自己。这一原则强调了代码逻辑和流程的重复会降低代码质量和可维护性，因此需要寻找重复的逻辑和代码，并进行适当的处理，如抽象出共同的部分、封装到模块、类或函数中，以及自动化流程重复。此外，文章还提到了好的代码注释和设计时审查等实践，以及持续学习的重要性。 总的来说，本文通过介绍编程技术方面的原则和实践，为读者提供了提高工作效率和成长为高效程序员的指导。同时，文章还强调了技术领域的不断演化和发展，以及持续学习的重要性。 通过本文的总结，读者可以快速了解提高编程效率的关键原则和实践，以及在工作中应用这些原则的重要性，为读者提供了有益的技术指导和思考。
《研发效率破局之道》，新⼈⾸单¥59
全部留言(15)
- 最新
- 精选
Jxin
1.应该是提高个人效能的实践，哪个更有体会吧？ 2.关于追求完美，我有点体验。原本我也是事事追求完美。但在跟完郑烨老师的<10x程序员工作法>后，我认可了一个观点。过分的追求完美是在核心价值思考上的偷懒。所以后面对完美的追求就变成了边际成本投入和边际收益的平衡上，依旧是追求更好，但力度更小更精准，每一行代码在写上去前都有过斟酌。 3.关于自动化，我也有点体验。我曾抱怨过项目完全没有自动化测试这一块，但测试同学都是业务测试，很无奈，然后我就自己干，结果根本撑不起来，自动化case的添加都赶不上功能需求的添加。而后，经过和测试同学的讨论，我们采用了定时任务维护测试环境数据，加半自动case覆盖（部分需要人工验证）的方式，将回归测试case集先弄起来了。从中我吸取了一个经验，一切的目的是对任务close的追求，自动化只是常用的方式，编码只是工具。不一定都要自动化，也可以说完全自动化的追求亦是一种完美追求，不利于落地。采用优先落地持续迭代才是比较科学的方案，毕竟，这样能更早的享受到回归case的好处，虽然它一开始并没有那么好用。 4.我不建议采用太多设计模式，除非非常有把握或者说这么用基本是编程泛式，不然简单才是硬道理。我在重构时，为了结构优雅去重啥会引入一些设计模式。在针对某块业务性能调优时会引入。但往往快速迭代时都只是适当做下领域抽象就上了。 5.除了高效，感觉价值导向也很重要。程序员需要持续学习，而我现在的持续学习不大一样。我现在的持续学习，往往都是工作中有什么难点，然后针对性去学习，我的目标是自己的成长要在工作中产生价值，也就是随着自己的成长团队可以持续受惠。为此，我学习管理学，okr，来科学管理团队，学习软件工程和项目管理来把控开发过程，学习市场运营和产品设计来追求价值最大化和产品合理性，学习增长思维和经济学来对齐企业战略，导向团队和项目发展。但这么做有个很大弊端，沉默成本太多，大多是专用资源，在基本只看通用资源的当下面试场景太吃亏。而且越有价值越吃亏，和企业绑太死，发现太依赖企业成长情况，对个人职业发展也道不清是利是弊。对于这种尴尬的情况，老师您有什么见解？作者回复: 不好意思这两天特别忙，回复晚了一些。 每次@Jxin的发言都很高质量。这次一样。我逐条讲一下我的看法。 1. 我原先就是想问问看大家对我在"抽象和分而治之"部分提到的方法，哪一个你觉得有用。不过现在看来看，的确是"提高个人效能的实践，哪个更有体会"这个问题更能激发大家的思考 ：） 2. "过分的追求完美是在核心价值思考上的偷懒"讲的真好！ 3. 这个是实用主义的体现。完成目标才是最重要的。 4. 这是设计模式和简单化的权衡的问题。使用设计模式和简单化，都是方法而不是目的。目的是质量、性能、和可维护性这些东西。要根据目的选择方法。不过一般来说我会稍微偏向简单化一些。 5. 我等一下另外回复。
2019-10-11721
技术修行者
很久以前看到的一句话，也是经常给团队说的一句话：没有什么问题是分层不能解决的，如果不能解决，那再加一个分层。 抽象和分而治之是从事这个行业的基本素质。作者回复: 👍👍👍
2019-10-128
Y024《Kubernetes Patterns》已开源可免费下载：https://k8spatterns.io/作者回复: 谢谢分享！
2019-12-1124
罗小布老师你提到了「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-1124
文中要重复超过三次，且机器做会更有效更迅速的事情，我就会将它自动化。 例如： - 要搭新项目的时候，要创建新工程，做一系列的 DevOps 相关配置、IaaS 资源申请和绑定，就可以通过一些脚手架来自动化 - 指标的上报做到 Controller 的注解和 RPC Client 的基类中，再在 Prometheus 实现无差别的默认监控报警规则，确保每次有新功能上线，指标上报和报警规则都能自动上线，不会有报警漏掉。有不合理的阈值，再增加额外的报警规则进行处理。有报警来了，通过将报警输入一个报警分析服务，自动捞出可能相关的系统日志，即可大致判断异常来源，自己问题自己爬起来修，不是自己问题就可以安心交给上下游的系统继续处理。 - 通过 flyway 恢复 在 git 中管理的 mysql 建表语句和基础数据，自动化测试数据维护。 - 整理大家的周报，做数据统计，一个个人看比较低效。让大家按规定格式上报，自己再写一个脚本来分析，省时省力。作者回复: 你的自动化做的很不错啊！谢谢分享！
2020-04-143- 技术修行者DRY对于日常工作来说也很重要，尤其是当你的工作和运维相关时，比如 1. 编译打包部署整个流程，不使用DevOps的话，会有大量的没有什么价值的重复工作。 2. 各种日常报表的生成和维护，可以自己开发程序或者用Excel宏来生成。
作者回复: 是的。运维相关工作很多不需要界面，重复性也比较明显。DRY合适。我的经验，python和nodejs挺适合写一些自动化的小工具的。
2019-10-123 
兴国代码重复是在写代码时比较反感的地方，常量重复、逻辑重复等都会造成后期的难以维护。 代码提交前没有充分自测，提交后阻塞别人开发。这点也是平常需要加强的。 抽象和分而治之这点，有时在接到新需求时，也要考虑对现有的系统的影响范围以及是否能够在原来的系统上和代码上再次抽象，不只是新增代码。作者回复: 👍👍👍
2019-10-1123
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-082
李双抽象和分而治之！作者回复: Code Complete 这本书当年给我印象最深刻的一点就是关于复杂度处理的讨论。这么些年工作下来，的确程序写得好就是复杂性处理得好。
2019-10-112- ヾ(◍°∇°◍)ﾉﾞ每天来学习的同事主要学习技术，方法论还是工具呢？
作者回复: 嗯，没人回答。你自己呢？
2019-10-144
