轉(zhuǎn)載自：http://mp.weixin.qq.com/s/9NBilUFs-tEbX9O7-0pucw
姓名：梅金波? ? ? ? ? ? ? ? 學(xué)號：16010110036
【嵌牛導(dǎo)讀】編程不僅有不同的語言疏唾， 而且也有不同的風(fēng)格圃庭。
【嵌牛鼻子】散彈槍編程户敬， 撞大運式變成熙尉， Cargo-Cult 編程晃酒， 刻舟求劍編程爽雄， 設(shè)計模式驅(qū)動型編程魏烫，偵探型編程嗅回， 屠宰式編程及穗。
【嵌牛提問】 編程有哪些流行的風(fēng)格？
【嵌牛正文】
散彈槍編程
這種編程風(fēng)格是一種開發(fā)者使用非常隨意的方式對待代碼绵载」÷剑“嗯，這個方法調(diào)用出錯了……那么我會試著把傳出的參數(shù)從 false 變成 true!”娃豹，當(dāng)然依然出錯焚虱，于是我們的程序員會這樣：“好吧，那我就注釋掉整個方法吧”懂版，或是其它更為隨意的處理方式鹃栽，直到最后讓這個調(diào)用成功∏耄或是被旁邊的某個程序員指出一個正確的方法谍咆。
如果我們把一個正規(guī)的程序員和一個撞大運的程序員放在一起做結(jié)地，那么私股，那個正規(guī)的程序可以馬上變得發(fā)瘋起來，并且恩掷，可以把正規(guī)的程序員的智商降到最低倡鲸。兩個撞大運的程序員不應(yīng)該在一起做結(jié)對編程，這是因為他們破壞性的才能會造成的傷害會比只有一個還差黄娘。
撞大運編程
這是一種比散彈槍編程要溫和一些的編程方式峭状，我相信這種方式可能會是大多數(shù)程序員都會使用的方式。這種編程方式經(jīng)常出現(xiàn)于程序員并不確切知道他們在干什么逼争，也不知道所寫的程序的本質(zhì)和實際优床，但是可以讓程序工作起來。他們以一種撞大運的方式在寫程序誓焦，某些時候胆敞，他們根本就不知道某個錯誤的原因，就開始稀里糊涂地修改代碼杂伟。
一旦出現(xiàn)問題移层，他們會用兩條路：
1）停下來，理解一下程序赫粥，找到出錯的原因观话。
2）使用散彈槍編程方式開始解決問題。
測試驅(qū)動開發(fā)（Test Driven Development）是一種可以用來拯救上百萬的撞大運編程的程序員越平。于是频蛔，他們有了一個更為NB的借口：只要我的程序通過測試了灵迫，你還有什么話好說？別罵我晦溪，測試驅(qū)動開發(fā)是一個不錯的事物瀑粥，其主要是用來控制撞大運開發(fā)所帶來的問題。
Cargo-Cult 編程
關(guān)于Cargo Cults 這個詞兒來自二戰(zhàn)期間的某些太平洋上小島里的土著人尼变。在戰(zhàn)爭期間利凑，美國利用這些小島作為太平洋戰(zhàn)場上的補給站。他們在這些小島上修建自己的飛機跑道以用來運輸戰(zhàn)爭物資嫌术。而那些小島上的土著人從來沒有見過飛機哀澈，當(dāng)他們看到飛機的時候，覺得相當(dāng)?shù)呐６绕梢詾槟切┌兹藥砀鞣N各樣的物品和食物割按。當(dāng)二戰(zhàn)結(jié)束后，那些土著人仿照著修建了飛機跑道磷籍，并用竹子修建了塔臺适荣。然后就在那期望著有飛機為他們送來物品和食物。
Cargo Cult 編程是一種非常流行的編程方法院领，使用這種方法的程序員會學(xué)習(xí)其它編程高手的編程方法弛矛，雖然他們并不知道為什么高手們要那樣做，但是他們覺得那樣做可以讓程序工作起來比然。舉個例子丈氓，當(dāng)時有大量的程序員在J2EE出現(xiàn)的第一年中過度地使用了EJBs和Entity Beans。
刻舟求劍編程
刻舟求劍是一個很流行的寓言了强法。這種風(fēng)格的編程在程序員的圈子里是非常常見的万俗。比如，有一天饮怯，你發(fā)現(xiàn)了一個空指針的異常闰歪，于是你到了產(chǎn)生空指針異常的地方，簡單地放上一個判斷： if (p != NULL)蓖墅。
是的库倘，這樣的fix可以讓你的程序工作起來，但你并沒有真正地解決問題置媳。你只不過是在你的船邊記下了劍掉下去的位置于樟，這樣做只不過把問題隱藏起來，最終只會讓你的程序的行為變得神出鬼沒拇囊。你應(yīng)該找到為什么指針會為空的原因迂曲，然后再解決這個問題。
設(shè)計模式驅(qū)動型編程
正如這種編程的名字所說的寥袭，這種編程風(fēng)格使用大量的設(shè)計模式路捧，在你的程序中关霸，四處都是設(shè)計模式，你的代碼到處都是Facade杰扫，Observer 队寇，Strategy，Adapter章姓，等等等等佳遣。于是，你的程序要處理的業(yè)務(wù)邏輯被這些設(shè)計模式打亂得無法閱讀凡伊，最后零渐，也不知道是業(yè)務(wù)需求重來，還是設(shè)計模式重要系忙，總之诵盼，實際業(yè)務(wù)需求的程序邏輯被各種設(shè)計模式混亂得不堪入目。
偵探型編程
在解決一個Bug的時候银还，偵探型程序員會調(diào)查這個Bug的原因风宁。然后，則調(diào)查引發(fā)這個BUG的原因的原因蛹疯。再然后戒财，其會分析修正代碼后是否會導(dǎo)致其它代碼失敗的因果關(guān)系。再然后然后捺弦，他會使用文本搜索查找所有使用這個改動的代碼固翰，并繼續(xù)查找更上一級的調(diào)用代碼。最后羹呵，這個程序員會寫下30個不同的情形的測試案例，就算這些測試案例和那個Bug沒有什么關(guān)系疗琉，最最后冈欢，這個程序員有了足夠多的信心，并且精確地修正了一個拼寫錯誤盈简。
與此同時凑耻，其它一個正常的程序員修正了其它5個Bug。
屠宰式編程
使用這種風(fēng)格的程序員柠贤，對重構(gòu)代碼有著一種難以控制的極端沖動香浩。他們幾乎會重構(gòu)所有經(jīng)手的代碼。就算是在產(chǎn)品在Release的前夜臼勉，當(dāng)他在修正幾個拼寫錯誤的bug同時邻吭，其會修改10個類，以及重構(gòu)與這10個類有聯(lián)系的另20個類宴霸，并且修改了代碼的build腳本囱晴，以及5個部署描述符膏蚓。
