事故驱动开发

在互联网浸淫多年的人对 TDD[1]，BDD[2] 和 DDD[3] 都是耳熟能详的，看着都是好东西，但就是落不了地。

TDD 为什么落不了地？大多数业务系统的生命周期都很短，日常的迭代就像是在没完没了地做 MVP-Minimum Viable Product 版本的系统。连稳定的业务逻辑都没有，想要维护和业务保持一致的测试还是比较难的。当然，TDD 的信徒会较真地说，我们 TDD 的正确方法是先写测试，后写逻辑。那你要看看现在大型互联网公司动辄上万行代码，上百个依赖的“核心”接口，是不是真的有那么容易写各种场景的测试了，令人 mock 到头秃。

BDD 更不用说了，测试都不写，还 behavior。尽管 living doc 中对大家谆谆教导 BDD 可以帮助生成多样的业务文档，实际落地起来还是障碍重重。

DDD 同样，现在的公司架构往往是简单粗暴的逻辑演进来的，架构师们什么时候会讲自己用了 DDD 呢？一般是在去参加架构师大会的前夕，翻阅一下 DDD 的理论，用 DDD 的封皮包装公司内的系统再去外面兜售，名不符实。看起来人人都在用这些理论来指导自己的系统，但是即使你饱读群书，也没有找到那个传说中可以解决所有复杂性问题的银弹。

对于很多人来说，理论只不过是吹捧自己和贬低他人的武器。不想接锅就说要“拆分”，想要排除异己就说要“收敛”。哆拉 A 梦口袋里的工具越多，越方便随时掏出合适的工具来砸别人的场子。

软件工程是软件的工程，更深的层面上是“人”的工程。最终能让大家达成共识而且人人遵守的业界规范，实际上就剩一条了，我把它总结一下，叫：ADD-Accident Driven Development，事故驱动开发。

为什么是共识呢，因为线上事故往往是和程序员们的 KPI 直接相关的，同时也是和程序员们的领导的 KPI 相关的，同时还是跟程序员的领导的领导们的乌纱帽相关的，再往上，是和公司的直接经济损失相关的。从人性的层面来看，大多数人都是记打不记吃的(打的时候要扣钱，曾经某司的大事故直接导致大老板降职。

看啊，这次上下一条心了吧。

可以观察一下，无论一个程序员、领导、领导的领导再不靠谱，碰上事故的时候，都是惶恐无措，心惊胆颤，心有余悸，惴惴不安的。(如果你周围的同事连出事的时候都无所谓的话，那还是趁早开溜吧。

哪怕你们的系统不是特别重要，那出了事也是一定要解决的，解决以后是一定要复盘的。复盘以后也是一定要改进的。至于改进方案靠谱不靠谱是另外一回事了。

复盘的时候也是夹带私货最好的时候，平常沉默寡言的同事一到了复盘会上个个侃侃而谈，虎虎生风，老实巴交的工程师惊异于同事们怎么平常是一副“可以都行没关系”的调调，到了复盘会上就成了“我知道我可以我早就说过”。

如果工程师苦于有什么要人协作的事情难以推进，那就去找找部门最近有什么复盘会吧！勇敢地参加，大胆地发言，悄悄地私货。

这都是屡试不爽的套路，解决浮出水面的问题才是大老板的 KPI，也是帮助你和老板一起升官发财的不二法宝。

而那些还潜伏在水面下的，没有发生的问题，提前做规划去预防？这不是给你老板添堵吗？有这时间不如多摸一会儿鱼。

出了问题再去解决问题，你是公司的大功臣，是大家都爱的救火队员。(火是你放的都没有关系，年终还是会成为绩效小王子)。

没有问题就做预防？最后沦为无用功。

TDD: https://zh.wikipedia.org/wiki/%E6%B5%8B%E8%AF%95%E9%A9%B1%E5%8A%A8%E5%BC%80%E5%8F%91

BDD: https://zh.wikipedia.org/wiki/%E8%A1%8C%E4%B8%BA%E9%A9%B1%E5%8A%A8%E5%BC%80%E5%8F%91

DDD: https://en.wikipedia.org/wiki/Domain-driven_design