如何更优雅的编码？
??點擊上方?好好學java?，選擇?星標?公眾號
重磅資訊、干貨，第一時間送達 今日推薦：牛人 20000 字的 Spring Cloud 總結，太硬核了~作者：會長 來源：https://www.cnblogs.com/zzy0471/p/7236309.html筆者認為做到比較優雅地編碼，需遵從如下約束，排名分先后：
良好的命名
清晰的結構
不十分差勁的算法
下面逐一說明：
良好的命名
名不正，則言不順，言不順，則事不成 ── 孔子
孟子曰：“孔子說的對”。
命名很重要，隨便一本邏輯學教材（如果讀者有興趣，此處推薦《邏輯學導論》）里都會有長篇大論來討論命名的問題，我國古代在人才輩出的百家爭鳴時期曾經出現過一個學派叫“名家”，專門討論命名的問題，比如著名的“白馬非馬”、“離堅白”等，有空讀讀還是挺有趣的，比玩王者榮耀還有趣。筆者認為我國到目前為止出現了三個思想大解放時期：一，春秋戰國時期的百家爭鳴，可惜被秦皇的郡縣制大一統所終結；二，民國時期，西方思想初涌，國人似驚雷轟頂，如夢方醒；三，當下，技術革命使得中央思想控制力度急劇下降，使得底層人民有了選擇被誰控制思想的自由（請參考如今基于互聯網的粉絲文化，圈子文化）。所以大家一定要好好寫代碼，才不負少年頭呀。
回歸主題，命名應該本著不怕長就怕不清楚的原則，盡量把一個類、方法、變量的含義交代清楚，實際上筆者比較喜歡OC的方法（消息）命名規則，比如：
(void) buy:(NSString*)something from:(NSString*)store at:(NSDate*)time;
長，但是很清楚。下面詳述命名：
接口的命名
接口的命名一般都是前綴 I 加上名詞或形容詞，實際上.Net Framewrok類庫就是這樣做的，比如：
System.Collections.Generic.ICollection（名詞）
System.Collections.Generic.IEnumerable（形容詞）
接口往往用來分裝一個或一組行為，實現接口的類意味著它具有了一個或一組行為的能力，所有常用形容詞。當實在找不到一個恰當的形容詞時，名詞也可以。
抽象類
抽象類通常不需要加前綴或后綴，也有部分大牛喜歡給抽象類視情況加Base后綴。如下的命名筆者覺得就不錯：
Shape（抽象類）
Ellipse（具體類）
Rectangle（具體類）
具體類
盡量使用名詞，不排除個別情況下把一個行為封裝為類時使用動詞。
方法
使用動詞或動詞性短語。
以上。筆者覺得其它的字段啊、屬性啊、事件啊出現命名問題的比較少，不再討論。比如有的人喜歡字段用下劃線開頭，有的人喜歡用**m_**開頭，都無關緊要，求同存異，只要使用的詞語恰當，并不會帶來太多麻煩。反倒是如果規定一個巨細無比的規范才有問題，一是耗費編撰者的時間，二是閱讀者也記不住，三是閱讀者記住了也可能因為和自己的習慣不同而心存抵觸。
此外需強調一點就是少用拼音多用英文，少用縮寫多用全稱，盡量不用拼音縮寫，甚至是方言拼音縮寫，還有英語加拼音，甚至是英語加拼音縮寫......。但也不能排除個別如“計劃生育”這樣的不好翻譯的詞語可以用拼音，需注釋明確或維護詞匯表。另外，縮寫也不是不可以用，一些大家約定成俗的縮寫比如“Id”，使用之并不會帶來誤解，還有利于代碼的清晰度。
有時候由于英語水平的問題，畢竟我們的母語不是英語，難免會出現不知道用什么單詞的情況。此時，可以試試codelf，感謝據說是網易工程師unbug開發的此工具。這個應該讀作[ko?d?f]吧，但是倒數第二個字母不是I,是L。
清晰的結構
基本要求
if、while等關鍵字包裹的表達式，即使只有一句，也盡量使用大括號括起來
盡量避免使用直立人時代的goto語句
盡量避免過長的方法，把大方法拆分為數個小方法，方法的職能盡量單一
盡量避免重復代碼，將其轉移到公共工具中
盡量避免過大的類，拆分為數個類，各司其職
適當的注釋，注釋太多，說明代碼本身的表達力可能還有待加強。有些實在難纏的邏輯，可以寫詳細注釋，如果不寫注釋，離職時請注意不要泄露給擦屁股人自己的地址
較高要求
熟悉以下常用面向對象的設計原則：
開放-封閉
單一職責
里氏替換
依賴倒置
接口隔離
再高要求
熟悉常用設計模式:
工廠方法
抽象工廠
建造者模式
單例模式
適配器模式
外觀模式
觀察者模式
命令模式
代理模式
策略模式
面向對象語言的三大特征人人都知道，但是真的用好卻是不容易，三大特征僅僅是面向對象設計的基礎，在此基礎上建立起了面向對象的高樓大廈。筆者工作多年，常感嘆虛度年華，至今尚未精通面向對象設計之十之五六。筆者想極力推薦一本書：《Head First 設計模式》，此書乃Head First系列成名之作。此外，這個網站不錯，言簡意賅，案例經典：www.oodesign.com。此外，《Java編程思想》開頭部分關于面向對象設計的講解也很精彩。
使用成熟的設計模式有兩個好處：
這些解決方案已經經受過了考驗，用了即使無功，但也不會犯錯
設計模式的名稱本來就一種在程序員間流傳的概念，基于共同的對概念的認識能夠降低溝通成本
當然也有壞處，代碼的擴展性雖然是好了，但是代碼的復雜性也高了，這就要求我們最好熟悉常用的設計模式，這樣就得到了它的好處，規避了它的壞處。
必須要注意的是：不要亂用設計模式，只有需求產生了變化，或預見了需求將要發生變化才使用這些模式來封裝發生的或可能發生的變化。有時候再重構代碼時也會用到，比如外觀模式和設配器模式等。
更高要求
能力越大，責任越大 ──蜘蛛俠
大項目肯定不是一個人能完成的，人多了容易發生混亂，此時需要團隊的領袖勇敢地承擔起義不容辭的責任，包括但不限于：
定期維護代碼框架、分層結構。寫的時間長了難免亂，領袖人物要定期排除，及時消除臭味
引導小弟們做代碼審查。審查的意義不在于監督，而在于學習和維持良好的態度。學習指通過代碼審查學習別人的長處，同時幫助別人進步。保持良好的態度是指如果預知了有人會看自己的代碼，那么就會自覺地盡量把代碼寫工整，即使審查代碼的人偷懶沒有真真看過，正所謂，如果人人都相信三尺之上有神靈，那么也就沒人做壞事了，宗教的積極意義就在于此，扯遠了。
過目數據庫設計
及時更新或委派組員更新文檔
關于文檔，還需多說一句：只有再非常有必要寫文檔的情況下才寫文檔。如果寫了一大堆可有可無的文檔，代碼更新后文檔也要及時更新，很難做到的。一個新手面臨著一堆和代碼脫節的文檔只會起誤導作用，以代碼本身的表達力和口頭交流為主，以文檔交流為輔，兩手都要抓，一只手硬，一只手軟。
不十分差勁的算法
相信大部人做的項目都是性能不敏感的，只要稍稍注意就能做好。比如該使用分頁的地方就使用分頁，該根據條件查詢數據庫的就別一次都查出來，該優化數據庫就優化數據庫。
此外，壓力測試也很有必要，有的性能問題只有在數據量大了的情況下才出現。很多性能問題都是到了生產環境中才暴漏出來的。
代碼之外
和團隊建設比起來，以上只能算是雕蟲小技，只起到了一個錦上添花的作用。如何使團隊保持活力，保持積極性才是最重要的，通常也是最容易被領導忽視的，最難做好的，這些已超出筆者能力范圍和本文的論述重點，有機會再寫。祝大家工作愉快！
作文以記之
丁酉年夏，鵬鎮守武漢。數月，政通人和，百廢俱興，乃重修代碼規范，屬予作文以記之。予觀博客園勝狀，駝峰命名，強制注釋，迫之蕓蕓碼士，俱迂腐巨細之論，此前人之述備矣。然，求同存異，團隊建設，收買人心，論之甚少，此大道也，得之可平天下。
總結
- 上一篇： 科普：String hashCode 方
- 下一篇： 妈妈再也不担心我面试被 Redis 问得