各種流行的程式設計風格

在過去的N年中，我遇到了很多使用囧然不同風格的開發者，下面是我所知道的一些，你還知道其它的嗎？

散彈槍程式設計

這種程式設計風格是一種開發者使用非常隨意的方式對待程式碼。“嗯，這個方法呼叫出錯了……那麼我會試著把傳出的引數從 false 變成 true!”，當然依然出錯，於是我們的程式設計師會這樣：“好吧，那我就註釋掉整個方法吧”，或是其它更為隨意的處理方式，直到最後讓這個呼叫成功。或是被旁邊的某個程式設計師指出一個正確的方法。

如果我們把一個正規的程式設計師和一個撞大運的程式設計師放在一起做結地，那麼，那個正規的程式可以馬上變得發瘋起來，並且，可以把正規的程式設計師的智商降到最低。兩個撞大運的程式設計師不應該在一起做結對程式設計，這是因為他們破壞性的才能會造成的傷害會比只有一個還差。

撞大運程式設計

這是一種比散彈槍程式設計要溫和一些的程式設計方式，我相信這種方式可能會是大多數程式設計師都會使用的方式。這種程式設計方式經常出現於程式設計師並不確切知道他們在幹什麼，也不知道所寫的程式的本質和實際，但是可以讓程式工作起來。他們以一種撞大運的方式在寫程式，某些時候，他們根本就不知道某個錯誤的原因，就開始稀裡糊塗地修改程式碼。一旦出現問題，他們會用兩條路：1）停下來，理解一下程式，找到出錯的原因。2）使用散彈槍程式設計方式開始解決問題。

測試驅動開發（Test Driven Development）是一種可以用來拯救上百萬的撞大運程式設計的程式設計師。於是，他們有了一個更為NB的藉口：只要我的程式透過測試了，你還有什麼話好說？別罵我，測試驅動開發是一個不錯的事物，其主要是用來控制撞大運開發所帶來的問題。

Cargo-Cult 程式設計

關於Cargo Cults 這個詞兒來自二戰期間的某些太平洋上小島裡的土著人。在戰爭期間，美國利用這些小島作為太平洋戰場上的補給站。他們在這些小島上修建自己的飛機跑道以用來運輸戰爭物資。而那些小島上的土著人從來沒有見過飛機，當他們看到飛機的時候，覺得相當的牛，可以為那些白人帶來各種各樣的物品和食物。當二戰結束後，那些土著人仿照著修建了飛機跑道，並用竹子修建了塔臺。然後就在那期望著有飛機為他們送來物品和食物。

Cargo Cult 程式設計是一種非常流行的程式設計方法，使用這種方法的程式設計師會學習其它程式設計高手的程式設計方法，雖然他們並不知道為什麼高手們要那樣做，但是他們覺得那樣做可以讓程式工作起來。舉個例子，當時有大量的程式設計師在J2EE出現的第一年中過度地使用了EJBs和Entity Beans。

刻舟求劍程式設計

刻舟求劍是一個很流行的寓言了。這種風格的程式設計在程式設計師的圈子裡是非常常見的。比如，有一天，你發現了一個空指會的異常，於是你到了產生空指標異常的地方，簡單地放上一個判斷： if (p != NULL)。

是的，這樣的fix可以讓你的程式工作起來，但你並沒有真正地解決問題。你只不過是在你的船邊記下了劍掉下去的位置，這樣做只不過把問題隱藏起來，最終只會讓你的程式的行為變得神出鬼沒。你應該找到為什麼指標會為空的原因，然後再解決這個問題。

設計模式驅動型程式設計

正如這種程式設計的名字所說的，這種程式設計風格使用大量的設計模式，在你的程式中，四處都是設計模式，你的程式碼到處都是Facade，Observer ，Strategy，Adapter，等等等等。於是，你的程式要處理的業務邏輯被這些設計模式打亂得無法閱讀，最後，也不知道是業務需求重來，還是設計模式重要，總之，實際業務需求的程式邏輯被各種設計模式混亂得不堪入目。

偵探型程式設計

在解決一個Bug的時候，偵探型程式設計師會調查這個Bug的原因。然後，則調查引發這個BUG的原因的原因。再然後，其會分析修正程式碼後是否會導致其它程式碼失敗的因果關係。再然後然後，他會使用文字搜尋查詢所有使用這個改動的程式碼，並繼續查詢更上一級的呼叫程式碼。最後，這個程式設計師會寫下30個不同的情形的測試案例，就算這些測試案例和那個Bug沒有什麼關係，最最後，這個程式設計師有了足夠多的信心，並且精確地修正了一個拼寫錯誤。

與此同時，其它一個正常的程式修正了其它5個Bug。

屠宰式程式設計

使用這種風格的程式設計師，對重構程式碼有著一種難以控制的極端衝動。他們幾乎會重構所有經手的程式碼。就算是在產品在Release的前夜，當他在修正幾個拼寫錯誤的bug同時，其會修改10個類，以及重構與這10個類有聯絡的另20個類，並且修改了程式碼的build指令碼，以及5個部署描述符。