10X程序员工作法

开篇词

软件行业两个概念，本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）。
大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题。
如何减少偶然复杂度引发的问题，让软件开发工作有序、高效地进行，是这个专题讨论的问题。

01 | 一个思考框架

Where are we?（我们现在在哪？）
Where are we going?（我们要到哪儿去？）
How can we get there?（我们如何到达那里？）

四个思考原则

给出思考框架是为了让你明白为什么要提出问题，而具体问题要怎么问，就可以遵循下面这四项原则：

• 以终为始，确定好真实目标；

• 任务分解，找到实施路径；

• 沟通反馈，解决与人打交道出现的问题；

• 自动化，解决与机器打交道出现的问题。

  02 | 以终为始：如何让你的努力不白费？

  任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。
  对做软件的人来说，我们应该把“终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来。
  践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。

  03 | DoD的价值：你完成了工作，为什么他们还不满意？

  理解的鸿沟

  双方的理解有差异，那就把这个差异弥合上。弥合差异的方式有很多，有一个最佳实践，它的名字叫 DoD（Definition of Done，完成的定义）。

  完成的定义

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

• DoD 的检查项应该是实际可检查的。

• DoD 是团队成员间彼此汇报的一种机制。当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”。
  DoD 是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。
  在做任何事之前，先定义完成的标准。

  04 | 接到需求任务，你要先做哪件事？

  需求，是软件开发中的一个关键环节，一旦需求理解出现问题，势必会造成大量的浪费。传统的功能列表只是简单罗列了要实现的功能，丢失了大量的上下文，会导致团队成员对于需求“只见树木不见森林”。

  用”用户故事”描述需求

• 标题，简要地说明这个用户故事的主要内容

• 概述，简要地介绍这个用户故事的主要内容，一般会用这样的格式：
  As a （Role）, I want to （Activity）, so that （Business Value）.

• 详述，详细地描述这个用户故事的完整流程，我们会把操作流程、用户界面等信息都放到这里。

• 验收标准，这个部分会描述一个正常使用的流程是怎样的，以及各种异常流程系统是如何给出响应的，这是程序员常常会欠缺的思考。它会把详述中很多叙述的部分变成一个具体的测试用例。
  验收标准非常重要的一环是异常流程的描述。验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。
  在做任何需求或任务之前，先定好验收标准。

  05 | 持续集成：集成本身就是写代码的一个环节

  在很长一段时间内，集成都是软件行业的难题，改动量和集成时间互相影响。
  每日构建作为早期的一种“最佳实践”被提了出来，但因为它基本上都是原则，没有得到广泛的应用。当人们进一步“调小”参数后，诞生了一个更极致的实践：持续集成，也就是每次提交代码都进行集成。
  尽早提交代码去集成。

  06 | 精益创业：产品经理不靠谱，你该怎么办？

  我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数。
  但是随着互联网深入人心，软件开始向各个领域蔓延。越来越多的人进入到 IT 行业，不同的人开始在各个方向上进行尝试。这时候，软件开发的主流由面向确定性问题，逐渐变成了面向不确定性问题。

  精益创业

  它要解决的是面向不确定性创造新事物。
  那精益创业到底说的是什么呢？其实很简单。我们不是要面向不确定性创造新事物吗？既然是不确定的，那你唯一能做的事情就是“试”。
  精益创业的方法论里，提出“开发（build）- 测量（measure）- 认知（learn）”这样一个反馈循环。就是说，当你有了一个新的想法（idea）时，就把想法开发成产品（code）投入市场，然后，收集数据（data）获取反馈。
  最好的办法就是以最低的成本试，达成同样一个目标，尽可能少做事。精益创业提出一个非常重要的概念，最小可行产品，也就是许多人口中的 MVP（Minimum Viable Product）。简言之，少花钱，多办事。
  精益创业提供给我们的是一个做产品的思考框架，我们能够接触到的大多数产品都可以放在这个框架内思考。
  ：默认所有需求都不做，直到弄清楚为什么要做这件事。

  07 | 解决了很多技术问题，为什么你依然在“坑”里？

  不同角色工作上真正的差异是上下文的不同。
  虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。

  在更大的上下文工作

  扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。

  08 | 为什么说做事之前要先进行推演？

  对比我们的工作，多数情况下，即便目标清晰，路径却是模糊的。所以，不同的人有不同的处理方式。有些人是走到哪算哪，然后再看；有些人则是先推演一下路径，看看能走到什么程度。
  在军事上，人们将其称为沙盘推演，或沙盘模拟。
  在动手做一件事之前，先推演一番。

  09 | 你的工作可以用数字衡量吗？

  一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。

  从数字出发

