後端好書閱讀與推薦(續二)

後端好書閱讀與推薦系列文章:
後端好書閱讀與推薦
後端好書閱讀與推薦(續)
後端好書閱讀與推薦(續二)css

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

Effective Java

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

本書是Java領域的經典之做,做者提出了幾十個經驗法則,可以優雅健壯的解決咱們平常編程可能會遇到的大部分的問題。java

本書亮點遍地是,挑一些表明性的:git

  • 學好一門天然語言有三件事:語法、詞彙、習慣和高效的用法;學好一門編程語言也相似的,咱們要了解語言的核心,掌握常見的數據結構與API,同時爲了效率要掌握一些最佳實踐。程序員

  • 靜態工廠方法通常來講能夠比構造器更好的控制對象的生成,好比生成特定子類類型(根據名稱判別)、生成時機、數量(單例、緩存)等,可是要注意規範命名,以便於使用者沒必要去猜靜態方法的用處(由於靜態工廠方法並不如構造器那麼特別)。github

  • 用對象池來避免建立對象須要對象池裏面的對象是重量級的才行(如建立代價較大),由於維護輕量級對象池的代價甚至大於即時建立的代價。web

  • 本身在管理內存的時候尤爲容易發生內存泄漏,因此要確保不只你知道這個變量不被引用了,還要讓JVM知道;另外,還能夠好好利用軟引用和弱引用來保證內存不足時變量能夠被回收的問題。redis

  • 不要使用 public 域,而應該使用 private 域加 public 和 getter 這樣就保留了未來靈活修改內部數據表示的能力,若是直接用 public 域,那麼未來要修改內部表示,那麼調用者也必須修改其調用方式,這顯然不利於重構維護的。spring

  • 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<String> l = new Vector<>(); 不要用 Vector<String> l = new Vector<>();,由於這樣就能夠在想換實現的時候修改一行代碼就好了 List<String> l = new ArrayList<>(); 代碼中的其餘部分並不會收到影響。爲何要換實現呢?可能新的實現提供了更好的性能,更多的功能等等

  • 多線程中,Thread既能夠充當工做單元,又能夠充當執行機制,可是最好要把這二者分開,用Runable和Callabe做爲工做單元(task),用executor 封裝的thread來做爲執行機制(不要直接使用thread),這樣職責劃分代碼更清晰

讀完這本書,結合前面的設計模式、代碼整潔之道、重構幾本書,我感受能夠總結一點:每個段特定的代碼(類、函數)其實都是分爲做者和調用者,代碼之因此寫的爛,是由於好多時候咱們本身一我的同時充當了做者和調用者,因此忽略了咱們做爲做者應該怎樣寫代碼才更有利於別的調用者調用,達到可複用、低耦合、易重構的效果,因此咱們在寫一段代碼的時候不要想固然的就把某個功能隨意的放在某段代碼實現,而是要好好分割功能實現和調用,分清本身做爲做者和調用者的界限,才能避免當局者迷。

本書也比較老了,08年的,因此不少問題都被Java7/8/9解決了,好比

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

  • interface 的 default 方法打破了接口不容許實現的規則,因此書中提到的抽象類比接口更易於演變的理由彷佛再也不成立

  • Java 8 的方法引用能夠很方便的實現策略模式,而不須要再書中提到的(可是思想依然相同)宿主類、匿名類

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

MongoDB In Action

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)

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 In Action

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技術內幕

深刻分析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命令行大全

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歲,哈哈。

相關文章
相關標籤/搜索