10x程序员工作法 学习总结笔记

前言

本文总结了做为一个程序员有哪些高效的工作方式、思考方式和落实起来有用的方式和实操,请选择使用。

软件行业的名著《人月神话》里提到两个重要概念:本质复杂度(Essential Complexity)和偶然复杂度(Accident Complexity)。简单来说,本质复杂度就是解决一个问题时,无论如何都要做的事,而偶然复杂度是因为做事方法不当,而导致要多做的事。

所以做事需要讲究方法,各位各业都有不同的做事方法,本文总结了10x程序员的做事法则。

本文笔记 根据 来自极客时间专栏上资深架构师郑晔的《10x程序员工作法》中的学习部分笔记、和其他相关资料加上个人思考的而形成的总结笔记。

忙碌原因

  • 本质复杂度(Essential Complexity)

    问题本身复杂

  • 偶然复杂度(Accident Complexity)

    选用方法不当, 导致复杂度上升

客观事实

大部分程序员忙碌解决的问题,都不是程序问题,而是由偶然复杂度导致的问题

解决方案

减少偶然复杂度引发的问题, 让软件开发工作有序、高效地进行; 优秀程序员的开发效率是普通程序员的 10 倍。

遵循以下原则有利于减少偶然复杂度

  • 以始为终
  • 任务分解
  • 沟通反馈
  • 自动化

10x工作法原则

如何让努力不白费?

以终为始:遇到事情,倒着想

网上流传着一个帖子,亚马逊 CTO 介绍亚马逊是如何开发一项产品的,简单来说,他们采用向后工作的方法,开发一项产品的顺序为:

  • 写新闻稿;

  • 写 FAQ (常见问题解答);

  • 写用户文档;

  • 写代码。

任何事物都要经过两次创造:一次是在头脑中的创造,也就是智力上的或者第一次创造(Mental/First Creation),然后才是付诸实践,也就是实际的或第二次创造(Physical/Second Creation)。我们应该在第一次创造上多下功夫,统一集体想象,让目标更明确。

“以终为始”的思维可以帮助我们更好地规划我们手头任务,也可以帮助我们发现过程中的问题。

“ 以终为始”也是《高效能人士的七个习惯》中提到的一个重要习惯。这本书值得一读。

史蒂芬.柯维说绝对不要以任何片面的事情为中心,应该要以原则为中心。“一个以原则为中心的人,对自己的选择胸有成竹,无论结果怎么都能专注于此,并且心安理得,内心没有羁绊。以原则为生活中心的人,总是见解不凡,思想与行为也独具一格,而坚实稳定的内在核心赐予他们高度的安全感,人生方向,智慧与力量。会让他们度过积极与充实的一生。”
所以找到你人生的原则,设定一个目标,以终为始。

任务分解

  • 任务分解:按部就班的前提

  • 软件开发的任务分解:

    • 一个大问题,我们都很难给出答案,但回答小问题却是我们擅长的
    • 任务分解的粒度: 可执行。不同的可执行定义差别在于,你是否能清楚地知道这个问题该如何解决。
  • 大师级程序员工作的秘笈

    • 将任务拆小,越小越好
    • 将大问题拆解成能够解决的小问题
  • 测试也是程序员的一部分

    • 对于每个程序员来说,只有在开发阶段把代码和测试都写好,才有资格说,自己交付的是高质量的代码

    • 测试驱动开发(TDD),一种设计挑战

小结:面对看上去无法解决的问题,需要学会分解问题,不然无从下手。

大师级程序员的工作秘笈

大师级程序员每当遇到一件要做的事,把他分解成几个小任务,记录在一个清单上,然后才是动手写测试、写代码、重构这样一个小循环。等一个循环完成了,他会划掉已经做完的任务,开始下一个。一旦在解决问题的过程中遇到任务新问题,他会把要解决的问题记录在清单上,保证问题不会丢失,然后,继续回到自己正在处理的任务上。当他把一个个任务完成的时候,问题就解决完了。每个任务完成时,代码都是可以提交的。看上去简单,但是很多程序员都做不到。

