做軟件開發十數年，見識了形形色色的開發者，和各種各樣的奇葩軟件開發模式。本文跟你侃侃這些軟件開發模式及其特點。

IDD（IDE-Driven Development）

大巧在所不為，大智在所不慮。

-- 荀子 天論

IDD，也就是 IDE 驅動開發，幾乎是初學者步入軟件開發殿堂的必經之路。IDE 為開發者屏蔽了很多細節，并且幾乎不用配置（相對于 vim / emacs / sublime）就可以使用代碼自動補全，代碼跳轉，搜索，以及簽入簽出等軟件開發中將會使用到的幾乎所有工作。

然而，它帶來的危害也是顯而易見的，陷入 IDD 開發模式太深，開發者離開了 IDE 便像無頭蒼蠅一樣，幾乎不知道怎么讀代碼，甚至不太會寫代碼，不懂怎么編譯，不會自動化完成常見的任務（比如 android 項目從編譯到打包到 apk 分析），甚至連基本的 git 操作都無法完成。而這些被屏蔽的細節都是軟件工程師的基本功，就像彈鋼琴的基本指法一樣，是必須修煉好的。試想一下，如果你只會在 IDE 里讀代碼，離了 IDE 的跳轉就不知道怎么追溯代碼的脈絡，那么有的代碼你只能通過 browser 閱讀怎么辦？不讀了？如果你只會在 IDE 里寫代碼，有天你只能 ssh 到服務器上寫代碼（表笑，有很多公司這么做，也有很多場合需要這么做），你難道就不寫了？

此外，IDD 開發者如果不能及時從對 IDE 的極度依賴中抽身而出，很容易轉化成下一類開發者。

• 適用人群：初學者
• 舒適指數：五星
• 危害指數：四星
• 解決之道：學會任意一個 shell 下的編輯器

DDD（Debugger-Driven Development）

合格的程序員的代碼是一行行寫出來的；不合格的程序員的代碼是一行行調出來的。

-- 某子 程序員的自我修養

DDD，面向調試器開發，是 IDD 依賴到一定程度的必然反應。這種開發模式的典型表現為：寫出來的代碼不知道對不對，從頭到尾設置無數個斷點，然后進入到調試模式，一個斷點一個斷點跟蹤。發現一個問題，解決一個問題（也許引入一個新的問題），直到所有斷點走數遍，所有遇到的問題被消滅，抹一抹頭上的汗，心里罵上一句：媽的，這段代碼老子（娘）終于調通了！

DDD 是非常浪費程序員生命的一種開發方式，它讓我們把有限的時間精力都浪費在無窮地瞎忙活之中。因為斷點過于唾手可得，程序員會變得懶于思考，懶于設計，甚至寫完了代碼都懶得自己看一眼 —— 大手一揮，無數個紅色的斷點就設置好了，反正出了問題我調就行了唄。

其實很多 concurrent 的問題，靠調試器是無法復現和解決的，更要命的是，DDD 還容易使程序員陷入 tunnel vision —— 我們太過于關注眼前的那一點點狀態，而忽視了全局。

• 適用人群：入門者
• 舒適指數：四星
• 危害指數：五星
• 解決之道：多花時間思考和設計，使用 TDD（Test Driven Development），如果非要追蹤狀態，合理地使用日志（log）而非斷點

PDD（Print-Driven Development）

王好戰，請以戰喻。填然鼓之，兵刃既接，棄甲曳兵而走。或百步而后止，或五十步而后止。以五十步笑百步，則何如？

-- 孟子 梁惠王上

看到 DDD，做嵌入式開發的 C 程序員笑了，我們沒有那臭毛病 —— 大部分嵌入式開發的場景，要么設斷點太麻煩（需要 remote debugger），要么無法設置（比如說很多內核態的代碼），所以我們的代碼都是寫出來的。不過，這部分程序員大多自發聚集起來，立起一個山頭：PDD，也就是面向打印開發。其開發邏輯有如下面的代碼：

// ...some awesome logic...printf("haha, hit 1");// ...some more logicprintf("!!!!!! hit 2");if (awesome_check(awesome_state)) {printf("####### condition captured")}

PDD 和 DDD 相比，是旗鼓相當，半斤八兩。PDD 開發者加入的代碼，和 DDD 開發者設置的斷點一樣，頭疼醫頭，腳疼醫腳，哪里的狀態不對了，或者和預想的流程不一致，先不考慮設計上是否有缺陷，為什么會出現這樣的結果，而是不管三七二十一，加個打印（設個斷點）看看狀態是什么。如果沒抓對位置，那么就繼續細化，直到很被動地找到原因為止。

