讀讀《編寫高質量代碼:改善Java程序的151條建議》

這本書能夠做爲平時寫代碼的一個參考書，這本書以我我的讀的經驗看來，最好是經過平時代碼驅動的方式來讀，這樣吸取的快，也讀的快。

這本書主要講什麼，我本身用了個思惟導圖概述:

根據這種導圖可知，主要講的就是Java語法、JDK API、程序性能、開源工具和框架、編程風格和編程思想等五個點。

我此次主要讀的是關於開源世界和思想開源這兩章，這兩章至關於導圖中提到的開源工具和框架、編程風格和編程思想。因此今天講的也是這兩個方面。

1、開源工具和框架

導圖以下所示:

做者的觀點是:大膽採用開源項目。並對此提出五點建議。不過在我看來的話除了選擇框架和工具需遵循六個原則外，其它四點從導圖上看彷佛沒有多大用處。因此我也不打算詳細說，可是這四點我將其理解爲這些想法和建議。

想法和建議以下:

使用的相關工具類要統一，好比apache common對於String相關的有其專門處理類，儘量不要引用其它具有此功能的，由於容易弄混,並且導包的時候，有些時候安ctrl+alt顯示的太多,若是你不是對對應的API十分熟悉的狀況下，很容易眼花繚亂,在此我要說明的是，工具類統一的好處避免導包眼花繚亂,同時也避免出現爲了實現某個功能須要對應的工具類時，你引用這個，我引用那個。

目前開源項目，我認爲比較不錯的工具類集成項目，就是Hutool,它不只文檔相對完整，並且很多開源項目及其對應的公司也在用。

Hutool官方地址爲:http://www.hutool.cn/

可是在選擇開源框架和工具的時候，最好遵循六個原則:

(1)普適性;

選擇工具或框架必需要考慮項目總體團隊的技術水平，不能有太大的跨度和跳躍性，要確保大部分項目成員對工具比較熟悉，好比在關於持久層的選擇下，選擇MyBatis比Hibernate要好，緣由是由於上手快，學習成本低，再好比MyBatis替換爲MyBatis-Plus，跨度和跳躍性也不大，由於MyBatis-Plus本質上仍是MyBatis，這樣一來團隊學習的成本不多，項目重構的成本很低，同時開發的效率也會提升。

(2)惟一性;

相同的工具只能選擇一種或多種，不要讓多種相同或類似職能的工具並存。例如，hutools能夠代替apache common的相關功能，儘量的選擇其中一種，這樣當項目成員在開發時，有的時候ctrl+shift+O導包時不用考慮導的對不對。

(3)大樹納涼;

找知名的開源項目，好比目前在Java中普遍應用的Spring+MyBatis+SpringMVC等。或者是如今開源項目之一的Jeesite4.0。由於有不少人在用，咱們沒必要擔憂遇到不少Bug,雖然也有，可是因爲用戶的羣體普遍，能夠避免咱們踩不少坑。

(4)精而專;

(5)高熱度;

選擇開源項目儘量選擇那些更新頻繁的。頻繁意味着有人負責維護，出問題了有人負責解決。更新頻繁的總比一年甚至兩年更新甚至已經不更新的項目要好吧。所以咱們再採用開源項目的時候應抱有這樣的觀點，大膽採用，仔細篩選。固然了，還有就是最後若是發現選擇了某個開源項目，忽然做者由於某種緣由不維護了，遇到這種狀況時，不要抱怨對方，也不要詆譭人家，畢竟咱們享受的是他人辛苦貢獻的成果。

 

2、編程風格與編程思想

關於編程風格與編程思想，該做者提出了八點建議，我以爲挺棒的。因此我將其用思惟導圖概括成以下:

