https://book.douban.com/subject/26919457/

本書是作者Rober C. Martin，也就是“Bob大叔”40多年編程生涯的心得體會(huì)的總結(jié)。要成為專業(yè)的工程師需要具備怎樣的態(tài)度，需要遵循怎樣的原則，需要采取怎樣的行動(dòng)。以及作者走過的一些彎路的錯(cuò)誤示例。

專業(yè)合理的排期

專業(yè)合理的排期是規(guī)避項(xiàng)目延期和保證項(xiàng)目質(zhì)量的前提。 書中將其總結(jié)成兩個(gè)方面：

學(xué)會(huì)拒絕

不要懼怕對(duì)抗，要堅(jiān)持合理的排期結(jié)果，妥協(xié)會(huì)給自己的團(tuán)隊(duì)帶來極大的損失甚至是項(xiàng)目的延期并且要提前向上拋出風(fēng)險(xiǎn)。為什么堅(jiān)持這樣的排期，其中的原因往往不那么重要，提供太多的細(xì)節(jié)往往會(huì)招到更多的微觀管理。

學(xué)會(huì)承諾

職場沒有嘗試，不要說“試試看，我盡量”，而是需要給出一個(gè)明確的時(shí)間點(diǎn)。并且遵守原則。盡可能做到“有求必應(yīng)”，當(dāng)給出肯定的承諾回答時(shí)，會(huì)使用正式的承諾，以確保各方能明白無誤地理解承諾的內(nèi)容。

高效率編碼

需要尋找一個(gè)好的狀態(tài)，避免疲勞或者心煩意亂的狀態(tài)。

書中提到一個(gè)“流態(tài)區(qū)”的概念?！傲鲬B(tài)區(qū)”的意思是，進(jìn)入一種意識(shí)高度專注但思維視野卻會(huì)收攏到狹窄的狀態(tài)，這種情況下人會(huì)感到效率極高。

Bob大叔的忠告是，避免進(jìn)入流態(tài)區(qū)，這只是一種“淺層冥想”狀態(tài)，這種狀態(tài)下，為了追求所謂的速度，理性思考的能力會(huì)下降。----既所謂的，眼光會(huì)暫時(shí)變得“狹隘和短淺”。

有時(shí)候也可以通過一些創(chuàng)造性的輸入給我們激發(fā)靈感和創(chuàng)造力（這種創(chuàng)造性輸入是針對(duì)大腦而言的）。比如一些別的行業(yè)領(lǐng)域的知識(shí)。

TDD

三項(xiàng)法則：

1.在編好單元測試之前，不要編寫任何產(chǎn)品代碼

2.只要一個(gè)單元測試失敗餓了，就不要在編寫測試代碼，無法通過編譯也是一種情況

3.產(chǎn)品代碼恰好能夠讓當(dāng)前失敗的單元測試成功通過即可，無需多寫

-這是個(gè)非常酷炫的理想化工作模式，對(duì)與bug的態(tài)度從原來的防守狀態(tài)變?yōu)橹鲃?dòng)進(jìn)攻（因?yàn)槟阈枰染帉憜卧獪y試代碼再開始編寫產(chǎn)品代碼）。

-同時(shí)也能極大的縮小運(yùn)行一次代碼的周期，快速發(fā)現(xiàn)問題提高效率。

-這可以極大減輕回歸測試的壓力，也就是減少了重構(gòu)的風(fēng)險(xiǎn)和成本，要時(shí)常優(yōu)化代碼（不變的代碼是很危險(xiǎn)的）。

-這會(huì)迫使你去隔離出待測試的代碼，簡單的函數(shù)相互直接調(diào)用不方便測試，這時(shí)候就需要對(duì)倆函數(shù)進(jìn)行解耦，這可能會(huì)引導(dǎo)你從“面向接口編程”的角度去思考你的代碼。

局限：得保證寫出優(yōu)秀的測試代碼。

UI界面開發(fā)因?yàn)镚UI變動(dòng)頻繁，容易導(dǎo)致測試代碼失效，成本很高。

練習(xí)

再練習(xí)編碼防手生的情況下就提倡進(jìn)入“流態(tài)區(qū)”，可以選擇一些小算法來頻繁練習(xí)，譬如刷題。

測試策略

