接觸互聯網行業的朋友，總會在工作中遇到很多各種各樣風格的開發人員，而面對這些開發人員，有時候真的想發火也無從入手，下面就等小編為大家支招，如何從不同風格的開發人員入手，讓項目進行得更加順利。

散彈槍編程

這種編程風格是一種開發者使用非常隨意的方式對待代碼。「嗯，這個方法調用出錯了……那麼我會試着把傳出的參數從 false 變成 true!」，當然依然出錯，於是我們的程序員會這樣：「好吧，那我就注釋掉整個方法吧」，或是其它更為隨意的處理方式，直到最後讓這個調用成功，有可能是被旁邊的某個程序員指出一個正確的方法。

撞大運編程

大多數程序員都會使用的方式，在某些時候，他們根本就不知道某個錯誤的原因，就開始糊里糊塗地修改代碼。而一旦出現問題，他們可能會：

1)停下來，理解一下程序，找到出錯的原因。

2)使用散彈槍編程方式開始解決問題。

另外，還可以利用測試驅動開發(Test Driven Development)工具，控制大運開發所帶來的問題。測試驅動開發可謂是，用來拯救上百萬的撞大運編程的程序員的極佳變成工具。

Cargo-Cult 編程

Cargo Cult 編程是目前一種非常流行的編程方法，很多程序員並不知道高手寫這個代碼的意義是什麼，但是他們卻覺得這樣做能讓程序工作起來，因此他們也就會模仿高手編寫代碼，而不知道代碼的含義。

刻舟求劍編程

這種風格的編程在程序員的圈子裡是非常常見的，例如：當這類風格的程序員發現了一個空指會的異常，於是你到了產生空指針異常的地方，簡單地放上一個判斷： if (p != NULL)。

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

設計模式驅動型編程

這種編程風格使用大量的設計模式，在整個程序中，幾乎四處都是設計模式，你的代碼到處都是Facade，Observer ，Strategy，Adapter等。很多時候，這種程序要處理業務邏輯時，會這些設計模式打亂而無法閱讀，最後也不知道是業務需求重要，還是設計模式重要。總之，整個業務需求程序邏輯被各種設計模式搞得非常混亂。

偵探型編程

在解決一個Bug的時候，偵探型程序員會調查這個Bug的原因，然後，調查引發這個BUG的原因，再然後，其會分析修正代碼後是否會導致其它代碼失敗的因果關係……最後，這個程序員會寫下30個不同的情形的測試案例，就算這些測試案例和那個Bug沒有什麼關係，等到這個程序員有足夠的信心，才開始精確地修正了一個拼寫錯誤。

屠宰式編程

這種風格的程序員，對重構代碼有着一種難以控制的極端衝動。即使是在產品Release的前夜，當他們在修正拼寫錯誤的bug同時，還會修改10個類，以及重構與這10個類有聯繫的另20個類，並且修改了代碼的build腳本，以及5個部署描述符……反正，你懂得!