程序员的三大美德：懒惰、急躁、傲慢

懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，敦促你写出节省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。
急躁，是计算机偷懒时，你会感到的一种愤怒。它会促使你写出超越预期的程序，而不只是响应需求。
傲慢，极度自信，写出（或维护）别人挑不出毛病的程序。

说明

本文是在 极客时间 APP 学习郑晔老师专栏《10x程序员工作法》的学习笔记。

开篇

概念：

本质复杂度 & 偶然复杂度
本质复杂度就是解决一个问题时，无论怎么做都必须要做的事，而偶然复杂度是因为选用的做事方法不当，而导致要多做的事。

现象

大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题。

目的

如何减少偶然复杂度引发的问题，让软件开发工作有序、高效地进行。

实践

以终为始
任务分解
沟通反馈
自动化

明确现状

我现在在哪（或者说技术水平）？以此确定现状！
我要到哪去（或者说技术水平）？以此确定目标！
我如何到那（或者说技术水平）？以此确定实现路径！

以终为始

最佳实践

DoD，确定好完成的定义，减少团队内部的理解不一致
用户故事，细化出有价值的需求
持续集成，通过尽早集成，减少改动量，降低集成的难度
精益创业，减少过度开发不确定性产品带来的浪费
迭代0，在项目开始之前，做好一些基础准备
任何事物都要经过两次创造：
- 第一次是在头脑中创造，也就是智力上的。
- 第二次是付诸实践，也就是实际的构建。

实战指南

遇到需求或任务，倒着想，先推演，明确“终”

明确完成的标准
明确验收的标准
弄清楚所有待做的需求的原因
扩展自己的角色，不仅限于“程序员”
尽量用可度量的数字衡量所做的工作

扩展

作为程序员，可以管理上级
- 管理上级的预期，把看到的问题暴露出来
- 帮助上级丰富知识，细化分支
- 说出自己的想法，而非压抑
拿老板说事，可以到老板面前澄清
- 一般来说老板要求的是方向，而不是细节；要排除产品经理畏于老板而强迫下游无脑实现的需求。
对抄袭的需求，先明确要抄什么，而不是无脑照抄
分清楚需求和技术，各自做好各自的事情

任务分解

最佳实践

艾森豪威尔矩阵（Eisenhower Matrix）
- 将事情按照重要和紧急程度进行划分，成四个象限
- 重要且紧急的事情要立即做；重要但不紧急的事情应该是重点投入精力的地方；紧急但不重要的事情，可以委托别人做；不重要且不紧急的事情，尽量少做
最小可行产品
- “刚刚好”满足客户需求的产品
- 在实践中，用最小的代价找到一条可行的路径

实战指南

分而治之，是人类解决问题的基本手段
任务分解，分解到可以进行的微操作
- 事前思考，减少遗漏
- 事中被打断，可迅速恢复
应该编写可测试的代码

扩展

对不了解技术的任务，先要去了解技术，然后再做任务分解
通过一次技术Spike，学习新技术
- Spike，指轻轻的刺，程度弱于调研
- Spike的作用在于消除不确定性，让需求方知道这里要用到一项团队内没有人懂的技术，需要花时间弄清楚
- Spike，针对使用新技术所关注的点进行快速调试、验证
- Spike用的原型代码，应该抛弃，不可作为实际应用的代码
分清目标与现状，用目标作为方向，指导现状的改变

沟通反馈

最佳实践

看板
- 可视化的任务
- 明确任务大纲及进程
持续集成
- 做好持续集成的关键是快速反馈
- 本地检查过后再提交
回顾&复盘
- 枚举关注点
- 选出重点
- 深入讨论
- 列出行动项
- 找到负责人
编写代码的进阶路径（非底层）
1. 编写可以运行的代码
2. 编写符合代码规范的代码
3. 编写人可以理解的代码
4. 用业务语言写代码
  - 贴近实际应用现场，例如起名字贴近实际应用业务而非代码中面向实现的名字
  - DDD 领域驱动设计
会议是一种 重量级 的沟通方式
- 若非必要，不要开会
- 减少参会人数
- 尽量采用 轻量级 的沟通方式 —— 面对面沟通
聆听用户声音
- 能做自己用户，做自己用户
- 能接近用户，接近用户
- 没有用户，创造用户
Fail Fast
- 尽早暴露出错误，不要隐瞒，容错

