摘要：后端好書閱讀與推薦系列文章后端好書閱讀與推薦后端好書閱讀與推薦續后端好書閱讀與推薦續二幾個月又過去了，又讀了幾本書，同時為了深切體會到某些書里面的要點還專門做了一個小項目，這里就把讀書與小項目過程中的一些心得體會記錄一下。

后端好書閱讀與推薦系列文章：
后端好書閱讀與推薦
后端好書閱讀與推薦（續）
后端好書閱讀與推薦（續二）

幾個月又過去了，又讀了幾本書，同時為了深切體會到某些書里面的要點還專門做了一個小項目，這里就把讀書與小項目過程中的一些心得體會記錄一下。

Effective java 中文版（第2版） (豆瓣) https://book.douban.com/subje...

本書是Java領域的經典之作，作者提出了幾十個經驗法則，能夠優雅健壯的解決我們日常編程可能會遇到的大部分的問題。

本書亮點遍地是，挑一些代表性的：

學好一門自然語言有三件事：語法、詞匯、習慣和高效的用法；學好一門編程語言也類似的，我們要了解語言的核心，掌握常見的數據結構與API，同時為了效率要掌握一些最佳實踐。

靜態工廠方法一般來說可以比構造器更好的控制對象的生成，比如生成特定子類類型（根據名稱判別）、生成時機、數量（單例、緩存）等，但是要注意規范命名，以便于使用者不必去猜靜態方法的用處（因為靜態工廠方法并不如構造器那么特別）。

用對象池來避免創建對象需要對象池里面的對象是重量級的才行（如創建代價較大），因為維護輕量級對象池的代價甚至大于即時創建的代價。

自己在管理內存的時候尤其容易發生內存泄漏，所以要確保不僅你知道這個變量不被引用了，還要讓JVM知道；另外，還可以好好利用軟引用和弱引用來保證內存不足時變量可以被回收的問題。

不要使用 public 域，而應該使用 private 域加 public 和 getter 這樣就保留了將來靈活修改內部數據表示的能力，如果直接用 public 域，那么將來要修改內部表示，那么調用者也必須修改其調用方式，這顯然不利于重構維護的。

List 優先于 Array 因為泛型是不可變的，而數組是協變的。而且數組是具體化的，只有在運行期才會檢查元素類型約束，但是因為泛型擦除，所以在編譯期就檢查元素類型，這樣就能提前發現錯誤。

參數有效性檢查，對于public方法，應該檢查并throw 異常，對于未被導出的方法，檢查時應該用assert，既能起到檢查效果，又能減少開銷；對于類的可變組件還要選擇性的進行保護性拷貝，避免破壞類本身

override 方法的選擇是在運行時動態決定的，總是選擇最具體的方法；overload 方法選擇是在編譯時靜態進行的，完全基于編譯時類型

對于集合或者數組這些 容器 類，寧愿返回一個長度為0的容器而不要返回null，避免客戶端忘了檢查而拋出空指針異常，如果擔心性能問題可以把這個長度為0的容器聲明為靜態常量（因為它是空的，所以可以自由共享），避免每次新建容器帶來的性能消耗（其實很小）。這個在應用中很常見，比如web中展示列表之類的，如果在Service中返回null，那么Controller中還要檢查，不然前端渲染時foreach列表時就會報空指針異常，但是返回一個長度為0的容器，就可以避免檢查，空與不空統一處理了

精確的計算尤其是貨幣不要使用float或者double，因為要讓一個浮點數精確的表示0.1（或者10的任何負數次方，另外，任何進制都有不能表示的數）是不可能的，而因該使用BigDicimal(數量大，精確控制小數點)、long或者int（性能較好）。題外話，如果讓用戶損失了錢，即使是一分錢，都會讓你的應用失去用戶的信任，所以該精確的地方一定要足夠精確

一般都要通過接口來引用對象而不是類，如 List l = new Vector<>(); 不要用 Vector l = new Vector<>();，因為這樣就可以在想換實現的時候修改一行代碼就行了 List l = new ArrayList<>(); 代碼中的其他部分并不會收到影響。為什么要換實現呢？可能新的實現提供了更好的性能，更多的功能等等