• 適用人群：入門者
• 舒適指數：三星
• 危害指數：四星
• 解決之道：多花時間思考和設計，合理地使用深思熟慮過的日志（log）而非用完即扔的打印信息

BDD（Bug-Driven Development）

以管窺天，以蠡測海，以莛撞鐘，豈能通其條貫，考其文理，發其音聲哉。

-- 東方朔 答客難

看到 BDD，也就是問題單驅動開發，相信大家都相視一笑。本來這里我想用 TDD（Ticket-Driven Development），更接近我的原意，為了不和 Test-Driven Development 混淆，故而只好改成 BDD。這可能是我們最熟悉的開發模式了 —— 在一個業務穩定的軟件公司（甭管規模大小），勉力維護現有的代碼，小心地添加新功能是多數程序員的主要職責。在這些公司里，與其說我們是工程師，不如說我們是補鍋匠。看不懂代碼？沒關系，只要你會讀日志（出錯信息）；解決不了問題？不打緊，能找到 workaround 把問題繞過去也可以，更有甚者，遇到神問題，看不懂，想不明，解不了，還沒有 workaround，大筆一揮：not reproducible，就把問題關了，幾個月半年后，說不定自己已經去補別的鍋了。

BDD 開發者修的都是防御之道，一手華麗的 defensive coding skill，堪比仙女座的星云鎖鏈，把系統的每寸肌膚防得滴水不漏。如果你看到一段代碼，函數 A(a, b, c) 調了函數 B(c)，即便參數 c 在 A 的入口進行了詳細的檢查，在 B 中也還會再度詳細檢查（哪怕 B 只有 A 調用），那么這代碼一定是 BDD 開發者開發的。

BDD 開發者的視野往往很窄，所學所用皆局限于已有的系統，由于系統并非自己所寫，閱讀代碼又是就著問題去追根溯源，所以對系統的理解會比較狹窄。這并非程序員能力不足，相反，能做 BDD 開發往往都是很有經驗的程序員。然而，他們被公司的需求所局限，整日被 ticket 追逐，疲于奔命，在工作中無法有效提升，漸漸迷失在一個又一個犯罪現場，眼界變得越來越狹窄。

• 適用人群：業務穩定的公司里的『高級程序員』
• 舒適指數：二星
• 危害指數：四星
• 解決之道：自己主導一個項目的開發，或者，跳槽

RDD（Rat-race-game-Driven Development）

From day to day, we programmers dreamed of being an expert inside the team/company; however, when that day really comes we trapped ourselves.

-- 程序君 Programmer’s dilemma

These walls are kind of funny. First you hate ’em, then you get used to ’em. Enough time passes, gets so you depend on them. That’s institutionalized. They send you here for life, that’s exactly what they take. The part that counts, anyways.

-- Red, The Shawshank Redemption

RDD，老鼠賽跑驅動的開發，是指那些整個職業生涯都在原地打轉的開發模式。Rat race game 是『富爸爸窮爸爸』中的經典例子 —— 老鼠在環形的籠子里拼命地奔跑。

每個程序員都在努力地成為他所在領域的專家。成為專家的代價是巨大的，我們需要付出經年累月的努力，才能爬到峰頂，帶上「專家」的帽子。然而，成為「專家」往往意味著一條路走到黑 —— 一來之前的累計的慣性實在太大，掉頭的機會成本太大；二來你的雇主因此而付你更高薪水，所以你只能在這個方向上不斷前進。

我們知道，軟件是個工程的活兒，并非科學。科學的路上走得越遠，打出的裝備越稀缺；而在同一家公司或者同一個行業里搞軟件的，走得越遠，就有越多的路是重復再走。你可能精于 chip verification，于是從第一份工作到第 n 份工作，干的都是 verification 的活，直到有天驚聞這個職位被砍；你可能是web 桌面化的好手，extjs 玩得風生水起，公司依賴你的技能開發產品，直到有一天，這個產品沒人用了，你到市場上一看，你的 extjs 九段的功力，比不上玩 react 才剛剛兩段的水平受歡迎。

RDD 就像 Red 口中所述的那些高墻。當你沉浸在 RDD 中不能自拔時，悄悄地，你曾經引以為豪賴以生存的能力成了你生存下去的最大障礙。

• 適用人群：大公司里的『專家』
• 舒適指數：五星
• 危害指數：四星
• 解決之道：在公司里換不同的團隊，或者，跳槽去更有挑戰的公司

以上寫了這么多，總有一款符合你。你有沒有找到自己心儀的開發模式？如果沒有，恭喜你；如果找到了，別慌，有則改之，無則加勉即可。