如何寫出優美的 JAVA 代碼（轉）

一、不要使用魔法數字，儘量定義枚舉、常量、宏： 
我常常見到表示各種狀態的數字，0，1，2....，我真的不知道這表示什麼含義，如果 
你在不在文檔中說明的話，這個東東過幾天連你自己都不知道個一二三了。 

二、命名要具有描述力，儘量使用全名而不是自創的縮寫，除非地球人都這麼用這個縮寫： 
我常常看到一些自創的縮寫，這個縮寫或許只有你自己知道，類名，方法名，參數名 
尤其要有好的描述裏，局部變量尚可容忍。我寧可容忍超過40個字符的命令，也不願意 
看到只有一兩個字母的命名，當然迭代用的i,j除外。當然命名不要太長，太長說明你的類和 
方法要做的事情太多，請你拆分出更多細粒度功能單一的類和方法。 

三、同一類東東命名方式儘可能統一，比如類名使用大寫字母開頭的單詞，變量使用 
下劃線分割開來的小寫字母單詞，常量使用下滑線分割的開來的大寫字母單詞。不要 
交替使用。 

四、函數、類功能儘可能單一，不要試圖寫一個萬能/超級函數或者類。 
一個類和方法要有單一的職責，這樣的類和方法只做一件事，並且容易把他做好。 
1、不要試圖寫一個強大無比的方法。 
我常常看到一些試圖寫的多麼“精妙”無比多麼“強大”的函數，事實上不是什麼精妙，而是 
代碼的臭味道。精妙強大無比萬能的方法往往你耗費大量精力去設計算法，試圖覆蓋現在的各 
種可能，而無法面對將來新的需求，隨着新的需求，你的這個精妙的方法需要的修改並且改起來 
極其痛苦。在一次次的痛苦與精妙的演化中，你的方法越來越複雜，並且每一次修改你都會面 
臨影響以前功能的風險。這個方法使用者需要小心的處理你的精妙之處，如果沒有精妙傳遞好參 
數，那麼這個方法再也不精妙了，而是直接廢掉了。 
KISS（keep it simple and stupid）原理就是這個道理，你要使你的代碼儘可能簡單，讓人 
看到有一目瞭然的清爽，而不是因爲設計了一個精妙無比的萬能方法而沾沾自喜。這裏的簡單不是 
簡潔的代名字。有時候簡潔是那種傳說的“精妙”的代碼。 
2、不要寫做多件事情的方法和類，你做一件事情，你就寫一個對應的方法，不要試圖通過參數來判定各種情況，然後做事情，並且做的事情和你方法描述的不一致。當你發現你的方法名字想不出來好的名字了，或者要加or和and了，那麼請你拆分出更多單一的方法。 
不要舉一些linux完成多種功能系統調用，這是被迫的，因爲系統調用的數量是有限制的，它只有有限的空間來描述系統調用號和系統調用的映射表，不要在應用程序開發中效仿而誤以爲優雅強大。我最噁心根據參數，然後一大堆的if..else 和switch..case判斷。 
五、不要修改已有的類和方法而是擴展它。 
這是程序設計的一個重要原則，開閉原則，在面向對象的語言中尤爲重要。在面向過程中主要表現在，不要在一個函數要應對和這個函數相似的一個需求了，就在這個加個if，來修改這個方法，試圖重用和避免重複。而是要把公用的部分抽出來成一個小的功能函數，然後增加一個應對新的類似這個需求的處理方法。在面向對象中，例如使用策略模式、訪問者模式、Extend Object模式。 
六、不要重複你自己（DRY）： 
程序最怕的是copy,paste，到處是重複的代碼。copy，paste經常被誤以爲快速完成需要用的功能的高效方式而被到處使用。你每重複一次，你就得負責保持他們的一致性，你就得在一處增加新的功能時，你就的把這個的功能加到其他地方。還在我剛會寫代碼的時候去了一個小公司，他們的代碼到處是copy，paste的痕跡，當要在現有的功能增加審計功能是，他們開始下命令了，每個人加幾行代碼來做審計，真不知道那麼多人寫的審計版本，分散到那麼多處，這個審計功能是否可信有用。 
避免DRY的方法就是抽象，分離變化。不管是面向對象還是面向過程，分離變化並抽象之是最主要的設計原則。設計模式中的模板方法，我們常用的回調都是我們常用的方法。 
我發現越是提供更多回調處理的語言和框架，就越具有靈活性和易用性。ruby語言之所以有如此的威力，主要是因爲它提供了更多的回調處理。它可以在動態的給一個類增加方法，這樣可以在超類中定義增加方法的方法，然後再子類調用，子類就具有無比的能力。它的block提供了強大的回調機制，我只要不知道如何處理了我就yield出來，method missing機制更是神祕無比，你可以寫出像find_by_name_and_age,2.days.ago這樣像自然語言一樣易讀的代碼。 

七、不要跨越邊界，在適合的地方寫代碼。 
在分層的架構中，不要跨越層的邊界。例如web開發的三層架構: 
數據訪問層（DAO)、業務層(Service)、表現層。 
不要在業務層裸寫SQL來做事情，不要在業務層摻和進來表現層的東東，不要在表現層/控制器中寫業務的東東。既然已經分層了，那麼就要好好的遵守它，如果到處跨越邊界的話，那麼和不分層沒有什麼區別，使得每一層都不倫不類。例如你應該在業務層進行事務管理，而你的控制器到處是業務代碼，那將無法控制。如果你的業務層到處是SQL，我不知道你的DAO存在的意義了。 
八、分層的web架構： 
DAO層最好按照模型來劃分dao類，如果業務很簡單，也可以將相關的模型合併爲一個DAO。 
Service層，不要按照DAO和Service一一對應的方式劃分，而是要按照業務的類別和實際情況來劃分。事實上Service層通常是用來處理涉及到多個模型的業務，而涉及到一個模型的業務，常常被放在模型中，這是一種自然而更面向對象的設計方法。只有數據的模型被稱爲貧血型模型，這種模型被認爲是對面向對象的一種背離，而在模型中放置專有的業務方法，不僅有利於公用，而且模型更具有描述力。 
九、關於MVC: 
MVC是一種鬆耦合的設計方案，最容易誤用的就是控制器（c）。控制器只負責調用業務方法，準備好數據供View去展現。而不要把業務和如何展示的東東放在裏面。我常常看到有人在控制器中拼html片段和寫一些業務相關的代碼。 
十、順便說一下異常的使用。 
如果你是使用語言支持異常機制，那麼儘可能的使用異常機制和定義好與自己業務相關的異常，而不是通過返回值表示正確和錯誤。如果你使用的語言支持異常機制，請不要寫類linux下c似的代碼形式，每寫一個函數，我就寫一個判斷返回值調用是否成功，嚴重分離了我對核心業務的關注。異常提供了優雅的處理錯誤的方法。 

總之，你在寫代碼的時候，你儘量考慮使用你接口的人和閱讀你代碼的人，不要讓他們不爽。 
先寫到這裏，希望對大家有所幫助