引用：http://www.cnblogs.com/komojoemary/p/5760437.html
如何才能編寫出優質程式碼，每個開發人員都有自己的理解。我大致整理了下面十八個招數，供大家參考。正像武學界的武功一樣，每門功夫都需要一個名字，正好個人比較喜歡降龍十八掌，而正好也有十八招
第一招：養成一個好習慣
在我第一年工作的時候，我有幸加入了一個好團隊，另外有一個很好的領導者。我至今記得他跟我們講的第一句話：一個良好習慣的養成對你們以後的工作非常重要，當然它需要你從一開始就去培養，並且持之以恆，堅持不懈。而我們下面講的很多內容，或者說絕大部分內容都可以算做這個好習慣中的一部分。
第二招：規範你的程式碼
沒有規矩，不成方圓。程式碼遵循統一的格式規範，首先便於自己日後維護，其次便於移交他人。自己讀起來清晰明朗，他人看起來整潔規範，這對一個專案團隊，一個公司來說尤為重要。檢查的方式也很簡單，如果整個專案的程式碼最後看起來是同一個人的風格，那麼證明你遵循了規範。就好比我們讀書年代的考試，你的考卷整潔清晰，肯定會給你附加分。這裡我們舉個例子來說：如何規範一個類中程式碼。首先成員變數的定義需要放在一起，不能幾個在上面，幾個在中間，幾個又跑到下面去；接著是類中方法定義；最後是成員變數的get/set方法。同時，可以繼續按照public、protected、private3種來細分。
第三招：合理註釋你的程式碼
很多人寫程式碼不喜歡註釋，或者覺得專案時間緊，忙於實現了交差，或者覺得沒有必要，反正可以看懂。
另外一部分人喜歡程式寫完後再來註釋，有點補交作業的概念。
只有少部分人會在程式碼開始之前，進行思路整理，寫出程式碼邏輯各步驟，各分支的註釋，然後在註釋下面填充實現程式碼。
顯然，第三種才是最正確的做法，正所謂：兵馬未動，糧草先行。當然也是最難的，但是你只要習慣了，它也就soso了。
一份合格的程式碼的註釋率一般在30%以上。
第四招：不寫重複程式碼
我想我們每個開發人員應該把它當成孫悟空的緊箍咒，時時刻刻都要念上幾遍來反覆提醒自己。重複程式碼絕對是垃圾程式碼的第一特徵，並且是最大的特徵。Copy的時候會很爽，但往往有樂極生悲的時候，一旦出錯，意味著加倍的工作量和持續的不可控。
不寫重複程式碼的最高目標是不寫兩行一摸一樣的程式碼，當然這僅存在理論的可能，我們僅需要做到不寫兩份功能一致或相似的程式碼即可。這個度我想你可以掌握。
第五招：不寫過多引數方法
當你的方法引數超過5個時，你就要考慮你這個方法設計的是否合理了。真的需要這麼多引數嗎？是否可以精簡？如果實在必須，那麼你也是到了必須改變的時候，封裝物件來進行傳遞吧，這樣不僅減少了引數個數，也為以後提供了無窮擴充套件的可能。同時使用者也不必去硬記引數的順序。
第六招：不做脫褲子放屁的事
脫褲子放屁是一件無意義的事，我想不會有人去做這樣的事吧。我們編碼的時候，也是如此，沒有意義的程式碼就不需要寫了。
我們開發的時候，常常會通過copy來實現一些功能，但是copy過來後，會引入很多使用不到的東西，這些程式碼擱置在那邊完全就是無意義的，可以刪除。
另外我們經常會不經意的犯一些這樣的錯誤：寫if else if else 判斷語句的時候，條件判斷會出現重複，分支裡面的程式碼可能永遠不會執行等，這些其實都是我們在碼之前沒有理清思路導致的，也就是我們前面所說程式碼註釋的重要性了。
過多的考慮將來的可能性：有的時候我們考慮程式碼的可擴充套件性時，會進入一個誤區，也就是過猶不及的概念。帶入了非常多當前並沒有出現的可能性，這些內容可能永遠不會用到，完全沒必要在當前就寫進去。
第七招：限制好你的閥門
開閘放水，關門放狗，講究的是一個入和出，寫程式碼也一樣。
小的來說，我們的方法，入參的考慮需要夠講究，夠精細；出參的位置需要限制到方法的尾部。很多人喜歡在方法的中間用return來終止方法的執行。比如做一些check的時候，不滿足就return，這不是一個好的做法，雖然執行上面並沒有什麼問題，但保證統一出口更重要。
比如你需要記錄執行日誌，或者在方法出口時需要做一些額外的事情時，那麼統一出口會很方便，否則你需要在每個return處去處理。
大的來說，我們開放給外部使用的介面，是否被限制在了一個層面上。這個時候用代理模式、門面模式會是一個比較好的做法。過多的特性開放給外部時，有時候反而會讓人不易掌握。用代理做一層封裝，再統一門面後，會使得程式碼出入口更可控。
第八招：正確擺放你的程式碼
有的人說：啊哈，我學了core Java，我會了所有的基礎，我可以去程式碼的世界自由遨遊了。這話不能說它錯，但如果你僅僅考慮就實現功能去做事的話，那就跟壘磚是一樣的了。怪不得我們程式設計師常常會==泥水匠。其實你除了要實現功能外，你還要考慮的事情非常多，正確擺放你的程式碼位置就很重要。檢查你的方法，看裡面的實現邏輯是否應該放在這個名稱的方法中；檢查你的類，看裡面的方法是否應該放在當前類中；檢查你的工程，看裡面的類是否應該放在這個工程裡面。一層層檢查，你該發現你的程式碼有多少問題了吧。這有時候就是人的過程性思維導致的，從大的方面來講是我們抽象的不夠。
第九招：多為你的使用者考慮
做任何事情如果沒有服務的物件，也就失去了它本身的意義，同樣的編碼也是如此。或者你是做框架做產品的，那麼你面對的就是普通開發人員，或者你是做專案的，那麼你面對的就是我們通常意義上的客戶。不管你面對的是什麼物件，一個好的出發點非常重要：多為你的使用者考慮，也就說我們常說的，客戶至上。這裡我們拿編寫工具方法為例：當你寫出一個非常好的工具元件，最後你要考慮的肯定是開放的api介面，該開放哪些介面，介面的引數如何。這些都需要你從使用者的角度出發，你才能考慮的儘可能完善。不管是java裡面的過載，亦或是設計模式裡面的介面卡，說的都是這個概念，為的都是讓你的使用者儘可能的簡單，少做事情。
第十招：加強你的理解能力
十幾年的語文學習，不知道對你如今的工作有多大影響。在我看來，最大的作用就是培養了我們的理解能力。理解能力對於開發人員來說非常重要：
快速理解客戶意思，能夠保障你良好溝通進行
正確理解需求，能夠保障你方向的正確性
同樣的，優秀的理解能力能夠使你輕易讀懂他人程式碼。
第十一招：設計模式
設計模式的出現，是為了解決一些通用問題的套路，它能使你的程式碼更加優美、高效。23種設計模式，更多的是一種概念思想。我們學的時候可以從簡單易用，且常用的一些出發。比如工廠、單例，逐漸的我們可以嘗試代理、介面卡、合成、門面，最後我們可以運用一些較複雜的觀察者等。為了可以更好的理解，當你學完全部的之後，你可以去學習下反設計模式，它會讓你選取設計模式應用場景的時候更加的契合，合理。
第十二招：拆卸你的程式碼
在我工作了5年之後，我終於明白，評價一份程式碼的優劣，其中一個非常重要的指標就是：是否易於拆卸。簡單來說，就是它的耦合性。這裡的耦合分為內耦合和外耦合。我們一般注意到的是外耦合，即我們的程式碼與外部程式碼之間。其實內耦合在某些時候更加的重要：我們的程式碼內部之間的關係。比如你做了一個持久化服務工具，裡面涵蓋了3塊內容：增刪改查、指令碼操作、資料定義。整個持久化服務不依賴於外部的任何內容，或者依賴的層面會切割到一條線上，那麼代表你這份程式碼的外耦合控制的非常好。這個時候我們有個同事想用到一個資料定義的功能，但是它想在裡面加入非常多的個性化，也就是說他僅僅想要1/3的內容，這個時候你的程式碼如果能夠很好的拆卸出來，而不破壞其他部分的平衡，你的內耦合才算達標。
第十三招：檢查工具幫你忙
碼完程式碼後，用上一些簡單的靜態檢查工具，比如checkstyle、fingbug等，可以很方便的檢查出你程式碼中格式、以及一些隱藏的漏洞。
另外可以做下單元測試，讓你的程式碼更健壯。
第十四招：溫故而知新
個人認為最好的一招，每隔一段時間，多回過頭去看看你之前寫的程式碼，可以一週，一個月。要把你寫的程式碼當作自己的孩子一樣去呵護，如果你還沒有孩子，那當成男女朋友吧，或者小夥伴吧。簡而言之，我們要對它充滿感情，程式碼其實也是有生命力的。一份好的程式碼或許會存活很長時間，一年、兩年、十年。但是一份糟粕估計很快就會被推翻重構。每次回顧你應該都可以找出你程式碼中的一些問題，這樣逐漸的你們2人都在不斷成長。
第十五招：學會站在巨人肩膀
有時候很多功能，度娘和google神器都可以幫你輕易的解決，所以完全沒有必要自己絞盡腦汁，重起爐灶。因為已經有巨人助你攀登的更高了，為什麼不享用呢。但是你會正確使用這個巨人嗎？你是否是copy過來之後不加理解就進行使用呢？過後遇到問題束手無策。
因為我是做框架的，所以我遇到這類的問題會比較多。因為常常有人向我抱怨更新框架的複雜與風險，因為更新之後會出現各種問題。其實這些有兩方面的原因：一是框架釋出的時候本身存在一些問題；另外就是我們使用框架的方式並不正確。
正確踏上巨人肩膀首先你應該做到如下幾件事情：
- 對你所用的內容熟悉，這是最起碼的。比如你用到了哪些內容，這些都需要了如指掌。
- 最好能夠將你應用的層面做下限制，也就是我們上面講到的閥門的另一種情況了。比如你應用了一個第三方的功能，那麼接入你的專案時，你是直接寫到你的業務處理程式碼中，還是說會對其做一次封裝呢？顯然後者是一種正確的做法。雖然會耗費你一些額外的時間，但是不僅能夠提高重用，而且一旦以後實現方式或者版本做升級，你需要付出的就會大大減少了。
- 正確把握個性化的度
有時候你需要用到框架某個功能，但是卻有很多不滿足，這個時候一般會考慮進行個性化程式碼實現。一般的做法都是簡單粗暴型：copy出原始碼進行修改。
其實好的一個做法是要先進行考慮，這個個性化的內容是否是框架原有功能的補充和完善，如果是，那麼應該是提交框架去解決；或者自己實現了提交框架去整合然後供其他專案複用，也就是說該功能隸屬原功能。
第二個做法是考慮在原有功能做一些擴充套件修改來支援：比如加上一些反射外調介面處理。這樣個性化業務的內容還是自己搞，但是隸屬框架的原功能都可以進行復用。
第三個做法是進行繼承，原理和第二個一樣。
最後才是考慮copy程式碼來進行修改。
基於原功能來做，最大的好處就是原功能一旦做優化和升級，那麼你的這塊內容將無縫得到升級。否則將來如果你想走回來，花的代價將非常大。
第十六招：開始砍你的程式碼吧
當我們還在呼哧呼哧為了實現一些新功能編寫大量程式碼的時候，很多大牛的做法卻與你截然相反，他們在不停的砍削原有程式碼，有的時候他們可以依靠精簡程式碼來實現新需求。砍程式碼的另一個叫法是重構。
第十七招：一份詳盡優美的指南
春秋的時候，有很多的說客，光憑三寸不爛之舌就可以攻城略地，退兵攘敵，可見說出來的重要性。所以不僅要實幹，還需要能夠將你做的內容展示出來。作為一個編碼的程式設計師，更多可能就要靠寫了，這個寫一般就是一份指南，說白了就是一份文件。大到整個系統的操作手冊，小到功能模組的api。就像市場營銷一樣，你需要把你做的東西推薦出去，讓大家意識到這個東西的價值，好處，才會有人來買單。
所以，加強你的文件能力吧，騷年。
第十八招：無招勝有招
看過武狀元蘇乞兒的都知道，最後周星馳跌倒在地，觀看降龍十八掌祕籍，風吹捲動，最終前面十七招融合就成了第十八掌：神龍擺尾。我們的編碼也是如此，當你能夠將所有東西都融會貫通後，你也就不需要去拘泥那麼多的套路了，因為你本身已經習慣成自然，你的一舉一動都已經是非常好的招式了。當然，對於這種境界，我還一直在路上。