读 10x 程序员有感。

作为一名程序员我一直也在探索什么样的工作方式是正确的、高效的。读了极客时间的《10x 程序员工作法》 感受颇深，让我有好多的思考。同时非常认同弗雷德里克·布鲁克斯（Frederick Brooks）统计结果，优秀程序员的开发效率是普通程序员的 10 倍。我总结了一套适合自己的工作方式，虽不能适用所有人，也想和大家一起探讨和思考适合每一个人的工作方式。

以前的我，学了一项技术的时候总会把他锁在自己的笔记里，也不会去跟别人分享与探讨，所以导致“只是学完，没有学会”。

1. 每天的必要思考（吾日三省吾身）：

1.我现在是一个什么样的水平。（现状）

2. 我想达到什么样的水平。（目标）

3. 我将怎么样达到这个目标。（实现路径）

2. 没有写过的代码，是最好维护的代码（以终为始）：

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

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

当前的”终”为：接到需求后，开始在头脑里解析需求，并构思在写代码中可能遇到的问题。

接下来进行写接口文档和注释。

最难维护的代码，是一个月后看你自己写的代码。如果注释没有写流程可能一个月后，你可能会忘记的一干二净。（文档详尽（welldocumented）也是好代码的一种表现）

以终为始,遇见什么事儿，先倒着想。

附《亚马逊是如何开发一项产品的》

1. 写新闻稿

2. 写 FAQ（常见问题解答）

3. 写用户文档

4. 写代码

3. 做任何事之前，先定义完成的标准（DOD：完成的定义（Definition of Done））

准备写代码前：需要对接好相应的完成标准。

比如说某个功能的 DOD：

1. 写接口文档。

2. 写接口注释。

3. 开发人员编写好功能代码。

4. 编写好单元测试（自测）。

5. 测试可以通过。

6. 代码通过代码风格检查。

7. 代码处于可部署状态。

实际项目的 DOD

1. 某个功能的 DOD：比如这个功能特性已经开发完成，处于一个可部署的状态。

2. 一个迭代的 DOD：比如迭代规划所有功能已经完成。

3. 一次发布的 DOD：上线计划，整个软件处于一个可发布的状态。

4. 接到需求任务时：可以使用用户故事。

用户故事：

用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是 who、why、what。用户故事通常的表达格式为：作为一个<用户角色>,我想要<完成活动>,以便于<实现价值>。

角色（who）：谁要使用这个

活动（what）：要完成什么活动

价值（why）：为什么要这么做，这么做能带来什么价值。

①标题：简要地说明用户故事主要内容，比如：登录需求，使用用户名密码登录。

②概述：简要的介绍这个这个用户故事主要内容，作为一个角色，要做什么事，能达到什么效果。比如用户想登录网站，需要输入用户名密码，登录网站成功。

③详述：详细地描述这个用户故事的完整流程，操作流程，用户界面等信息都放在这里，比如用户输入正确用户名密码，提示用户登录成功，用户输入错误用户名密码，提示用户登录失败，用户名或者密码错误。

④验收标准：验收标准会描述一个正常使用的流程是什么样的，以及各种异常流程系统是如何做出相应（制定 DOD）。

5.集成本身就是写代码的一个环节。

客户不需要编写的代码文本，需要的是一个可执行文件，尽早提交代码做集成。

6.解决了技术问题，为什么还在坑里

1. 扩大自己的上下文，总是在自己的的视角里，或者说是在程序员的角色思维里，什么问题都想用技术来解决。手里有锤子，看什么都是钉子。花很多时间来解决的问题，可能并不是问题，常常是程序员的盲区。

2. 扩大自己的上下文，当你知道整个软件的开发周期后，你看到就不只是你做的单个的功能点，而是一条线，虽然写的代码都是一样的，但你看到的是树，别人看到是整个森林，更能用全局来思考问题。

独善其身，不是好事。

7. 数字改变生活

1.在我们的工作中，经常会发生的一个现象是，一个人说，我觉得这个缓存有作用，另一个人说，我觉得那个缓存没有。几个“觉得”下来，双方就开始进入了隔空对话的环节，谁也无法说服谁。 既然这样倒不如增加一个测量尺度，用数据（访问时间）来证明两个人是否说的正确。

2.每天干什么是你的领导最关心的，如何知道让你的领导知道你每天都干什么，也可以通过日报的尺度，（不是说你写得多，你干的活就多）而是你相对昨天（完成度 30%）相比 今天（完成度 60%） 是否有增加。通过数据来测量每天的生产量，也可以作为自己进步的标准。

3.通过数字来解决同事之间扯皮问题：某项功能访问特别慢，是否有前后端扯皮现象。

前端：接口返回慢。

后端：css js 加载慢。

可以使用 SkyWalking、Jaeger 来进行链路追踪，通过数据来说话。

8. 迭代 0

需求方面：

当项目开始时，会有一大堆需求，当需求分解后，大部分的需求都还没有细化，先别去细化所有需求，可以先区分需求的优先级，哪个先做，哪个后做，再进行需求细化。

在这里分享一个小故事：

在 p2p 盛行时期，大部分金融类的 APP 都在抢时间上线，来分行业空白的一杯羹，时间显得特别可贵，等你的 APP 所有的需求都做完了以后，可能你与这个行业已经“天各一方”。

思路：p2p 类型的 App，可以第一个月 App1.0 就只做借款方面的需求,还款时间定为一个月以后，可以在第二个月内做还款功能，等到需要还款时上线 2.0，既不耽误用户使用，也能快速上线，节约时间成本。

系统发布阶段：

这个清单在我们组（可能每个公司不一样）使用屡试不爽，当系统上线时，对照清单选项，工作会有条不紊的进行。

当项目上线后，如果出现问题能通过清单快速定位问题所在。

个人的感受是:公司不缺技术，公司缺的是规范的流程和规范的工作方法。如果说技术是硬技能的话，那么规范的流程和方法就是软技能。工作中碰到的问题有很多都是因为软技能缺失引起的。