实战指南

回顾会议是一个常见的复盘实践，是一个团队自我改善的前提。
- 分类方式
  - 主题分类1
    - 做得好的
    - 做的欠佳的
    - 问题或建议
  - 主题分类2（海星图）
    - 继续保持
    - 开始做
    - 停止做
    - 多做一些
    - 少做一些
- 会议重点：
  - 写事实，不要写感受
    - 事实就是明摆在那里的东西，而感受无法衡量
  - 重点关注可改进的部分，按照优先级讨论（一般只挑出最重要的几个）
  - 通过多个为什么，一步步找到根因
  - 尝试着找出解决方案，一系列行动项；所有的行动项都是可检查的，可验证实现的内容
  - 验证行动项的完成情况
多输出，让知识更有结构
- 金字塔原理，从中心论点到分论点再到论据
  - 结论先行（一次表达只支持一个思想，且出现在开头）
  - 以上统下（任一层次上的思想都必须是下一层思想的总结概括）
  - 归类分组（每组中的思想都必须属于同一范畴）
  - 逻辑递进（每组中的思想都必须按照逻辑顺序排列）

扩展

安全性检查，是回顾会议的前提条件
- 暴露问题，是改进的前提条件
- 营造畅所欲言的环境，让“领导”暂时回避
在信息获取上，国内外程序员差别不大，开拓视野，改善工作习惯，是国内程序员亟需提高的

自动化

最佳实践

持续交付
- 将生产部署纳入开发的考量
- 持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境
- 构建流水线保证到了下游的交付物一定是通过上游验证的
- 随着Docker的诞生，交付由发布包变成了Docker镜像
微服务
- 做好微服务的前提是划分好限界上下文
- 微服务的第一步，不要划分微服务
程序员的三大美德：懒惰、急躁、傲慢
- 懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，敦促你写出节省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。
- 急躁，是计算机偷懒时，你会感到的一种愤怒。它会促使你写出超越预期的程序，而不只是响应需求。
- 傲慢，极度自信，写出（或维护）别人挑不出毛病的程序。

实战指南

谨慎地将工作自动化，将工作过程自动化
采用简单的技术解决问题，直到问题变复杂
软件设计最基础的原则是高内聚、低耦合
小心NIH综合症（Not Invented Here Syndrome）
- 因为那个东西不是我做的，可能存在各种问题，非要自己做出一套新的

扩展

AB测试，用一个软件的多个版本验证想法
熟练使用快捷键
有价值的事情不局限于事情本身。做自动化很重要，写代码很重要。但根据现有情况判断是否需要自动化，是否需要写代码也很重要。有的放矢，任务分解，权衡跟设计是一件很艺术的事情。
分而治之是解决复杂问题的一大利器。持续交互就像重构中小步快走，都能保证大工程的稳步前进。同时由于单元小了，所以也灵活了，持续交付可以结合最小产品的理念，以小成本做test，收集数据后，及时调整产品发展方向。

综合运用

实战指南

“学习区”学习模型
- 舒适区，舒适而缺乏成长
- 恐慌区，超出能力范围
- 学习区，有难度而可以达成
- 在学习区练习才能得到足够的成长
T型人才，一专多能
- 知识的广度
- 专业技能的深度
面对新工作，从全面了解了解开始
- 业务：做什么
- 技术：怎么做
- 团队运作：怎么与人协作
- 由大到小，由内及外地了解工作
面对遗留系统，稳扎稳打，小步前行
- 基础理念
  - 烂代码只是现象，要了解根因
  - 能重构，先重构，大规模改造是迫不得已的选择
  - 小步前行
- 实际操作
  - 构建测试防护网
  - 将大系统分解成小模块，逐步替换
  - 新旧模块并存，由分发模块调度
  - 建立好领域模型
  - 寻找行业对于系统构建的最新理解
程序员的职业发展
- 程序员的焦虑来自于对未来的不确定性，这种不确定性是一个特定时代加上特定行业的产物
  - 快速发展的中国经济
  - 程序员在中国是一个新兴职业
- 成为行业专家，制定高目标
- 向大师学习，开拓视野
- 找到好的问题，和高水平的人一起工作

扩展

Lead by Example
外部系统应该用接口隔离，这种做法体现了接口隔离原则，也是防腐层概念的体现

参考：

极客时间《10x程序员工作法》