??點擊上方?好好學java?，選擇?星標?公眾號

重磅資訊、干貨，第一時間送達 今日推薦：牛人 20000 字的 Spring Cloud 總結，太硬核了~作者：會長 來源：https://www.cnblogs.com/zzy0471/p/7236309.html

筆者認為做到比較優(yōu)雅地編碼，需遵從如下約束，排名分先后：

• 良好的命名

• 清晰的結構

• 不十分差勁的算法

下面逐一說明：

良好的命名

名不正，則言不順，言不順，則事不成 ── 孔子

孟子曰：“孔子說的對”。

命名很重要，隨便一本邏輯學教材（如果讀者有興趣，此處推薦《邏輯學導論》）里都會有長篇大論來討論命名的問題，我國古代在人才輩出的百家爭鳴時期曾經出現(xiàn)過一個學派叫“名家”，專門討論命名的問題，比如著名的“白馬非馬”、“離堅白”等，有空讀讀還是挺有趣的，比玩王者榮耀還有趣。筆者認為我國到目前為止出現(xiàn)了三個思想大解放時期：一，春秋戰(zhàn)國時期的百家爭鳴，可惜被秦皇的郡縣制大一統(tǒng)所終結；二，民國時期，西方思想初涌，國人似驚雷轟頂，如夢方醒；三，當下，技術革命使得中央思想控制力度急劇下降，使得底層人民有了選擇被誰控制思想的自由（請參考如今基于互聯(lián)網的粉絲文化，圈子文化）。所以大家一定要好好寫代碼，才不負少年頭呀。

回歸主題，命名應該本著不怕長就怕不清楚的原則，盡量把一個類、方法、變量的含義交代清楚，實際上筆者比較喜歡OC的方法（消息）命名規(guī)則，比如：

(void) buy:(NSString*)something from:(NSString*)store at:(NSDate*)time;

長，但是很清楚。下面詳述命名：

接口的命名

接口的命名一般都是前綴 I 加上名詞或形容詞，實際上.Net Framewrok類庫就是這樣做的，比如：

• System.Collections.Generic.ICollection（名詞）

• System.Collections.Generic.IEnumerable（形容詞）

接口往往用來分裝一個或一組行為，實現(xiàn)接口的類意味著它具有了一個或一組行為的能力，所有常用形容詞。當實在找不到一個恰當?shù)男稳菰~時，名詞也可以。

抽象類

抽象類通常不需要加前綴或后綴，也有部分大牛喜歡給抽象類視情況加Base后綴。如下的命名筆者覺得就不錯：

• Shape（抽象類）

• Ellipse（具體類）

• Rectangle（具體類）

具體類

盡量使用名詞，不排除個別情況下把一個行為封裝為類時使用動詞。

方法

使用動詞或動詞性短語。

以上。筆者覺得其它的字段啊、屬性啊、事件啊出現(xiàn)命名問題的比較少，不再討論。比如有的人喜歡字段用下劃線開頭，有的人喜歡用**m_**開頭，都無關緊要，求同存異，只要使用的詞語恰當，并不會帶來太多麻煩。反倒是如果規(guī)定一個巨細無比的規(guī)范才有問題，一是耗費編撰者的時間，二是閱讀者也記不住，三是閱讀者記住了也可能因為和自己的習慣不同而心存抵觸。

此外需強調一點就是少用拼音多用英文，少用縮寫多用全稱，盡量不用拼音縮寫，甚至是方言拼音縮寫，還有英語加拼音，甚至是英語加拼音縮寫......。但也不能排除個別如“計劃生育”這樣的不好翻譯的詞語可以用拼音，需注釋明確或維護詞匯表。另外，縮寫也不是不可以用，一些大家約定成俗的縮寫比如“Id”，使用之并不會帶來誤解，還有利于代碼的清晰度。

有時候由于英語水平的問題，畢竟我們的母語不是英語，難免會出現(xiàn)不知道用什么單詞的情況。此時，可以試試codelf，感謝據(jù)說是網易工程師unbug開發(fā)的此工具。這個應該讀作[ko?d?f]吧，但是倒數(shù)第二個字母不是I,是L。

清晰的結構

基本要求

• if、while等關鍵字包裹的表達式，即使只有一句，也盡量使用大括號括起來

• 盡量避免使用直立人時代的goto語句

• 盡量避免過長的方法，把大方法拆分為數(shù)個小方法，方法的職能盡量單一

• 盡量避免重復代碼，將其轉移到公共工具中

• 盡量避免過大的類，拆分為數(shù)個類，各司其職

