前言
近来工作有些感悟记录下来，总结经验，以便在以后的生活工作中实践检验。
本次的经验总结为： 用文档驱动开发
目标
工作不能 糙，快，猛， 要 好又快。
在资本增密、技术增密、劳动增密但是排斥劳动者个数的互联网行业，糙快猛是没有前途，是死路一条，唯有好又快才是个人的出路。
那么如何做到又好又快的完成工作呢，方法之一为文档驱动开发。
为什么要文档驱动开发
假如有一个任务来了，那么常见的糙，快，猛做法是沟通需求，大致设计一下架构，区分一下模块，然后创建代码仓库，撸起袖子开始写。写着写着就发现各种各样没想到的问题，先是需求变动、然后是设计不合理、接口变化，再然后是写完之后，发版，管控困难，break change，质量不稳定，可维护性差，可读性差，有黑盒子逻辑，新人贡献代码困难，review困难等。需要很大的心力手动处理各种脏活。
文档驱动开发 的区别是对于这样的任务，先写文档，写文档并不是高考卷旁的草稿纸，而是真正答完要交的高考卷。（可以有各种草稿纸，但是最终要写在考卷上）。
写文档只是表面区别，真正的区别是，形成思于先而行于后的习惯，只有想清楚了，才能做得快速，做的明白、做的踏实。这是一种开头表面上慢，但是实际上很快速，质量又得到最大限度保证的行事方法。
写作是注意力高度集中，思维高度凝聚的一种方式，当你写下文档时，会让你思路清晰、去伪存真、也方便后来的维护。人脑是记不住哪些细节的，即便是当初觉得想的很明白、很清晰的事情，过几个月再看也会相见不相识。
如何写文档
写的好的文档才能驱动你的开发，写的差的文档，反而会扰乱思维。
好的文档要求：
- 目标明确，思路清晰，边界清楚。
- 语言凝练，描述准确，切记啰嗦。
- 经常维护
- 表达形式丰富，动态图、逻辑图、流程图等。
如何下笔写文档
千里之行始于足下，写文档第一件事是明确目标。明确目标是很难的事情，需要对需求的认证高度抽象，需要不断练习精进。
目标明确后，要确认边界。确认边界是很重要的事情，应对各种复杂的现实，一个项目解决的是一个或者一类事情，如果做成了，会有各种各样的事情想要加入进来，把项目变得臃肿，恶心。项目变大是一件好事，但是如果超出了边界就得不偿失了，不如用另外一个项目解决超出边界的问题。
目标明确了，边界确认好了，剩下的就是 前期调研、技术选型、设计架构 、质量管控、版本记录、交付方式、 TODO List 。
举例项目 -
- 背景介绍
- 目标
- 版本变更
- 前期调研
- 技术选型
- 架构设计
6.1 模块划分
6.2 整体架构图
6.3 高可用扩展
6.4 灾备- 质量管控
7.1 静态扫描（golint, eslint,pylint, flake8）
7.2 单元测试 （coverage）
7.3 API 测试
7.4 回归测试- CI-CD
8.1 git仓库管理 （简单的项目可以用Tag的方式管理分支，trigger ci-cd）
8.2 CI-CD
8.3 灰度上线
8.4 对外交付方式- 文档管理 （API文档, 用户文档建议把文档集成到Repo中，这样review代码时也可以Review文档）
- 平滑升级
- TODO List
抽象能力、需求认知、调研能力、架构能力、沟通能力的提升是没有捷径的，需要不断的实践练习，才能逐步提升。
反思
- 为什么会有糙快猛的现象？甚至是很多时候自己犯过同样的错误。
个人理解为，这是人类进化出来的本能反应，人类的应激式反应或者是应激式思考。人类的大脑可是消耗资源的大户。深度的思考对资源的消耗更是夸张，千万年来，人类一直处于资源匮乏的时代，进化的本能阻止深入的思考。
Action
- 文档驱动开发，开发前先写文档，把碎片化的思路拧成一股绳，去伪存真。
- 培养思于先而行于后的习惯, 具体锻炼方式为:
a. Review自己的代码或者别人的代码，人脑编译，想各种 edge case。
b. 做leadcode时，脑海中编译测试过了再提交测试，不要应激式的思考。 - 多看好的文档或者样例，有好的输入源，才能有好的输出。
结束语
孔子说过，三人行，必有我师，择其善者而从之，其不善者而改之。
要培养对善、不善的细粒度的感知，这是根本能力。知其善才能从之，知其不善，才能改之。
