在互聯(lián)網(wǎng)浸淫多年的人對?TDD[1]，BDD[2]?和?DDD[3]?都是耳熟能詳?shù)?#xff0c;看著都是好東西，但就是落不了地。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[1]

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

[2]

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

[3]

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

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的事故驱动开发的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。