事故驅(qū)動開發(fā)

在互聯(lián)網(wǎng)浸淫多年的人對?TDD[1]，BDD[2]?和?DDD[3]?都是耳熟能詳?shù)模粗际呛脰|西，但就是落不了地。

TDD 為什么落不了地？大多數(shù)業(yè)務(wù)系統(tǒng)的生命周期都很短，日常的迭代就像是在沒完沒了地做 MVP-Minimum Viable Product 版本的系統(tǒng)。連穩(wěn)定的業(yè)務(wù)邏輯都沒有，想要維護和業(yè)務(wù)保持一致的測試還是比較難的。當然，TDD 的信徒會較真地說，我們 TDD 的正確方法是先寫測試，后寫邏輯。那你要看看現(xiàn)在大型互聯(lián)網(wǎng)公司動輒上萬行代碼，上百個依賴的“核心”接口，是不是真的有那么容易寫各種場景的測試了，令人 mock 到頭禿。

BDD 更不用說了，測試都不寫，還 behavior。盡管 living doc 中對大家諄諄教導(dǎo) BDD 可以幫助生成多樣的業(yè)務(wù)文檔，實際落地起來還是障礙重重。

DDD 同樣，現(xiàn)在的公司架構(gòu)往往是簡單粗暴的邏輯演進來的，架構(gòu)師們什么時候會講自己用了 DDD 呢？一般是在去參加架構(gòu)師大會的前夕，翻閱一下 DDD 的理論，用 DDD 的封皮包裝公司內(nèi)的系統(tǒng)再去外面兜售，名不符實。看起來人人都在用這些理論來指導(dǎo)自己的系統(tǒng)，但是即使你飽讀群書，也沒有找到那個傳說中可以解決所有復(fù)雜性問題的銀彈。

對于很多人來說，理論只不過是吹捧自己和貶低他人的武器。不想接鍋就說要“拆分”，想要排除異己就說要“收斂”。哆拉 A 夢口袋里的工具越多，越方便隨時掏出合適的工具來砸別人的場子。

軟件工程是軟件的工程，更深的層面上是“人”的工程。最終能讓大家達成共識而且人人遵守的業(yè)界規(guī)范，實際上就剩一條了，我把它總結(jié)一下，叫：ADD-Accident Driven Development，事故驅(qū)動開發(fā)。

為什么是共識呢，因為線上事故往往是和程序員們的 KPI 直接相關(guān)的，同時也是和程序員們的領(lǐng)導(dǎo)的 KPI 相關(guān)的，同時還是跟程序員的領(lǐng)導(dǎo)的領(lǐng)導(dǎo)們的烏紗帽相關(guān)的，再往上，是和公司的直接經(jīng)濟損失相關(guān)的。從人性的層面來看，大多數(shù)人都是記打不記吃的(打的時候要扣錢，曾經(jīng)某司的大事故直接導(dǎo)致大老板降職。

看啊，這次上下一條心了吧。

可以觀察一下，無論一個程序員、領(lǐng)導(dǎo)、領(lǐng)導(dǎo)的領(lǐng)導(dǎo)再不靠譜，碰上事故的時候，都是惶恐無措，心驚膽顫，心有余悸，惴惴不安的。(如果你周圍的同事連出事的時候都無所謂的話，那還是趁早開溜吧。

哪怕你們的系統(tǒng)不是特別重要，那出了事也是一定要解決的，解決以后是一定要復(fù)盤的。復(fù)盤以后也是一定要改進的。至于改進方案靠譜不靠譜是另外一回事了。

復(fù)盤的時候也是夾帶私貨最好的時候，平常沉默寡言的同事一到了復(fù)盤會上個個侃侃而談，虎虎生風，老實巴交的工程師驚異于同事們怎么平常是一副“可以都行沒關(guān)系”的調(diào)調(diào)，到了復(fù)盤會上就成了“我知道我可以我早就說過”。

如果工程師苦于有什么要人協(xié)作的事情難以推進，那就去找找部門最近有什么復(fù)盤會吧！勇敢地參加，大膽地發(fā)言，悄悄地私貨。

這都是屢試不爽的套路，解決浮出水面的問題才是大老板的 KPI，也是幫助你和老板一起升官發(fā)財?shù)牟欢▽殹?/p>

而那些還潛伏在水面下的，沒有發(fā)生的問題，提前做規(guī)劃去預(yù)防？這不是給你老板添堵嗎？有這時間不如多摸一會兒魚。

出了問題再去解決問題，你是公司的大功臣，是大家都愛的救火隊員。(火是你放的都沒有關(guān)系，年終還是會成為績效小王子)。

沒有問題就做預(yù)防？最后淪為無用功。

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