1.提倡良好的代碼風格

 

 換行排版總得要把，否則看起來亂七八糟也很差，這個目前大多數人均可以作到。可是風格統一的話，就有點難了，俗話說，一百我的眼裏有一百個哈姆萊特。有點難並不代碼沒有辦法解決，好比如今流行的Java規範手冊《阿里巴巴Java開發手冊》，就能夠借鑑參考。便捷(通用性工具，好比sonar這個代碼質量分析或者是sonar lite這個Eclipse代碼分析插件也是有利於塑造良好的代碼風格。

 

 2.不要徹底依賴單元測試來發現問題

 單元測試確實不能覆蓋全部的場景，由於咱們開發人員在有限的時間內，所能作的測試及其對應的數據場景，也就三種:

(1)正常;

(2)邊界;

(3)異常;

其它的咱們也沒有這個時間去考慮那麼多，即使是有專門的測試人員，測試的場景也仍是有限。更況且像沒有測試的小公司呢。

 

3.讓註釋正確、清晰、簡潔

 

 我以爲上面的這個思惟導圖已經足夠詳細了，因此關於註釋我再也不贅述。

4.接口職責單一

 

5.加強類的可替換性

 

6.依賴抽象而不是實現

 

 

四、五、6涉及對應的設計模式，可是這些設計模式，咱們實際開發中，一直在遵照，同時也一直在破壞。很難有人徹底聽從設計模式的那一套。

7.拋棄七條不良編碼習慣

 

(1)自由格式的代碼，爲所欲爲想怎麼寫就怎麼寫，最後你就等着哭吧。

(2)不使用抽象的代碼，好比在Java中，通常項目會這麼寫:

entity、dao、service、serviceImpl、controller

entity對應數據實體

dao至關於數據訪問層

service及其實現類至關於業務邏輯層

controller天然就是接口或者是視圖控制層

有的人圖省事，按照本身的想法來，將service和serviceImpl合併爲一個，咱們以前說過單一職責原則。若是是service和serviceImpl合併爲一個，就不符合做者所說的，單一職責和依賴倒置或面向接口。由於不管是單一職責也好，依賴倒置或者面向接口也罷，聽從的核心就是，「高內聚，低耦合」。他這麼作，天然就是「低內聚，高耦合」。

(3)像彰顯個性，好比自認爲將代碼寫的讓別人看不懂，就認爲本身很牛逼。

(4)像死代碼，好比某某功能代碼已經暫時棄用，可是之後可能用,就用個註釋將其註釋掉，等待之後再用，實際狀況是之後都不會再用，放在這影響可讀性。

(5)像冗餘代碼,好比有工具類能夠作字符串和非空判斷，你卻還要寫個if-else if-else等等。

(6)像拒絕變化的代碼，就比如人拒絕成長那樣，總有一天呢會吃虧的。

(7)像自覺得是的代碼，本身很快的寫完初步測試了幾個場景，或者是不測試就盲目的自信認爲本身寫的徹底沒有問題，一點bug都不會有，到最後，通常狀況都會有問題的。這一點我深有感觸。

 

8.以技術人自律而不是工人

 

(1)關於熟悉工具，好比Eclipse，你若是十分熟悉的話，不管是當項目愈來愈龐大時，或者是調試時，你總會比那些熟悉程度相對於比你低的多的人在錯誤排查或者說找某個包下的類，效率上要快的多。

(2)關於IDE，每一個編程語言都有其獨特的IDE，若是沒有IDE，想象着你用記事本或者notepad寫代碼，而後命令行編譯，那是一件多麼痛苦的事情啊，IDE的出現與普遍應用就是爲了提升程序員的開發效率，減小沒必要要的體力勞動。

(3)堅持編碼,這裏要提一點，只要仍是在技術這個圈子裏面混，代碼仍是要寫的，否則哪來的靈感呢。

(4)編碼前思考，這裏以前我也說過，編碼前不思考直接開幹，最後的結果是效率低，無用功。

(5)堅持重構，重構不必定是大規模，它能夠是一步一步，好比你以前的controller通常都是做爲控制層，一般是接收請求，處理數據，返回數據等，像與安卓對接，通常都是JSON數據，你能夠將以前引用的JSONObject抽取出來爲一個類複用，免得每次controller都要導包。

(6)多寫文檔，以前也說過，寫文檔不只僅是爲了理清業務邏輯和解決問題，仍是爲了提升本身的思惟能力。

(7)保持程序版本的簡單性，一個項目不要太多版本，不然每每會將簡單的事情變爲複雜。

(8)作單元測試，關於單元測試的重要性，我在這篇文章說過，文章連接:https://www.cnblogs.com/youcong/p/9291184.html 因此就再也不多說。

(9)作好備份，不怕一萬就怕萬一，總得留個後手。

(10)不要重複造輪子，有現成的工具，就不要本身千辛萬苦的去寫了，直接用現成的，固然了，你若是以爲你能夠改造這個輪子，讓這個輪子變的更好，那麼，我我的以爲不妨試一試，也許能推陳出新。

(11)不要拷貝，你能夠理解爲了有不少處代碼段須要引用某段函數，既然是須要引用相同的某段函數，爲什麼不將其寫成一個代碼塊方便調用呢。

(12）代碼充滿靈性的體現是，至少你看到這段代碼知道是什麼意思，見其便知意。而不是看天書似的。

(13)測試自動化，無論是性能測試、單元測試，仍是功能測試，想盡辦法讓它自動化，不要在測試以前手動配置觸發條件。

(14)作壓力測試，這個就沒必要多說了，如今壓力測試工具備不少，loadrunner或是jmeter,總體來講，都還不錯。

(15)"剽竊「不可恥，學習人家怎麼寫代碼的，好的借鑑，很差的引覺得戒，也是一種提升自我編碼質量的有效方式之一。

(16)堅持向敏捷學習,提升軟件開發流程的效率。

(17)重裏更重面，把握好用戶的第一面。

(18)分享，分享本身的技術，分享本身解決問題的方式，分享本身是怎麼寫代碼的。

(19)刨根問底，凡是對於問題或者事物，都要心中有爲何，特別是開發任務繁重的時候，業務不問清楚，很容易致使作無用功。

(20)橫向擴展，主要是又一點到多面，至關於在某些業務時，你接觸過數據庫、接觸過安卓、接觸過IOS或者是運維等，藉此能夠擴大本身的知識面，這也是發展爲全棧工程師的途徑之一。

 

小結:

上述說的，有些來自這本書，也有些來自我我的的想法。但願能給你們帶來幫助。