10x 程序员工作法 学习总结笔记
Posted 小羊子说
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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”. 刻意练习。
精进书单
《程序员修炼之道：从小工到专家》
《高效能人士的七个习惯》
《好好学习》
《好好思考》
《刻意练习》
……
总结
学会学习、学会思考、学习用好工具, 学会复盘，学会自我迭代，学会精进，学会掌握底层思考利器。
如里觉得总结对你有一点用的话，请给一个赞哦。
参考：
以上是关于10x 程序员工作法 学习总结笔记的主要内容，如果未能解决你的问题，请参考以下文章