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