今天這篇文章還是來自四火老師。
不要被我的標題騙了。我可不是來宣揚什麼模型驅動開發，或者什麼測試驅動開發的，那些都弱爆了。今天我要說的，是幾種看起來激動人心、華麗無比，但是可以讓程序員們痛苦不堪的開發方式，特別適合那些熱衷於折磨虐待程序員的項目經理和產品經理們。當然，掌握以後，偷偷用就好了，請不要來感謝我。
進度驅動開發（SDD，Schedule Driven Development）
這是在國內最爲流行的開發方式，大家心照不宣，口口相交，代代相傳，我只是把它寫下來而已。它最華麗的地方在於，可以百分之百，甚至百分之二百地壓榨程序員的勞動力。
需要實現哪些需求？用什麼技術？用什麼平臺？項目採用什麼流程管理？這些都不重要。重要的是——什麼時候交付？
假使說，老大們通知，下個月的這個時候要看到產品發佈，那麼：
- 三週以後就要拿出完備的產品準備上線；
- 兩週以後就請發佈 beta 測試版本，ST、IT 之類的東西就得在那之前完成；
- 本週就必須完成編碼和 UT，那麼週一設計，週二、週三開發，週四、週五測試和修正問題。
看，項目計劃多麼完美。項目時間本來就該是根據 deadline 倒排的。
項目做什麼呢？先做那些相對重要的需求，可是如果時間緊的話就只好砍需求了吧…… 不！你怎麼能那麼容易就放棄呢？你看，我的完美的計劃裏面沒有安排週六和週日嘛，大家可以來加加班嘛，年輕的時候不得奮鬥一把嘛，不用砍需求，平時的時間再壓一壓不就可以如期上線了？
在熱情洋溢的動員會之後，大家開始拼命趕工了，瘋狂的一週過去了，測試團隊始終等不到開發團隊提供的發佈包，難道 “又” 要延期了？
那還用問嗎？當然！
測試團隊的時間也是可以壓縮的嘛。於是煎熬的兩週過去了，發佈日期眼看越來越不靠譜，項目經理覺得，他需要挺身而出了——
敏捷思想教導我們，搞不定的時候，質量不能丟、進度更不能丟，那我們只得砍需求了。這樣，我們只發布 “核心功能” 總行吧……
可是什麼纔是 “核心功能” 呢？
對了，我們做完了哪些？要不，做完的就算 “核心功能吧”？
太牛了！這真是一個偉大的創舉！
別忘了，給程序員畫餅也是項目經理重要的技能——大家再努努力，進度壓力也是沒辦法的事，發佈以後大家就輕鬆了，有好日子過了！
瞧，“沒有發佈不了的版本”，這是真的！
產品發佈以後大家就輕鬆了，有好日子過了，這也是真的！
文檔驅動開發（DDD，Document Driven Development）
這種開發方式也非常華麗，對於許多領導和老大們而言，文檔勝過一切。架構文檔要靠 ppt，因爲他們的智商和知識不足以理解滿是文字的東西，而膠片，則是最接近看圖說話的好東西。設計文檔，要靠足夠詳細的 word 文檔，項目經理要看到你的文檔細緻到肯定可以輕鬆地指導編碼，如果你明天突然拉肚子拉到抽筋，打嗝打到卡住，喝水喝到噎着，於是不幸住院的話，文檔的威力就體現出來了，他可以輕鬆找到你的備份，替掉你的工作。
軟件開發全套有十項文檔，從工作任務書開始，只有完成了文檔，你的工作纔算完成。如果你要在郵件裏面，或者會議上向大家傳授一點什麼技巧，你可得當心了，因爲接下去劈頭蓋臉的就是這樣一句 “有文檔記錄嗎？”，彷彿有了文檔就有了一切，有了文檔就買了保險——至於有沒有人看，嗨，誰管呢？
別忘了，文檔的核心地位需要貫徹到底。在績效考覈的時候，最能寫的人，就可以成爲優秀員工。代碼這種無法體現智商差異的東西可以踢一邊去，只有文檔纔是智慧和能力的綜合代表啊。
指標驅動開發（IDD，Indicator Driven Development）
這種開發方式的華麗，源於它超強的數據化和量化的能力。寫代碼的目的是什麼？完成需求？優雅設計？用戶體驗？你全錯了。
再次強調，終極目的是測試覆蓋率。
整個軟件開發流程裏，你可以找得到無數的指標要求，在做每一件事情之前，必須要像默唸毛主席語錄那樣回顧一遍需要達成的指標，然後再動手。
有一天，你發現用戶體驗像屎一樣的產品，居然自動化測試也可以達到 95% 以上的通過率，bug 居然可以收斂到 10 個 / 輪測試，而且 Findbugs/CheckStyle/PMD/Source Monitor/Simian 之類的無數代碼檢查工具的結果頁上，都齊刷刷地顯示着綠條……
恭喜你，你成功了。
更重要的是，項目成功了。
裝逼驅動開發（ZDD，Zhuangbility Driven Development）
這大概是幾種開發方式中最華麗的一種。在設計前、寫代碼前，在做每一項事情之前，都要謹記裝逼的重要性。對於很多不懂技術的領導來說，聽起來越牛逼的軟件，就越值得開發。
- 產品裝逼：必須支持 “雲” 和 “大數據”，比如數據存儲到服務端叫 “雲同步”，其實具體怎麼個支持法，這不重要，關鍵是裝逼的理念，理念！
- 設計裝逼：核心就是，靈活！強大！設計，就是要體現出自己的知識和閱歷，已經無比聰慧的頭腦。設計的東西萬萬不可簡單直接，這是和裝逼理念嚴重違背的。軟件的每一個組件不但能夠對常見的異常情形容錯，你就是刪掉它幾個類它一樣跑得歡快。
- 代碼裝逼：漫山遍野的 Factory，漫山遍野的接口，最好別讓我看到 “new” 這樣的關鍵字；超強的解耦，好端端一個軟件，不把它分成個十幾二十層來實現都對不起 J2EE 的祖宗；超級無敵靈活的配置，需要啥配啥，還支持各種免重啓的熱插拔、熱部署，產品發佈的時候小於 500 個可配置的項都不好意思自說產品是自己做的。
- 評審裝逼：體現自己超強無比的全面性和洞察力，請參閱我曾經寫過的一些牛叉無比的評審方式中，“到處放炮型評審”。
總而言之，軟件工程的每一個環節都需要達到足夠的裝逼值，才能進入下一環節。裝逼是指導軟件開發的重要思想。
其實還有很多其他華麗無比的開發方式，比如會議驅動開發（MDD），Demo 驅動開發（DDD）等等，但這幾種是最常見的。如果你知道更華麗的開發方式，請告訴我。
文章來源鏈接: 《四火的嘮叨》
歡迎大家關注「碼匠趙鐵柱」，一起“享受”這些“華麗”開發方式