• 重视测量指标，重视数字。

• 基于数字进行技术决策。

• 从数字中发现问题。
  结合着“以终为始”的思考，如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。
  而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。我举了几个小例子，比如：基于数据进行技术决策、预先设定系统指标，以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。
  问一下自己，我的工作是不是可以用数字衡量。

  10 | 迭代0: 启动开发之前，你应该准备什么？

  一开始就把项目准备好的实践：迭代 0。

  迭代 0 清单

• 需求方面

  • 细化过的迭代 1 需求
  • 交互
    • 用户界面
    • 用户交互

• 技术方面

  • 基本
    • 技术选型
    • 技术架构
  • 数据库
    • 数据库表结构
    • 数据库迁移
  • 持续集成
    • 持续集成服务器
    • 持续集成监视器
    • 构建脚本
  • 测试
    • 单元测试和集成测试
    • 端到端测试
  • 发布
    • 发布脚本

设计你的迭代 0 清单，给自己的项目做体检。

答疑解惑 | 如何管理你的上级？

第一，管理上级的预期。相当于我把自己看到的问题暴露给上级，让他选择。
第二，帮助上级丰富知识。
第三，说出你的想法。

划重点 | 关于“以终为始”，你要记住的9句话

我们学习到了一些行业最佳实践。

• DoD，确定好完成的定义，减少团队内部的理解不一致。

• 用户故事，细化出有价值的需求。

• 持续集成，通过尽早集成，减少改动量，降低集成的难度。

• 精益创业，减少过度开发不确定性产品带来的浪费。

• 迭代 0，在项目开始之前，做好一些基础准备。
  还学习到一些重要的思维转变。

• 任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。

• 在更大的上下文内发现自己的“终”。

• 通过推演，找到通往“终”的路径。

• 用可度量的“数字”定义自己的“终”。

  11 | 向埃隆·马斯克学习任务分解

  软件开发的任务分解

  一个大问题，我们都很难给出答案，但回答小问题却是我们擅长的。
  用这种思路解决问题的难点是什么呢？给出一个可执行的分解。
  如今软件行业都在提倡拥抱变化，而任务分解是我们拥抱变化的前提。
  动手做一个工作之前，请先对它进行任务分解。

  12 | 测试也是程序员的事吗？

  对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码。
  越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广。
  小事反馈周期短，而大事反馈周期长。
  单元测试、集成测试、系统测试等等。越在底层测试，成本越低，执行越快；越在高层测试，成本越高，执行越慢。
  多写单元测试。

  13 | 先写测试，就是测试驱动开发吗？

  测试驱动开发（Test Driven Development）
  测试驱动开发和测试先行开发只差了一个词：驱动。
  测试先行开发和测试驱动开发的差异就在重构上。因为重构和测试的互相配合，它会驱动着你把代码写得越来越好。这是对“驱动”一词最粗浅的理解。
  如果我们把思路反过来，我有一个测试，怎么写代码能通过它。一旦你先思考测试，设计思路就完全变了：我的代码怎么写才是能测试的，也就是说，我们要编写具有可测试性的代码。
  测试驱动开发的节奏：红——绿——重构。把测试放在前面，还带来了视角的转变，要编写可测的代码，为此，我们甚至需要调整设计，所以，有人也把 TDD 称为测试驱动设计。
  我们应该编写可测的代码。

  14 | 大师级程序员的工作秘笈

  一个经过分解后的任务，需要关注的内容是有限的，我们就可以针对着这个任务，把方方面面的细节想得更加清晰。
  将任务拆小，越小越好。

  15 | 一起练习：手把手带你分解任务

  很多人可能更习惯一个类一个类的写，我要说，最好按照一个需求、一个需求的过程走，这样，任务是可以随时停下来的。
  检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了。
  每做完一个任务，代码都是可以提交的。
  按照完整实现一个需求的顺序去安排分解出来的任务。

  16 | 为什么你的测试不够好？

  主要是因为这些测试不够简单。只有将复杂的测试拆分成简单的测试，测试才有可能做好。

  简单的测试

  把测试写简单，简单到一目了然，不需要证明它的正确性。
  前置准备、执行、断言和清理

  测试的坏味道

  这个测试一旦出错，就需要把所有相关的几个方法都查看一遍，这无疑是增加了工作的复杂度。
  测试一定要有断言。

  一段旅程（A-TRIP）

  好的测试标准：

• Automatic，自动化；

• Thorough，全面的；

• Repeatable，可重复的；

• Independent，独立的；

• Professional，专业的。
  要想写好测试，就要写简单的测试。