只有把任务分解到很小,才可能做到小步提交。而把任务分解到很小,其实证明你已经想清楚了。而大多数程序员之所以开发效率低,很多时候是没想清楚就动手了。

任务分解是个好习惯,但是想要掌握它,大量的练习是必须的。

作者能保持连续在github上提交代码1000天,还是挺牛逼的,这个连续提交的基础,就是我自己在练习任务分解时,不断的尝试把一件事拆细,这样,我每天都至少能保证完成一小步。当然,如果有时间了,我也会多写一点。

经过这种练习之后,任务分解也就成了我的本能,不再局限于写程序上。我遇到任何需要解决的问题,脑子里的第一反应一定是,它可以怎么一步一步的完成,确定好分解之后,解决问题就是一步步做了。

DoD的价值:在做任何事情之前,先定义完成的标准

DoD(Definition Of Done,完成的定义),这个概念本身并不复杂,它就是告诉我们怎样算完成了,尽量减少因为理解偏差造成的各种浪费。

比如一次开发完成,表示:

  • 开发人员编写好功能代码
  • 编写好单元测试代码
  • 编写好集成测试代码
  • 测试可以通过
  • 代码通过了代码风格检查、测试覆盖率检查。

一旦 DoD 确定好了,谁该做什么事、该做到什么程度就一目了然了。

如何更好得使用 DoD呢?

  • DoD 是一个清单,由一个个检查项组成的,用来检查工作完成情况。

  • DoD 的检查项应该是实际可检查的,比如代码写好了,可以展示代码,单元测试代码写好了,可以进行现场测试。

  • DoD 是团队成员间彼此汇报的一种机制。有了 DoD,做事只有两种状态,即 “做完” 和 “没做完”。

在做任何需求或任务之前,先定好验收标准。

我们都知道,需求是软件开发的一个重要组成部分,但你可能没有仔细想过,不同的需求描述方式,可能会影响程序员对需求的理解。

很多公司的软件开发模式是基于功能列表的,这个列表 “ 规定 ” 了程序员要做的功能,这种方式把一个完整的需求拆成了碎片。不到最后一刻,大部分人并没有一个完整的概念,这也就会在最后关头遇到很多意料之外的问题,结果必然是手忙脚乱。

那么,这个时候验收标准变得极为重要,验收标准不仅仅描述了正常流程,也会关注到异常流程的处理。它给出了这个需求最基本的测试用例,保证了开发人员完成需求最基本的质量。一旦定义好验收标准,大量的扯皮工作就随之烟消云散了。

尽早提交代码去集成

持续集成指的是,频繁地将代码集成到主干。

它的好处主要有两个。

快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。
持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量

Martin Fowler 说过,”持续集成并不能消除 Bug,而是让它们非常容易发现和改正。”

在没弄清楚之前,需求都不做

精益创业:这个名字并不是指导人们创业挣大钱的方法论。它要解决的是面向不确定性创造新事物。

精益创业中的 “精益”这个词,让人们开始理解价值创造和浪费之间的关系。创造价值是每个人都能理解的,但减少浪费是很多人忽略的。所以,精益创业就是在尽可能少浪费的前提下,面向不确定性创造新事物。

既然是面向不确定性创造新事物,我们唯一能做的就是 “ 试 ”。也就是说,当你有了一个新的想法时,就把想法开发成产品投入市场,然后,手机数据获取反馈,看看前面的想法是否靠谱。好想法继续加强,不靠谱的想法丢掉。

既然是试,也不确定想法的有效性,最好的办法就是以最低的成本试。许多软件团队都会陷入一个非常典型的误区,不管什么需求都想做出来看看,殊不知,把软件完整做出来是最大的浪费。