• 適當?shù)淖⑨?#xff0c;注釋太多，說明代碼本身的表達力可能還有待加強。有些實在難纏的邏輯，可以寫詳細注釋，如果不寫注釋，離職時請注意不要泄露給擦屁股人自己的地址

較高要求

熟悉以下常用面向對象的設計原則：

• 開放-封閉

• 單一職責

• 里氏替換

• 依賴倒置

• 接口隔離

再高要求

熟悉常用設計模式:

• 工廠方法

• 抽象工廠

• 建造者模式

• 單例模式

• 適配器模式

• 外觀模式

• 觀察者模式

• 命令模式

• 代理模式

• 策略模式

面向對象語言的三大特征人人都知道，但是真的用好卻是不容易，三大特征僅僅是面向對象設計的基礎，在此基礎上建立起了面向對象的高樓大廈。筆者工作多年，常感嘆虛度年華，至今尚未精通面向對象設計之十之五六。筆者想極力推薦一本書：《Head First 設計模式》，此書乃Head First系列成名之作。此外，這個網站不錯，言簡意賅，案例經典：www.oodesign.com。此外，《Java編程思想》開頭部分關于面向對象設計的講解也很精彩。

使用成熟的設計模式有兩個好處：

• 這些解決方案已經經受過了考驗，用了即使無功，但也不會犯錯

• 設計模式的名稱本來就一種在程序員間流傳的概念，基于共同的對概念的認識能夠降低溝通成本

當然也有壞處，代碼的擴展性雖然是好了，但是代碼的復雜性也高了，這就要求我們最好熟悉常用的設計模式，這樣就得到了它的好處，規(guī)避了它的壞處。

必須要注意的是：不要亂用設計模式，只有需求產生了變化，或預見了需求將要發(fā)生變化才使用這些模式來封裝發(fā)生的或可能發(fā)生的變化。有時候再重構代碼時也會用到，比如外觀模式和設配器模式等。

更高要求

能力越大，責任越大 ──蜘蛛俠

大項目肯定不是一個人能完成的，人多了容易發(fā)生混亂，此時需要團隊的領袖勇敢地承擔起義不容辭的責任，包括但不限于：

• 定期維護代碼框架、分層結構。寫的時間長了難免亂，領袖人物要定期排除，及時消除臭味

• 引導小弟們做代碼審查。審查的意義不在于監(jiān)督，而在于學習和維持良好的態(tài)度。學習指通過代碼審查學習別人的長處，同時幫助別人進步。保持良好的態(tài)度是指如果預知了有人會看自己的代碼，那么就會自覺地盡量把代碼寫工整，即使審查代碼的人偷懶沒有真真看過，正所謂，如果人人都相信三尺之上有神靈，那么也就沒人做壞事了，宗教的積極意義就在于此，扯遠了。

• 過目數(shù)據(jù)庫設計

• 及時更新或委派組員更新文檔

關于文檔，還需多說一句：只有再非常有必要寫文檔的情況下才寫文檔。如果寫了一大堆可有可無的文檔，代碼更新后文檔也要及時更新，很難做到的。一個新手面臨著一堆和代碼脫節(jié)的文檔只會起誤導作用，以代碼本身的表達力和口頭交流為主，以文檔交流為輔，兩手都要抓，一只手硬，一只手軟。

不十分差勁的算法

相信大部人做的項目都是性能不敏感的，只要稍稍注意就能做好。比如該使用分頁的地方就使用分頁，該根據(jù)條件查詢數(shù)據(jù)庫的就別一次都查出來，該優(yōu)化數(shù)據(jù)庫就優(yōu)化數(shù)據(jù)庫。

此外，壓力測試也很有必要，有的性能問題只有在數(shù)據(jù)量大了的情況下才出現(xiàn)。很多性能問題都是到了生產環(huán)境中才暴漏出來的。

代碼之外

和團隊建設比起來，以上只能算是雕蟲小技，只起到了一個錦上添花的作用。如何使團隊保持活力，保持積極性才是最重要的，通常也是最容易被領導忽視的，最難做好的，這些已超出筆者能力范圍和本文的論述重點，有機會再寫。祝大家工作愉快！

作文以記之

丁酉年夏，鵬鎮(zhèn)守武漢。數(shù)月，政通人和，百廢俱興，乃重修代碼規(guī)范，屬予作文以記之。予觀博客園勝狀，駝峰命名，強制注釋，迫之蕓蕓碼士，俱迂腐巨細之論，此前人之述備矣。然，求同存異，團隊建設，收買人心，論之甚少，此大道也，得之可平天下。

總結

以上是生活随笔為你收集整理的如何更优雅的编码？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。