讀讀《編寫高質量程式碼:改善Java程式的151條建議》
這本書可以作為平時寫程式碼的一個參考書，這本書以我個人讀的經驗看來，最好是通過平時程式碼驅動的方式來讀，這樣吸收的快，也讀的快。
這本書主要講什麼，我自己用了個思維導圖概述:
根據這種導圖可知，主要講的就是Java語法、JDK API、程式效能、開源工具和框架、程式設計風格和程式設計思想等五個點。
我這次主要讀的是關於開源世界和思想開源這兩章，這兩章相當於導圖中提到的開源工具和框架、程式設計風格和程式設計思想。所以今天講的也是這兩個方面。
一、開源工具和框架
導圖如下所示:
作者的觀點是:大膽採用開源專案。並對此提出五點建議。不過在我看來的話除了選擇框架和工具需遵循六個原則外，其它四點從導圖上看似乎沒有多大用處。所以我也不打算詳細說，但是這四點我將其理解為這些想法和建議。
想法和建議如下:
使用的相關工具類要統一，比如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)高熱度;
選擇開源專案儘可能選擇那些更新頻繁的。頻繁意味著有人負責維護，出問題了有人負責解決。更新頻繁的總比一年甚至兩年更新甚至已經不更新的專案要好吧。因此我們再採用開源專案的時候應抱有這樣的觀點，大膽採用，仔細篩選。當然了，還有就是最後如果發現選擇了某個開源專案，突然作者因為某種原因不維護了，遇到這種情況時，不要抱怨對方，也不要詆譭人家，畢竟我們享受的是他人辛苦貢獻的成果。
二、程式設計風格與程式設計思想
關於程式設計風格與程式設計思想，該作者提出了八點建議，我覺得挺棒的。所以我將其用思維導圖歸納成如下:
1.提倡良好的程式碼風格
換行排版總得要把，不然看起來亂七八糟也不好，這個目前大多數人都可以做到。但是風格統一的話，就有點難了，俗話說，一百個人眼裡有一百個哈姆萊特。有點難並不程式碼沒有辦法解決，比如現在流行的Java規範手冊《阿里巴巴Java開發手冊》，就可以借鑑參考。便捷(通用性工具，比如sonar這個程式碼質量分析或者是sonar lite這個Eclipse程式碼分析外掛也是有利於塑造良好的程式碼風格。
2.不要完全依賴單元測試來發現問題
單元測試確實不能覆蓋所有的場景，因為我們開發人員在有限的時間內，所能做的測試及其對應的資料場景，也就三種:
(1)正常;
(2)邊界;
(3)異常;
其它的我們也沒有這個時間去考慮那麼多，即便是有專門的測試人員，測試的場景也還是有限。更何況像沒有測試的小公司呢。
3.讓註釋正確、清晰、簡潔
我覺得上面的這個思維導圖已經足夠詳細了，所以關於註釋我不再贅述。
4.介面職責單一
5.增強類的可替換性
6.依賴抽象而不是實現
4、5、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或者是運維等，藉此可以擴大自己的知識面，這也是發展為全棧工程師的途徑之一。
小結:
上述說的，有些來自這本書，也有些來自我個人的想法。希望能給大家帶來幫助。
來源：https://www.cnblogs.com/youcong/p/9873261.html