最近又重新看了一遍《這就是軟件工程師》，上一次看的時候是去年十二月份，差不多相隔一年了。一刷的時候還是有很多地方看不明白，這次二刷能看明白很多了，主要還是因為這一年經(jīng)歷了很多新事情，經(jīng)歷多了自然就懂了。

下面是我提煉出來的一些新讀懂的內(nèi)容。

關(guān)于做測試

大部分情況下，我們寫的代碼不要用人工進行測試，而是要讓機器進行測試。這時因為測試是一件重復(fù)的事情，重復(fù)的事情就應(yīng)該給機器做。

測試比寫代碼難，因為做測試考驗的是一個人全面思考的能力。

測試分為：單元測試、功能測試、集成測試、非功能測試（性能優(yōu)化等）、回歸測試（把以前做過的測試以及犯過的錯誤再測一遍。確保代碼或配置的修改、需求的增加不會影響現(xiàn)有的功能）

1. 做測試最好的方式不是用人工，而是寫代碼。

2. 想要做好測試，先訓(xùn)練自己全面思考的能力。

3. 測試要自己做，尤其不能讓用戶成為你的測試工程師。

如何改bug

改bug是程序員的家常便飯，但是當(dāng)你實在改不出bug時，可以試試下面2個方法。

1. 二分法：可以對代碼、數(shù)據(jù)庫、數(shù)據(jù)值、輸入場景進行二分，不斷縮小范圍

2. 小黃鴨調(diào)試法：如果你已經(jīng)知道了某段代碼大概率有問題，就可以拿一個小黃鴨放在桌上，把這段代碼對著它一行一行地解釋，甚至為什么這個地方用數(shù)組都要講得很清楚。

和朋友、高手一起工作

我們在工作時，身邊總是坐著我們的朋友，我們可以和朋友互相學(xué)習(xí)進步。

1. 讓高手review自己的代碼

2. 和高手一起解決難題。為什么說是“難題”？ 因為只有難題，高手才會拿出真本事去解決，這時你就可以趁機學(xué)習(xí)到很多。

3. 高手的代碼通用性高，且清晰、明確、有自己的風(fēng)格

4. 和身邊的人互相review代碼，彼此信任，有問題直說

5. 沒思路的時候和對方把整個流程需求說一遍，說不定對方有思路或者自己說完就有思路了

如何面對需求

在設(shè)計產(chǎn)品前需要進行需求分析，但注意一定要把需求分析的非常清楚、干凈，你才能寫出代碼來。一下是2個注意點：

1. 明確問題的邊界問題。例如發(fā)布一篇文章時，需要限制文章的字?jǐn)?shù)，那么這個限制是指最多能有多少字？或者最少不少于多少字？這些都是要關(guān)注的點。

2. 關(guān)注不可預(yù)期案例。例如用戶正在進行一場對局，按正常來說我們只需要關(guān)注局內(nèi)的東西即可，但這時如果用戶突然斷網(wǎng)了怎么辦？這就是不可預(yù)期，但又必須面對的東西。

團隊合作

平衡業(yè)務(wù)和技術(shù)：

業(yè)務(wù)方不要把技術(shù)方僅僅當(dāng)作需求解決方，而是要真正把技術(shù)當(dāng)作解決問題的參與方，技術(shù)的主觀能動性就能被調(diào)動起來。

業(yè)務(wù)方不要直接將需求丟給技術(shù)，而是要告訴技術(shù)真正想解決的核心問題是什么，這樣技術(shù)就會一起來想辦法，還可能會想到更好的方法。

平衡中后臺團隊：

離業(yè)務(wù)近的團隊叫作前臺團隊

離業(yè)務(wù)遠的團隊叫作中后臺團隊。

問題用一句話概括就是，離業(yè)務(wù)近的同學(xué)覺得離業(yè)務(wù)遠的同學(xué)做的東西都沒用，離業(yè)務(wù)遠的同學(xué)覺得離業(yè)務(wù)近的同學(xué)做的東西太短視。

這其實是一個長期目標(biāo)和短期目標(biāo)平衡的問題。需要大家互相理解，理解對方的訴求是什么、真正的痛點在哪里。

學(xué)會下指令：

管理者帶團隊時，不能簡單地把任務(wù)分配給下屬，直接告訴下屬做什么，因為這樣并不能說服他。

我們應(yīng)該告訴他 第一，為什么要做這件事，不做另一件事;? 第二，做這件事有什么好的方法。