精益创业提供给我们的是一个做产品的思考框架。当产品经理要做一个新产品或是产品的新特性,我们就可以用精益创业的概念检验一下产品经理是否想清楚了。比如,你要做个产品特性,你要验证的东西是什么呢?要验证的目标是否有数据可以度量呢?要解决的这个问题是不是当前最重要的事情?稳了这些,我们能更好地确定产品经理提出的需求确实是经过严格思考的。

接到需求, 要先做哪些事情

需求的拆分:用户故事

  • 问题

    基本上,闯入你脑海的需求描述是主题(epic),在敏捷开发中,有人称之为主用户故事(master story)
    绝大多数问题都是由于分解的粒度太大造成的,少有因为粒度太小而出问题的
    用户故事,它将是我们这里讨论需求管理的基本单位。

  • 需求要分解
    用户故事原则:

1、Independent,独立的
2、Negotiable,可协商的
3、Valuable,有价值的
4、Estimatable,可估算的
5、Small,小
6、Testable,可测试的

需求的估算:

估算的结果是相对的,不是绝对精确的,我们不必像做科研一样,只要给出一个相对估算就好,一般来说,估算的过程也是大家加深对需求理解的过程。

优先级管理:做最重要的事情

需求分解之后,最重要的是,排列需求的优先级。优先级的排列方式有很多,我们可以借鉴时间管理的方法,把事情按照重要和紧急的维度进行划分,得到了四个象限。我们要尽可能把精力放在重要的事情上,而不是把紧急的事情当成优先级排序的方式。

确定事情的重要程度, 一种方式就是找回丢失的上下文,如果无法判断好的办法, 那就引入外部更大的上下文

小结:需求从产品、开发、测试需要对齐,确保理解一致,按一定的敏捷开发流程来不段迭代开发流程,也是高效的工作法则之一。

为什么说做事情之前先要进行推演

  • 沙盘推演, 从军事指挥室里学来的大学问
  • 即便已经确定了自己的工作目标,我们依然要在具体动手之前,把实施步骤推演一番,完成一次头脑中的创造,也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演,在很多领域都有广泛地应用
  • 通向结果的路径才是更重要的
  • 在动手做一件事之前,先推演一番。

解决了很多技术问题,为什么依然在"坑"里?

技术是一把利刃,程序员相信技术可以改变世界,但并不是所有问题都要用技术解决。花大力气去解决一个可能并不是问题的问题,常常是很多程序员的盲区。

  • 更大范围内寻找"终"

  • 程序员总喜欢用技术去解决一切问题,但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案,很多时候原因在于程序员被自己的思考局限住了。

  • 不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题,换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化,很难达到最优的效果

  • 角色的差异:

    • 不同角色工作上真正的差异是上下文的不同
    • 虽然写的代码都一样,但你看到的是树木,人家看到的是森林,他更能从全局思考
    • 我并不是靠技术能力解决了问题,而是凭借对需求的理解把这个问题绕过去了
    • 而能想到问这样的问题,前提就是要跳出程序员角色思维,扩大自己工作的上下文
    • 当你对软件开发的全生命周期都有了认识之后,你看到的就不再是一个点了,而是一条线
  • 工作的上下文不同,看到的维度差异很大

    • 单一维度的思考,在多维度思考者的眼里几乎就是漏洞百出的
    • 扩大自己工作的上下文,别把自己局限在一个“程序员”的角色上。

小结:遇到问题,多沟通,多请教,学会转换视角,转换思维,实现对问题的降维打击,以解决问题。

入职新公司, 如何快速进入工作状态?

步骤:

  • 了解业务

  • 技术

    • 技术栈

    • 业务架构

    • 内外依赖

  • 团队运作

    需求, 产品,向谁汇报

  • 内部活动

    站会、 回顾会议、周会、代码评审、内部分享等。

  • 使用“行话”。在交流的过程中,学习一点”行话“。

    这会让人觉得你懂行,让你很快得到信任,尽早融入团队

  • 找到关键点,迅速下手

  • 由大到小, 由内而外