業(yè)務(wù)方對(duì)功能的設(shè)想，往往經(jīng)不起在電腦前真槍實(shí)彈的考驗(yàn)，所以要避免過早的精細(xì)化。所以為什么叫做“評(píng)估”。當(dāng)精細(xì)化被推遲，伴隨而來的是遲來的模糊性。這種模糊性，就是開發(fā)和業(yè)務(wù)方對(duì)驗(yàn)收標(biāo)準(zhǔn)的分歧。書中的解決辦法是-驗(yàn)收測試。

驗(yàn)收測試就是業(yè)務(wù)方與開發(fā)合作編寫的測試（自動(dòng)化），目的是確定需求已經(jīng)完成。

驗(yàn)收測試和單元測試不一樣。

單元測試是工程師寫給工程師的，是正式的設(shè)計(jì)文檔。關(guān)心單元測試結(jié)果的是工程師。

驗(yàn)收測試是業(yè)務(wù)方寫給業(yè)務(wù)方的 ，是正式的需求文檔，關(guān)心驗(yàn)收測試結(jié)果的是業(yè)務(wù)方和工程師。

兩者雖然測試的是同一個(gè)對(duì)象，但是機(jī)制和路徑不同，單元測試是深入系統(tǒng)內(nèi)部，調(diào)用特定類的方法。驗(yàn)收測試則是在系統(tǒng)外部，通常是在API或者UI級(jí)別進(jìn)行。執(zhí)行的路徑截然不同。

還有個(gè)根本原因，測試只是他們的附屬職能。首先是文檔，然后才是測試。主要目的是描述系統(tǒng)的設(shè)計(jì)，結(jié)構(gòu)，行為。真正的價(jià)值在具體指標(biāo)上。

必要的時(shí)候需接入CI

QA的職責(zé)總結(jié)下來有兩個(gè)：

1.需求規(guī)約定義者（和業(yè)務(wù)人員一起創(chuàng)建自動(dòng)化驗(yàn)收測試）

2.特性描述者（遵循探索式測試原則把過程細(xì)節(jié)反饋給開發(fā)）

*****人工探索式測試***

***************系統(tǒng)測試*************

********************集成測試*****************

************************組件測試**********************

****************************單元測試****************************

時(shí)間管理

避免低效會(huì)議（不參與，或則中途禮貌離席）

書中提到一個(gè)很有趣的時(shí)間片管理法----

番茄工作法

這個(gè)命名起源于廚房里長得像番茄一樣的計(jì)時(shí)器。把時(shí)間切成30分鐘的小片，每次工作25分鐘（25分鐘專注不可被打擾）然后休息放松5分鐘，每完成4個(gè)番茄時(shí)間段時(shí)間，休息30分鐘左右。每天大概能有12~14個(gè)這樣的時(shí)間片。

需要補(bǔ)充的是：這個(gè)技法適用于“有生產(chǎn)率的時(shí)間段”上，你可以真正的做點(diǎn)事情，其他的時(shí)間屬于非番茄時(shí)間。

協(xié)作問題

團(tuán)隊(duì)比項(xiàng)目更難構(gòu)建，因此，組建穩(wěn)健的團(tuán)隊(duì)，讓團(tuán)隊(duì)在一個(gè)個(gè)項(xiàng)目中整體移動(dòng)共同工作是較好的做法，給團(tuán)隊(duì)充足的時(shí)間，形成凝聚力，一直共同工作，成為不斷交付項(xiàng)目的強(qiáng)大引擎。

最后總結(jié)一下，專業(yè)軟件開發(fā)人員必須精通的事項(xiàng)

設(shè)計(jì)模式：

必須能描述GOF書中的全部24種模式，同時(shí)還有有POSA書中的多數(shù)模式的實(shí)戰(zhàn)經(jīng)驗(yàn)

設(shè)計(jì)原則：

必須了解SOLID原則，而且要深刻理解組件設(shè)計(jì)原則

方法

理解XP，Scrum，精益，看板，瀑布，結(jié)構(gòu)化分析，結(jié)構(gòu)化設(shè)計(jì)等

實(shí)踐

掌握測試驅(qū)動(dòng)開發(fā)，面向?qū)ο笤O(shè)計(jì)，結(jié)構(gòu)化編程，持續(xù)集成，結(jié)對(duì)編程

工件

UML圖，DFD圖，結(jié)構(gòu)圖，Petri網(wǎng)絡(luò)圖，狀態(tài)轉(zhuǎn)移圖表