程式設計師要避免的開發模式

原文的作者是個技術大牛，毫不避諱的說其對程式設計的認知已高出我們中的大多數。文中的分類方法不見得多麼標準，卻的確能精確刻畫出形形色色的各種程式猿。

個人讀完之後，也是感慨良深。其中很多開發模式錯誤自己也曾犯過，比如BDD+PDD，在之前的公司負責產品維護時，確實像文中所述新增大量的printf到懷疑邏輯中，猶如大海中撈針，漸漸迷失在愈來愈窄的視野以及技術細節中；曾幾何時，也為了只求解決問題，而忽略系統整體性，做各種函式級別的程式碼防護；這些錯誤對個人的技術成長及系統認知都產生了不小的阻礙。

希望下面的文章能對大家有所啟迪，更快地跳過障礙，茁壯成長。

以下轉自程式人生

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

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("hit 1");  
//....some more logic  
printf("hit 2"); 

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

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 中不能自拔時，悄悄地，你曾經引以為豪賴以生存的能力成了你生存下去的最大障礙。

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

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