多線程中，Thread既可以充當工作單元，又可以充當執行機制，但是最好要把這兩者分開，用Runable和Callabe作為工作單元（task），用executor 封裝的thread來作為執行機制（不要直接使用thread），這樣職責劃分代碼更清晰

讀完這本書，結合前面的設計模式、代碼整潔之道、重構幾本書，我感覺可以總結一點：每一個段特定的代碼（類、函數）其實都是分為作者和調用者，代碼之所以寫的爛，是因為好多時候我們自己一個人同時充當了作者和調用者，所以忽略了我們作為作者應該怎樣寫代碼才更有利于別的調用者調用，達到可復用、低耦合、易重構的效果，所以我們在寫一段代碼的時候不要想當然的就把某個功能隨意的放在某段代碼實現，而是要好好分割功能實現和調用，分清自己作為作者和調用者的界限，才能避免當局者迷。

本書也比較老了，08年的，所以很多問題都被Java7/8/9解決了，比如

List tempList = new ArrayList<>(); 泛型實例化類型的自動推斷簡化了代碼

interface 的 default 方法打破了接口不允許實現的規則，所以書中提到的抽象類比接口更易于演變的理由似乎不再成立

Java 8 的方法引用可以很方便的實現策略模式，而不需要再書中提到的（但是思想依然相同）宿主類、匿名類

但是這些并不影響我們閱讀，我們只需要看書的時候結合Java的最新特性來看就行了，況且本書主要講方法、經驗，而不是語法，所以新與舊影響并不是特別大，不過實在受不了的話也有好消息，第三版好像2017.12就要出來了，引入了Java7/8/9的最新特性。這本書屬于那種沒事可以翻一翻的書，因為做得越多，對書中的經驗體會就越深，就越能夠應用自如。

MongoDB實戰 (豆瓣) https://book.douban.com/subje...

MongoDB 我是作為幾乎的初學者來看這本書的，因為之前看了點基礎知識就直接用在了項目里，邊用邊學，雖然快速，但是難免心里有郁結，因為沒成體系。這里準備用這本書來系統的學習一下。
這本書內容相當豐富，從歷史講起，介紹了mongodb的基本概念，設計實例最后還講了一些高級用法如復制與分片，性能調優等，既有開發者視角，也有DBA視角，讀完收獲頗豐。

亮點：

MongoDB相對于關系數據庫的優點有：可存儲無Schema數據，讀寫吞吐量高（鍵值存儲簡單），擴展方便（自動分片，主從復制，主節點若發生故障從節點自動轉為主節點），數據模型直觀（一般不需要join連表查詢）；相對于其它NoSQL如redis的優點有支持即時查詢（redis只支持主鍵查詢）。這也是為啥MongoDB能在關系數據庫已經如此成熟的今天還能打下自己一片天地的原因

MongoDB應用場景：WEB應用如日志和實時分析（原子更新和固定集合，提供穩定的計數器和日志自動過期的功能），敏捷開發（因為無模式），緩存（完整的對象表示和簡單的鍵值存儲通常能獲得比MySQL更高的查詢速度）

shell可以很容易的查看任意方法的實現，只要輸入不帶括號的方法就行（這是js的特性）比如db.user.save就可以看出save其實就是對insert和update一個簡單的封裝，根據主鍵是否存在進行操作選擇。

所有的MongoDB驅動都主要有三個功能：檢查對象ID若無則生成（id可保證唯一，由4字節時間戳，3字節機器ID，2字節進程ID，3字節進程局部計數器組成，所以MongoDB一般不需要一個多帶帶的字段來記錄存儲時間了），把語言特定的文檔描述轉換為BSON，使用MongoDB的網絡協議通過TCP套接字與數據庫通訊（安全模式決定了通訊是否可靠）

