程序员

前言

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

软件行业的名著《人月神话》里提到两个重要概念：本质复杂度（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的编码套路
————————————————
版权声明：本文为CSDN博主「小羊子说」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/jun5753/article/details/114198674