如何管理你的上级?

  • 领导要求的,无力反驳怎么办?

我们要敢于管理上级。

第一,管理上级的预期。这个过程,相当于我把自己看到的问题暴露给上级,让他选择。
第二,帮助上级丰富知识。
第三,说出你的想法。这其实就是我们熟悉的一个最简单的道理:会哭的孩子有奶吃。

  • 产品经理总拿老板说事,怎么办?

实际上,老板要求的是方向,不是产品特性。大老板不会安排那么细的细节。所以,一个产品经理该做的事就是把老板给的方向,变成一个个可以实现的产品特性,他要分析其中的合理与不合理。

不合理的部分应该是他和老板去沟通的,而不是让开发团队来实现。

  • 别人能做的,我们也要做

第一,竞争对手有的产品,我们也要有。

“抄”不是问题,问题是无脑地抄。

所以,如果你的产品经理只想无脑抄袭,本质上,他就是在偷懒,没干好他该干的活。

第二:人家能做到,说明技术上是可行的。

要做什么是需求,怎么做是技术。与产品经理要确认的是,这个需求是不是合理,该不该做。技术上能否实现,这是开发团队要考虑的事情,并不是产品经理说事的理由。

刻意练习

最牛B的编码套路:

Steve Yegge 在“Practicing Programming”(练习编程)提到:

与你所相信的恰恰相反,单纯地每天埋头于工作并不能算是真正意义上的锻炼——参加会议并不能锻炼你的人际交往能力;回复邮件并不能提高你的打字水平。你必须定期留出时间,集中锻炼,这样才能把事情做得更好。

每天都开车去上班,但我的驾驶水平远远不如专业车手;类似的情况,天天编程可能并不足以使你成为一名专业的程序员。那么,什么才能把一个普通人变成一名专业车手或者专业程序员呢?你需要锻炼什么呢?

答案就在《科学美国人》的一篇名为“The Expert Mind”(专家思维)的文章里:

爱立信提出,重要的并不是经验本身,而是“努力的学习”,也就是要不断地挑战自身能力之外的东西。一些狂热的爱好者花费了大量的时间去下棋、打高尔夫球或者玩乐器,但他们可能始终停留在业余水平上,而一个训练有素的学生却可以在相对较短的时间里超越他们,原因就在这里。值得注意的是,在提高水平方面,花费在下棋上的大量时间(即使参加各种比赛)似乎还是比不过专门的训练来得更为有效。训练的主要价值在于发现弱点,并有针对性地进行提高。

“努力的学习”意味着,要常常去处理那些刚好在你能力极限上的问题,也就是那些对你来说有很大可能失败的事情。如果不经历一些失败的话,你可能就不会成长。你必须不断地挑战自我,超越自己的极限。

那样的挑战有时会在工作中碰到,但也未必。将锻炼从职业工作中分离出来,这在编程领域常被人称为“编码套路”(Code Kata)。

Code Kata的概念是由David Thomas提出的,他是《程序员修炼之道:从小工到专家》的作者之一。这个概念主要指的是:

针对某一种特定技术或技能进行重复性的练习,从而将其熟练掌握。——译者注

还有一些实践经验不在此列出,最后作者总结了最精炼的编程套路:

第一:写博客

第二:积极参与著名的开源项目

小结: 输出倒逼输入,是最好的学习方式之一;“Talk is cheap ,show me the code”. 刻意练习。

精进书单

《程序员修炼之道:从小工到专家》

《高效能人士的七个习惯》

《好好学习》

《好好思考》

《刻意练习》

……

总结

学会学习、学会思考、学习用好工具, 学会复盘,学会自我迭代,学会精进,学会掌握底层思考利器。

如里觉得总结对你有一点用的话,请给一个赞哦。

参考:

如何成为一位技术专家

最牛B的编码套路

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 精致技术 设计师:CSDN官方博客 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值