選擇嵌套還是引用（正規化與否）的關鍵是判斷讀寫比，選擇嵌套優點是查詢只需要一次就可以查完，簡單快速，但是如果要修改就需要在每個出現嵌套信息的地方進行修改，但是如果確定修改的頻率較低，或者嵌套對象不出現在父對象以外的其他上下文，那么嵌套就足以成為合理的設計。此外，如果信息量很大那么不適合用嵌套，應該用引用，可以避免或者推遲分片的到來。比如博客應用中文章的評論就非常適合嵌套

更新有兩種方式，一種是通用性更新：從數據庫獲得完整對象，然后修改這個對象，然后保存，另一種是針對性更新:直接按條件修改數據庫中一些對象的某些字段。前者的好處在于通用，可以將前臺傳來的表單無論修改了那個字段都可以直接保存，無需更多拼湊，修改任何字段的方法都是相同的，便于統一處理，后者的好處在于性能更好，因為節省了許多不必要字段的傳遞，而且允許原子性更新，比如inc

稀疏索引用于：不是所有文檔都要用unique索引，這樣可以避免某一類型數據（比如缺了一個字段）無法多次插入；集合中大量文檔都不包含被索引的鍵，用稀疏索引可以節約內存

復制可以提供：冗余能夠達到容災或者挽救誤刪數據的效果；故障遷移可以在緊急情況下切換節點；簡化維護工作，比如可以在主節點以外進行大開銷操作如備份或者大數據的索引構建；均衡負載，讀寫分離

分片可以解決某一類型數據過大，不能單機存儲的問題，同時能保持高性能讀寫。MongoDB自動分片策略應該可以替換大多我們自己手動分片的做法

書中還提出了許多最佳實踐，比如常見的設計范式一對多、多對多、樹形結構，這些都對我們在設計應用時有較大的參考價值

看這本書有點不爽的一點就是用ruby寫的，這一門語言我沒怎么接觸過，但是卻因為老板讓我部署redmine而留下了痛苦回憶，真的是我用過的框架里面部署最麻煩的，所以一直也沒有興趣去了解這門語言，但是還好大部分語言的語法都是相似的，并不是很影響我看這本書。
另外還有一點就是 MongoDB 版本3和2差別較大，最明顯的就是驗證方式，需要及時更新。

Pro Git (Second Edition) (豆瓣) https://book.douban.com/subje...

Git也用過挺久了，但是每次遇上問題都是直接搜索，這樣解決問題是快，但是同樣不成體系，所以用這本書站在使用者的角度進行學習，時間有限，后面還有關于原理的部分我就省略沒看了。

亮點：

版本控制系統（VCS）可以將某個文件回溯到之前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，你可以比較文件的變化細節，查出最后是誰修改了哪個地方，從而找出導致怪異問題出現的原因，又是誰在何時報告了某個功能缺陷等等

集中化的版本控制利于項目共享，權限管理，但是受中央服務器的單點故障影響特別明顯，而分布式版本控制系統每一個用戶都有一個完整的倉庫，對單點故障免疫，還可以根據需要設定不同的協作流程，比如層次模型式的工作流

Git支持離線操作，保證文件完整性，一般只添加數據所以不容易誤刪（但是也使得徹底清除文件比較費勁，比如誤上傳了密碼文件）

Git 有三種狀態，你的文件可能處于其中之一：已提交（committed）、已修改（modified）和已暫存（staged）。已提交表示數據已經安全的保存在本地數據庫中。已修改表示修改了文件，但還沒保存到數據庫中。已暫存表示對一個已修改文件的當前版本做了標記，使之包含在下次提交的快照中

git add 是個多功能命令：可以用它開始跟蹤新文件，或者把已跟蹤的文件放到暫存區，還能用于合并時把有沖突的文件標記為已解決狀態等。將這個命令理解為“添加內容到下一次提交中”而不是“將一個文件添加到項目中”要更加合適

對一個線上項目要添加新功能時應該新建一個新功能分支，如果線上項目出了問題，應切回線上分支，然后創建一個緊急分支來修復，測試結束過后切回線上分支，合并這個緊急分支，然后推送到線上分支，最后切回新功能分支，做完后測試，在切回線上分支，合并新功能分支，推送到線上分支。這是項目開發的最佳工作流實踐

與他人合作的最佳方法即是建立一個你與合作者們都有權利訪問，且可從那里推送和拉取資料的共用倉庫，倉庫最好放到服務器上方；Git服務器可以自己搭建，還可以自己搭一個對應的網頁查看器如GitWeb，也可以使用開源的功能全面的Git服務器比如GitLab，最簡單的做法是使用第三方托管如Github

集中式工作流類似于subversion：一個中心倉庫，可以接受代碼，所有人將自己的工作與之同步，模式簡單，應用廣泛；集成管理者工作流：每個開發者擁有自己倉庫的寫權限和其他所有人倉庫的讀權限。這種情形下通常會有個代表`‘官方’"項目的權威的倉庫。要為這個項目做貢獻，你需要從該項目克隆出一個自己的公開倉庫，然后將自己的修改推送上去。接著你可以請求官方倉庫的維護者拉取更新合并到主項目，維護者可以將你的倉庫作為遠程倉庫添加進來。主要優點是一方都可以按照自己節奏工作，適時的合并；司令官與副官工作流：是多倉庫工作流程的變種。一般擁有數百位協作開發者的超大型項目才會用到這樣的工作方式，例如著名的 Linux 內核項目。被稱為副官的各個集成管理者分別負責集成項目中的特定部分。所有這些副官頭上還有一位稱為司令官的總集成管理者負責統籌。司令官維護的倉庫作為參考倉庫，為所有協作者提供他們需要拉取的項目代碼，只有當項目極為龐雜，或者需要多級別管理時，才會體現出優勢

這本書作為工具沒啥好挑剔的，它講的全面、細致，看完再練練，把git常見功能弄熟悉就好，繁雜瑣碎的功能可以先不看，遇上問題了再來查閱。
ps:github上有對應的中文版。

Spring實戰（第4版） (豆瓣) https://book.douban.com/subje...

這本書可謂是涵蓋了Spring整個體系的概要書，從spring mvc 到 spring security 再到 spring boot，幾乎涵蓋了我們平常開發能用到的所有組件，讀完就可以從整體上把握spring，但是其中的每一個主題都可以多帶帶成書，值得好好研究，這本書就相當于是開個好頭吧。

亮點：

Spring框架是以簡化Java EE應用程序的開發為目標而創建的，主要使用pojo替換重量級的ejb，目前已經成為Java web事實上的標準

Spring可以做很多事情，為企業級開發提供給了豐富的功能，這些功能的底層都依賴于它的兩個核心特性，依賴注入（dependency injection，DI）和面向切面編程（aspect-oriented programming，AOP）

為了達到Spring最根本的使命：簡化Java開發，Spring采取了以下4種關鍵策略：基于POJO的輕量級和最小侵入性編程；通過依賴注入和面向接口實現松耦合；基于切面和慣例進行聲明式編程；通過切面和模板減少樣板式代碼。

通過DI，對象的依賴關系將由系統中負責協調各對象的第三方組件在創建對象的時候進行設定。對象無需自行創建或管理它們的依賴關系，依賴關系將被自動注入到需要它們的對象當中去；借助AOP，可以使用各種功能層（日志，審計，安全等）去包裹核心業務層。這些層以聲明的方式靈活地應用到系統中，你的核心應用甚至根本不知道它們的存在

Spring的配置風格是可以互相搭配的，所以你可以選擇使用XML裝配一些bean，使用Spring基于Java的配置（JavaConfig）來裝配另一些bean，而將剩余的bean讓Spring去自動發現。建議是盡可能地使用自動配置的機制， 顯式配置越少越好。當你必須要顯式配置bean的時候（比如，有些源碼不是由你來維護的，而當你需要為這些代碼配置bean的時候），推薦使用類型安全并且比XML更加強大、類型安全并且對重構友好的JavaConfig。最后，只有當你想要使用便利的XML命名空間，并且在JavaConfig中沒有同樣的實現時，才應該使用XML

大多數的JSP模板都是采用HTML的形式，但是又摻雜上了各種JSP標簽庫的標簽，使其變得很混亂。這些標簽庫能夠以很便利的方式為JSP帶來動態渲染的強大功能，但是它也摧毀了我們想維持一個格式良好的文檔的可能性；Thymeleaf模板是原生的，不依賴于標簽庫，它通過自定義的命名空間，為標準的HTML標簽集合添加Thymeleaf屬性。它能在接受原始HTML的地方進行編輯和渲染。因為它沒有與Servlet規范耦合，因此Thymeleaf模板能夠進入JSP所無法涉足的領域

ControllerAdvice最為實用的一個場景就是將所有的@ExceptionHandler方法收集到一個類中，這樣所有控制器的異常就能在一個地方進行一致的處理。 例如， 我們想將DuplicateSpittleException的處理方法用到整個應用程序的所有控制器上

Spring Security從兩個角度來解決安全性問題。它使用Servlet規范中的Filter保護Web請求并限制URL級別的訪問。Spring Security還能夠使用Spring AOP保護方法調用——借助于對象代理和使用通知，能夠確保只有具備適當權限的用戶才能訪問安全保護的方法

對于Spring data，簡單的查詢直接在自定義的repository接口中繼承JpaRepository，然后用findByUsername這種命名風格的方法就行，如果所需的數據無法通過方法名稱進行恰當地描述，那么可以使用@Query注解，為Spring Data提供要執行的查詢，更復雜一點的可以繼承自定義的類（并非真的繼承，而是命名加上Impl后綴，Spring Data自己會合并所有的方法），然后自定義查詢方法

Java消息服務（Java Message Service ，JMS）是一個Java標準，定義了使用消息代理的通用API。在JMS出現之前，每個消息代理都有私有的API，這就使得不同代理之間的消息代碼很難通用。但是借助JMS，所有遵從規范的實現都使用通用的接口，這就類似于JDBC為數據庫操作提供了通用的接口一樣。Spring對JMS的支持，包括JmsTemplate（同步）和消息驅動POJO（異步）

Spring帶來的主要益處就是簡化Java開發，Spring Boot讓這項任務變得更加簡單。從Spring創建以來，Spring Boot大概是Spring領域中最令人興奮的事情了。它在Spring之上，構建了全新的開發模型，移除了開發Spring應用中很多單調乏味的內容

這是一本“XX大全”類的書籍，下一本書也是，這種書最適合剛進入一個領域的時候看，因為能提供很多參考，利于我們進階的學習。

深入分析Java Web技術內幕 (豆瓣) https://book.douban.com/subje...

本書作者的理想很豐滿，想一次性得把Java web 全部搞定，從基本的http，dns協議，到底層的編譯原理、jvm與類加載技術，到中層的servlet，到上層的框架spring，幾乎能用到的知識點都講到了，但是由于這個面實在太廣，很難真正的深入講解，但是本書對于了解整個Java web的體系還是非常有好處的，這也是作者多年工作的積累和經驗，非常值得了解和學習。

亮點：

從用戶輸入含域名的URL到瀏覽器呈現結果會發生如下幾件事：域名解析成IP，首先瀏覽器檢查緩存，若無則檢查操作系統dns緩存，若無則檢查本地dns服務器LDNS，若無則檢查根域名服務器，最終得到IP,找到對應服務器；服務器根據請求相應結果，可能有多臺（群）服務器進行負載均衡，最終給用戶指定一個特定的服務器，服務器會檢查緩存，有的請求是緩存在分布式緩存里，有的是靜態文件緩存，有的還需要去數據庫取數據；瀏覽器得到結果后可能還會發現有靜態文件比如css,js,image等，如果瀏覽器沒有緩存則又會發起另外的http請求這些資源，可能在cdn上，可能直接在服務器上，最終得到結果渲染頁面并緩存起來，為下一次渲染加速

文件訪問一般涉及到數據從磁盤到內核空間，內核空間到用戶空間（內核空間可能會使用緩存機制）；直接IO是指應用程序跳過內核直接訪問磁盤，比如數據庫，通常可以結合應用層緩存和異步IO方式提高效率；內存映射是指操作系統將內存中的一段區域與磁盤中的文件關聯起來，可以減少從內核緩存到用戶空間緩存的數據復制操作，因為這兩個空間的數據是共享的

網絡IO優化方式：減少網絡交互次數，比如客戶端和服務端都設置緩存，將多個js或css合并一次發送，多個sql語句合并起來一次發送給數據庫；減少網絡數據傳輸量，比如數據壓縮，協議簡單化；減少編碼，盡量以字節形式發送，減少從字符到字節的過程

大型網站一般不采用多帶帶的cookie或者session，而是采用分布式session框架，客戶端只需簡單的發送sessionid即可，服務端的session是分布式存儲的，與真正的應用服務器分開，避免均衡負載session不一致情況的發生；同時，每個請求攜帶一個唯一的crsf_token存入session，既能防止跨站攻擊，也能防止表單重復提交

這本書還有個優點就是遍布全書的設計模式講解與實例分析，不得不說作者知識面很豐富，估計如果能把這本書提到的點都精通了就是真正的“架構師”了吧。

Linux命令行大全 (豆瓣) https://book.douban.com/subje...

做后端的肯定要和Linux打交道，比如程序日志好幾百兆，怎么快速找到需要的分析內容？訪問突然變得緩慢，怎么檢查是帶寬問題還是內存問題還是CPU問題？這些常用操作及其對應命令都可以在這本書里面找到答案，對于Linux系統的日常使用和管理，提升工作效率起到很大的幫助作用。

亮點：

Windows中每個存儲設備都有一個獨立的文件系統樹（C盤，D盤），而Linux中只有一個文件系統樹，不同的設備只能選擇性的掛載到這個樹中的某個位置

雖然使用圖形界面可以很輕松的實現簡單文件操作，但是對于復雜操作命令行的優勢就太明顯了，比如根據文件夾中特定類型的文件是否存在及其更新日期來決定是否把文件復制到該文件夾中，這個用圖形界面你就只能一個一個的手工選擇然后對比，但是命令行就一句 cp -u *.file destination 輕松搞定“insert or update when newer”的功能

當rm與通配符搭配使用時，通常結果影響較大，應該先用ls對通配符進行測試，檢查是否真是需要刪除的文件，確認后再按↑ 并用rm替換ls

硬鏈接是最初的鏈接方式，局限性在于不能引用自身文件系統以外的文件，而且無法引用目錄，它與文件本身沒區別，刪除它也不會刪除文件，除非該文件的所有鏈接都刪除完了；現在提倡使用軟鏈接（符號鏈接），它克服了硬鏈接兩大不足，與指向的文件幾乎沒區別，可以進行修改，但是刪除軟鏈接對指向文件沒影響

kill命令并不是殺死進程，而是給進程發送信號，不過通常都是殺死進程的信號，但是也有繼續運行、窗口改變等“非殺死”的信號

通過rsync命令同步本地與遠程系統上的目錄，該命令能檢測兩個目錄之間的不同，以最少量的復制動作完成兩個目錄之間的同步，與其他復制命令相比，顯得既快又經濟

這本書沒啥問題，就是相當的基礎，微觀，偏重于細節和使用，可以放桌上隨時查閱，想要稍微深一點或者更宏觀審查Linux的可以看這

軟件測試經驗與教訓 (豆瓣) https://book.douban.com/subje...

即使不是專業的軟件測試人員，開發者也應該學習一些軟件測試，畢竟寫完代碼你自己總得保證基本能運行吧，最開始可能可以手動運行，但是心里能有底嗎？還是得寫好單元測試，才能更有底氣的把代碼交給別人運行，所以看看這本書來了解一下軟件測試中的一些好的經驗。

亮點：

軟件測試的“語境驅動法”，在某些環境中很有效的方法在另一些環境就沒有效果，所以不談論最佳實踐，而是談論最適合當前特定環境的實踐

測試的任務是找到最重要的問題，所以要首先測試剛剛經過變更的部分，核心功能，功能完整性，常見使用情況，常見威脅，影響較大的問題，最需要的部分

為了測試就必須探索，亦即有目的地漫游，需要三種思索方式，前向思索：根據已知探索未知；后向思索：從懷疑或者想象的東西返回到已知；側向思索：讓自己的工作由于新想法而轉移，然后再將探索主題回到主線上

由于測試用例是無限的，在時間和預算的約束條件下應該選取少量最有效的測試，一些好的試探法測試包括：邊界測試；測試所有錯誤消息；測試與程序員不同的配置；運行比較難設置的測試；避免冗余測試；

任何產品都會殘留一些小缺陷，但是隨著小缺陷數量的增加，客戶信心會下降，更糟糕的是這些小缺陷的腐蝕作用，長久積累下來最終會導致產品失敗，所以小缺陷也值得報告和修改

自動化測試有很多優點比如加快測試速度，性能測試（1000個客戶鏈接不可能找1000個人去測）等等，但是手工測試也有自己的優點比如臨時變更測試，虛警過濾等等，所以這兩者不能互相替換，而是相互補充

腳本語言是用來加快人的工作完成速度而非提升機器性能的，所以對于許多自動化測試來說，腳本語言都是最合適的，測試員可以用腳本語言快速生成測試用例、訪問編程接口以及檢驗結果

這本書類似于程序員修煉之道，都是作者的經驗之談，我本人由于測試經驗相對較少，所以還需要在以后的工作中慢慢體會，并且時常翻看才可能做到融會貫通。
ps,要想學習軟件測試的基本理論知識還得看這本書：軟件測試的藝術。

軟技能 (豆瓣) https://book.douban.com/subje...

軟件開發者首先是作為一個人，其次才是軟件開發，這本書不教我們怎么寫代碼，而是教我們關注生活中的其他方方面面，針對職場人士，尤其是軟件開發者，提出了一系列可以讓人更接近成功，過得快樂的tips，包括很多方面比如學習，自我營銷，理財，人際關系還有健康。

亮點：

當說到“優秀的軟件開發人員”時，并不是說要精于編碼之道，善于解決缺陷，通曉單元測試。相反，所說的“優秀的軟件開發人員”，是那些能夠把控自己的職業生涯、達成目標、享受生活的人。的確，職業和生活能融洽的人才能稱得上“成功人士”，光有任何一樣都不完美

你所能犯的最大錯誤就是相信自己是在為別人工作。這樣一來你對工作的安全感已然盡失。職業發展的驅動力一定是來自個體本身。記住：工作是屬于公司的，而職業生涯卻是屬于你自己的。當你為了謀生一頭扎進寫代碼的世界時，其實你和中世紀小鎮上開鐵匠鋪的鐵匠沒什么差別，轉變你的心態，從被一紙“賣身契”束縛住的仆人轉變為一名擁有自己生意的商人。在起步階段就具備這種心態會改變你對職業生涯的思維方式，將此銘記在心，并積極主動地管理自己的職業生涯

盡管我們為自己的智慧感到驕傲，但我們依然是情感動物。我們就像那些穿著西裝、打著領帶、四處游蕩的小孩，假裝自己已經長大，其實任何輕微的傷害都能讓我們號啕大哭，或者大發雷霆，我們只是已經學會了如何控制和隱藏這些情緒。所以啊，不要覺得有理走遍天下，有時候得理也要饒人

你可能會害怕專攻軟件開發的某一領域，擔心自己陷入很窄的專業領域，從而與其他的工作和機會絕緣。雖然專業化確實會把你關在一些機會的大門之外，但與此同時它將打開的機會大門要比你用其他方式打開的多得多。從表面上看，身為“專才”后，潛在雇主和客戶群都變小了，但是實際上你對他們更具吸引力了。只要你專業能力雄厚，市場沒有過渡飽和，與那些自稱為“軟件開發人員”的人相比，你能更輕松地找到工作或者贏得客戶。不完全同意作者的觀點，T字型人才是我自己的奮斗目標

你當然可以改善你的弱點，但最好了解自身的強項是什么并且充分發揮自己的優勢。專業人士對自己的能力和弱點有著良好、精準而又客觀的自我評估。與作者共鳴，我覺得木桶理論不是很靠譜，因為許多人成功并不是依靠自己是全才，而是把自己的長處發揮的淋漓盡致

“假裝自己能成功”就是這樣起作用的。你說服自己的身體和內心去努力，使夢想成為現實。“假裝自己能成功”是不自信的對立面。你要在做任何事情的時候都充滿自信，即使是在自己的能力遠遠不到的時候，因為你有一種自己能夠克服一切障礙的信念

對技術虔誠的一大問題是，我們中的大多數崇拜某項特定的技術，只是因為自己熟悉這種技術。我們很自然地會相信自己選擇的是最好的，然而這會讓我們經常忽略任何反對意見。我們不可能充分了解現存的所有技術，從而給“哪項技術最好”作出最英明、最睿智的判斷，于是我們傾向于選擇我們了解的技術并先入為主地認為它是最好的。所以我的策略是多了解，選合適的工具來解決問題

如果你想成功，你必須要學會收起自己脆弱的自尊心，勇敢走出去，別害怕讓自己出丑，別在意自己站在大庭廣眾之下可能會啞口無言，別在意別人看了你的博客后覺得你完全錯了并且很蠢，別在意別人會嘲笑你，別太在意別人怎么看自己，拼盡全力去克服這些困難，克服掉那些不適感，讓自己變得更加優秀

如果想提前掌握所有知識，那只是在浪費時間，因為真正重要的內容會湮沒在那些細枝末節中。要關注重點，確實需要了解更多細節時，可以利用參考資料來彌補這些不足。有多少次你從頭到尾仔細閱讀一本技術書籍，卻發現自己實際用到的也只是書里介紹的技術的一小部分。感覺找到知音了，如果你看過我前面幾篇文章，你也應該知道我就是這么做的，有好多書其實我并沒有讀完，諸葛亮的觀其大略啊，哈哈 :-D

將自己學到的知識教給別人。要想確定你確實掌握了某些知識，這是唯一的辦法； 同時，在你將自己所學介紹給他人時，這也是查缺補漏的好辦法。在這一過程中，你要切實剖析并理解自己所學的知識，將其內化到自己的思想；同時，你也要用能夠讓他人理解的方式精心組織這些信息。 以我個人的經驗來說，在我開始“樂為人師”之后，我不僅在職業發展和專業成長上有了巨大飛躍，我的理解能力也更上一層樓。總體來說就是，要想給別人講清楚，首先自己得搞明白，所以不僅是“樂為人師”，寫博客也有這個好處。

要進入專注模式，必須要克服將自己的思緒集中于單一任務時的那種痛感。除非你完全享受完成這項任務，否則這種痛感一開始會很強烈。但是， 這正是關鍵所在。你必須要意識到，這種痛苦和不適只是暫時的，不會持續很久。強迫自己進入專注模式，達到專注的臨界點。在我看來，自然世界中不管是物理還是人的心理、思維，都存在慣性，所以我們要專注，就得首先強迫自己進入專注，過不久，就自然專注了，這個和習慣養成是一個道理，比如早起，最開始可能是一種痛苦，但但到了后來也就是一件很自然的事

最好不要多任務并行，因為這會打破專注，降低效率，但是現實不允許你單任務，你可以這樣：批處理瑣碎任務，比如不要來一封郵件就處理，這樣常常打斷你的工作，專注不夠，但是等一段時間一次性處理郵件，就好得多；將不費腦的任務和費腦的任務并行，比如跑步的時候可以聽一些書進行學習

這本書的亮點太多了，難以列全，我讀完過后有種找到知音的感覺，而且通過書中的介紹我找到了我一直想有但卻沒找到的應用kanbanflow，是一款用于任務管理與計時的非常棒的應用。所以我在這里強烈推薦大家看一下，然后結合自己的實際情況，把這些點運用起來，助力自己成為一個更好的“人”。

不知不覺，已經讀了20多本書了，我發現這個習慣非常利于我看書和消化，我準備把這個系列繼續下去，將來就不只是后端書籍了，方方面面的書我都可能看，也會寫，寫到80歲，哈哈。