2017年最后一周梳星，我按計劃把《The Clean Coder》讀完了，大約100頁左右慈俯。

第6章?練習(xí)

這一章的內(nèi)容是專業(yè)人士如何刻意練習(xí)归苍。Bob大叔提到40年來他使用的電腦綜合性能（內(nèi)存硬盤容量和速度宠默，顯示分辨率的提升麸恍；提及能耗價格等的縮減）提升了10的22次方倍，但是實際上計算機程序的本質(zhì)并沒有變化搀矫，是可以通過一些基礎(chǔ)程序的練習(xí)來不斷提升自己的技能的抹沪。為了讓22次方更形象，Bob大叔用了一個喬布斯經(jīng)常用的技巧瓤球，把它轉(zhuǎn)換成人可以理解的其他東西：是從這里到半人馬座阿爾法星的距離（以埃為單位）融欧，是1美元硬幣里的電子數(shù)，是地球質(zhì)量與個人質(zhì)量的比例卦羡。

今天噪馏，編譯不再需要程序員等待。現(xiàn)在仍然有些程序員必須等待構(gòu)建绿饵，這是悲劇欠肾，也是不夠仔細的征兆。如今拟赊，構(gòu)建時間應(yīng)該用秒來衡量刺桃，而不是分鐘，更不是小時吸祟。

構(gòu)建時間這么細節(jié)的問題體現(xiàn)了專業(yè)性瑟慈，比如前段時間大家關(guān)注解決的flex編譯時間的問題桃移，只是通過申請更好的機器就把整個項目的編譯時間從90分鐘縮減到20分鐘，這應(yīng)該是最便宜的投資了葛碧。不過還沒達到Bob大叔說的秒級構(gòu)建的水平借杰，這里還有進一步提升的空間，但是也需要有專業(yè)人士的投入才行吹埠，需要學(xué)習(xí)和嘗試下flex的增量編譯框架fcsh和flex編譯支持maven的工具flexmojos第步，也許會有幫助。

對于練習(xí)方式缘琅，作者給出了幾種形式粘都，一些練習(xí)套路，可以嘗試在公司里設(shè)計相關(guān)的課程刷袍。

卡塔

在武術(shù)里翩隧，卡塔是一套設(shè)計好的、用來模擬搏斗一方的招式呻纹。與之類似堆生，編程卡塔也是一整套敲擊鍵盤和鼠標的動作，用來模擬編程問題的解決過程雷酪。聯(lián)系著不是在解決真正的問題淑仆，因為你已經(jīng)知道了解決方案。相反哥力，你是在練習(xí)解決這個問題所需要的動作和決策蔗怠。

編程卡塔的最終目標，也是逐步練習(xí)以達到純熟吩跋。反復(fù)的練習(xí)會訓(xùn)練大腦和手指如何動作和反應(yīng)寞射。在不斷練習(xí)當眾，你或許會發(fā)現(xiàn)動作的細微進步锌钮，或者解決問題效率的小幅提升桥温。

要學(xué)習(xí)熱鍵和導(dǎo)航操作，以及測試驅(qū)動開發(fā)梁丘、持續(xù)集成之類的方法侵浸，找整套的卡塔來練習(xí)都是相當有效的。

Bob大叔給出了一些卡塔氛谜，參考網(wǎng)站http://codekata.pragprog.com通惫，其中包括在《ASD》中給出的保齡球計分程序。今年后備教練訓(xùn)練營的TDD作業(yè)混蔼，我做的就是這個BowlingGame的程序履腋。

真正的挑戰(zhàn)是把一個卡塔練習(xí)到爐火純青，你可以窺見其中的韻律。要做到這一點可不容易遵湖。

瓦薩

瓦薩基本可以說是兩個人的卡塔悔政。其中的招式需要精確地記憶，反復(fù)演練延旧。一個人負責(zé)攻谋国，另一個人負責(zé)守。攻守雙方互換時迁沫，各種動作要一而再芦瘾、再而三地反復(fù)。

程序員可以用一種叫“乒乓”的游戲來進行類似的練習(xí)：兩個人選擇一個卡塔集畅，或者一個簡單問題近弟，一個人寫單元測試，另一個人寫程序通過單元測試挺智，然后交換角色祷愉。

自由練習(xí)

自由練習(xí)就是不限制形式的搏擊。模擬搏斗與編程并不是特別貼合赦颇。不過二鳄，很多編程練習(xí)場中都會玩一種叫做“自由練習(xí)”的游戲。它很像由兩個參與者解決問題的瓦薩媒怯，只是自由練習(xí)是有很多人參與的订讼，而且規(guī)則是可以延續(xù)的。在自由練習(xí)中扇苞，屏幕被投影到墻上躯嫉，一個人寫測試，然后坐下來杨拐，另一個人寫程序通過測試，再寫下一個測試擂啥。桌子邊的人一個個輪流接下去哄陶，或者有興趣的人可以自己排隊參加。無論怎么安排哺壶，都是非常有趣的屋吨。

上面這三種方式，無一不是以TDD的方式進行山宾，和上一章的內(nèi)容吻合至扰。另外還有在業(yè)余時間參與開源社區(qū)，也是推薦的練習(xí)方法资锰，總之敢课，專業(yè)人士需要不斷的練習(xí)。

無論如何，專業(yè)人士都需要練習(xí)直秆。他們這么做濒募，是因為它們關(guān)心自己能做到的最好結(jié)果。更重要的是圾结，他們用自己的時間練習(xí)瑰剃，因為它們知道保持自己的技能不落伍是自己的責(zé)任，而不是雇主的責(zé)任筝野。練習(xí)的時候你是賺不到錢的晌姚，但是練習(xí)之后，你會獲得回報歇竟，而且是豐厚的回報挥唠。

第7章? 驗收測試

Bob大叔舉了一個和業(yè)務(wù)人員一起以不斷探索的方式寫應(yīng)用程序的例子，并總結(jié)了一些經(jīng)驗途蒋。其實是再一次闡述了敏捷的一些原則猛遍，強調(diào)變化是一定會有的，過早精細化是不必要的号坡，業(yè)務(wù)方自己很可能并不知道自己要什么懊烤。應(yīng)對方式是推遲精細化，用驗收測試驅(qū)動開發(fā)宽堆。驗收測試要自動化腌紧。幾年前測試團隊做過相關(guān)的嘗試，當時覺得在驗收自動化測試上投入有點高畜隶，沒有繼續(xù)進行下去壁肋，2018年是不是可以再嘗試一下，改變一下PO和BA的工作方法籽慢？

驗收測試和單元測試

驗收測試是寫給業(yè)務(wù)方看的浸遗，單元測試是寫個程序員的，它們并不重復(fù)箱亿。它們的主要功能其實不是測試跛锌，測試只是附屬功能。它們首先是文檔届惋，其次才是測試髓帽。

圖形界面的測試

這里提到了增加ID和分層測試服務(wù)兩種方式，都是以前曾經(jīng)嘗試過的脑豹，關(guān)鍵是要找到項目真實的落地郑藏。

持續(xù)集成

這里重點提到的是持續(xù)集成的紀律，集成失敗必須立即修復(fù)瘩欺，這是優(yōu)先級最高的事情必盖。實際做起來是需要全員意識上的改變的拌牲。

第8章?測試策略

“QA應(yīng)該找不到任何錯誤”，這是對專業(yè)人士的要求筑悴。QA的主要職責(zé)不是發(fā)現(xiàn)程序員的錯誤们拙，保證程序沒有錯誤是程序員自己的職責(zé)。那QA做什么阁吝？

QA在團隊中要扮演的是需求規(guī)約定義者(specifier)和特性描述者(characterizer)砚婆。

需求規(guī)約定義者：QA的任務(wù)是和業(yè)務(wù)人員一起創(chuàng)建自動化驗收測試，作為系統(tǒng)真正的需求規(guī)約文檔突勇。

特性描述者：QA的另一項任務(wù)是遵循探索式測試的原則装盯，描述系統(tǒng)運行中的真實情況，將之反饋給開發(fā)人員和業(yè)務(wù)人員甲馋。在這項任務(wù)中埂奈，QA并沒有解析需求，而是在鑒別系統(tǒng)的真實情況定躏。

自動化測試金字塔

專業(yè)開發(fā)人員遵循測試驅(qū)動開發(fā)的要求來創(chuàng)建單元測試账磺。專業(yè)開發(fā)團隊使用驗收測試定義系統(tǒng)需求，使用持續(xù)集成保證質(zhì)量穩(wěn)步提升痊远；同時垮抗，這些測試又屬于全局測試體系。擁有一套單元測試和驗收測試的同時碧聪，還需要有更高層次的測試冒版，這樣QA才找不出任何錯誤。

Bob大叔給出了五層的自動化測試金字塔逞姿，和我們經(jīng)炒俏耍看到的三層的金字塔不太一樣，從下到上依次是：單元測試滞造、組件測試续室、集成測試、系統(tǒng)測試谒养、人工探索式測試挺狰。

單元測試是程序員自己編寫自己使用，并且要做到接近100%的覆蓋率蝴光，通常在90%以上，并且是真實的覆蓋率达址，而不是那種雖然能通過但并不關(guān)心運行結(jié)果的錯誤的單元測試蔑祟。

組件測試和集成測試都是針對API進行的測試。組件測試針對單個組件沉唠，集成測試針對多個組件疆虚。組件測試由QA和業(yè)務(wù)人員編寫，開發(fā)人員提供輔助。常用的工具是FitNesse, JBehave, Cucumber径簿。針對GUI的是Selenium或Watir等工具罢屈。組件測試要覆蓋差不多系統(tǒng)的一半，主要是成功路徑篇亭。異常路徑是要靠單元測試來覆蓋的缠捌。集成測試主要針對大型系統(tǒng)，是編排性測試译蒂，主要不是測試業(yè)務(wù)規(guī)則曼月，而是測試組件裝配在一起時是否協(xié)調(diào)。集成測試一般由系統(tǒng)架構(gòu)師或主設(shè)計師來編寫柔昼，用于確認系統(tǒng)架構(gòu)層面的結(jié)構(gòu)是否正確無誤哑芹。集成測試時間運行比較長，一般不會作為持續(xù)集成的一部分捕透。

系統(tǒng)測試大約占測試的10%聪姿，由系統(tǒng)架構(gòu)師和技術(shù)負責(zé)人編寫，一般是在GUI層次乙嘀。

人工探索性測試不是自動化測試末购，它需要使用人類的創(chuàng)新能力，對系統(tǒng)進行深入研究和探索乒躺。預(yù)先編寫測試計劃反而會削弱這類測試的效果招盲。可以考慮一些全員“抓蟲”行動嘉冒。覆蓋率不是探索性測試的目標曹货。

結(jié)論

TDD、驗收測試這些組合起來讳推，最終目標還是讓QA找不到任何錯誤顶籽。

第9章?時間管理

會議

關(guān)于會議，有兩條真理：

（1）會議是必需的银觅；

（2）會議浪費了大量時間礼饱。

通常，兩條真理同時適用于同一場會議究驴。有些與會者認為這兩條總結(jié)得非常好镊绪，有些則認為它們是正確的廢話。

你需要為自己的時間負責(zé)洒忧，所以你需要選擇哪些會議參加哪些會議不參加蝴韭。Bob大叔提到Scrum的四會的問題，相關(guān)內(nèi)容應(yīng)該可以參考Scrum相關(guān)書籍熙侍。

爭論/反對

Kent Beck曾告訴我一個深刻的道理：“凡事不能在5分鐘內(nèi)解決的爭論榄鉴，都不能靠辯論解決履磨。”

如果爭論必須解決庆尘，就應(yīng)當要求爭論各方在5分鐘時間內(nèi)向大家擺明問題剃诅，然后大家投票。這樣驶忌，整個會議花的時間不會超過15分鐘矛辕。

注意力點數(shù)

現(xiàn)在是個爭搶注意力的時代，每個人最稀缺的資源就是注意力位岔，誰搶到更多的注意力就能賺錢如筛。如何保持注意力？

首先需要保證睡眠抒抬。Bob大叔每晚需要睡7小時杨刨。年初有幾個月我曾經(jīng)每晚睡5小時晌端，想多爭取些時間工作和學(xué)習(xí)氏仗，靠每天早晨的咖啡來支撐，后來發(fā)現(xiàn)自己有點扛不住档礁，就盡量往7小時睡眠靠了惠勒。前陣子聽樊登講《睡眠革命》赚抡，一個睡眠周期時間是1.5小時，如果在睡眠周期中間被鬧醒纠屋，則整天都會受影響涂臣，所以睡眠時間最好是1.5小時的整數(shù)倍，一周累積睡到35個周期就沒問題售担。正在嘗試中赁遗，貌似挺有道理。

肌肉注意力族铆。體力活動需要肌肉注意力岩四，編程需要心智注意力，兩者的要求不相同哥攘。不過定期訓(xùn)練肌肉注意力可以提升心智注意力的上限剖煌。Bob大叔的做法是騎自行車1-2小時，大約30-50km逝淹，騎車的時候可以聽播客或者音樂耕姊。我自己挺喜歡慢跑的，周六的早上慢跑聽書是一種享受栅葡，也是一種放松茉兰。不過進入冬天霧霾重了就沒怎么跑了。不過在家里做些俯臥撐也挺有好處妥畏。

時間拆分和番茄工作法

番茄工作法我用過一段時間邦邦，有時經(jīng)常被打斷或者自己內(nèi)心沒法靜下來；有時又覺得25分鐘時間好像有點短醉蚁，專注的做一件事情時剛進入狀態(tài)燃辖，番茄就結(jié)束了⊥鳎看到有的文章說番茄時間設(shè)置成1小時比較好黔龟。不過按照Bob大叔前面的說法，其實進入心流狀態(tài)并不是很好滥玷。也許25分鐘的番茄鐘就是很科學(xué)的氏身。

要避免的行為是優(yōu)先級錯亂，或者不按優(yōu)先級順序來處理惑畴，這個事情在我身上也經(jīng)常發(fā)生蛋欣，明明知道有個事情是重要的，但總是拖到最后一刻才做如贷，把自己逼到死角陷虎，搞得很忙亂。

番茄時間也需要回顧杠袱，感覺番茄工作法就是一個人的Scrum尚猿。我對自己的回顧就是對于每項事情的預(yù)估時間還是經(jīng)常偏樂觀，也許是因為自己有完美主義的傾向楣富。這個和敏捷的思路并不太匹配凿掂，造成自己效率不高，需要調(diào)整纹蝴。

死胡同和泥潭

死胡同：比如選擇了走不通的技術(shù)道路庄萎，越是堅持浪費的時間越多。要記得骗灶，任何時候都有選擇惨恭。

坑法則：如果你掉進了坑里，別挖耙旦。

比死胡同更糟糕的是泥潭脱羡。泥潭會減慢速度，但不會讓你徹底停下來免都。但如果你使盡全力锉罐，你仍然可以取得進展。

之所以說泥潭比死胡同更麻煩绕娘，是因為在泥潭中脓规，你仍然可以看到前進的道路，而且看起來總是比回頭路要短（雖然實際不是這樣）险领。

這兩個道理一看就懂侨舆，可以如何分辨哪些是死胡同秒紧，哪些是泥潭，哪些是需要堅持挺過去的呢挨下？感覺需要大智慧才行啊熔恢。

第10章?預(yù)估

預(yù)估是軟件開發(fā)人員面對的最簡單、也是最可怕的活動之一了臭笆。

承諾和預(yù)估

承諾是確定性的叙淌，必須要完成，其他人會依據(jù)你的承諾制定計劃愁铺。不能兌現(xiàn)的承諾是一種欺騙鹰霍。

預(yù)估是一種猜測，預(yù)估錯誤無關(guān)聲譽茵乱。

我記得Steve McConnell的《快速軟件開發(fā)》中有過描述茂洒，預(yù)估總是會給出兩個值，要么是一個區(qū)間范圍瓶竭，要么是一個值和概率获黔，而承諾就只有一個值。糟糕的是我們給出的大部分預(yù)估都會被管理者當成承諾在验，因為我們在預(yù)估時往往只給出一個值玷氏。

特別提一點，按照我們完成任務(wù)的時長繪制出直方圖腋舌，大致上是符合韋伯分布的盏触，而不是正態(tài)分布。從我司的度量數(shù)據(jù)可以看出這一點块饺。如果出現(xiàn)明顯不符合韋伯分布的曲線赞辩，要么說明任務(wù)粒度差異比較大，要么說明這里存在明顯的異常授艰，需要關(guān)注一下辨嗽。

常用的預(yù)估方法，都是PMBOK中的知識：三點法淮腾、DELPHI法等糟需。計劃撲克就是一種DEPLHI法。

關(guān)于軟件估算谷朝，McConnell專門寫了一本書洲押，可惜沒投入時間仔細讀過。從經(jīng)驗來看圆凰，多人一起拍腦袋做類比估算是比較靠譜的杈帐，在PMBOK中叫做專家判斷。目前業(yè)界的趨勢應(yīng)該是使用功能點方法或快速功能點方法，感覺其本質(zhì)也是類比估算挑童，不過是基于大數(shù)據(jù)的類比估算累铅，最核心的東西是其積累的成千上萬的項目數(shù)據(jù)信息。

第11章?壓力

即使有壓力站叼，專業(yè)開發(fā)人員也會冷靜果斷争群。盡管壓力不斷增大，他仍然會堅守所受的訓(xùn)練和紀律大年，他知道這些是他賴以戰(zhàn)勝由最后期限和承諾鎖帶來的壓力感的最好方法。

本章前面講述了Bob大叔自己承擔(dān)壓力以及他的應(yīng)對方法玉雾。確實在他40年的軟件生涯中翔试，什么都遇到過了。有興趣就閱讀原書吧复旬。

保持整潔

快速前進確保最后期限的方法垦缅，便是保持整潔。專業(yè)人士不會為了快點前進而亂來驹碍。他們明白“快而臟”是自相矛盾的說法壁涎。臟亂只會導(dǎo)致緩慢！

根據(jù)經(jīng)驗和我自己的理解志秃，如果工作總是在交接中怔球，可以找到下一位“接盤俠”，那么大家在工作中保持專業(yè)性的可能性就會大大降低浮还。以前我維護的程序竟坛，我知道出了問題都要自己去解決，沒有其他人可以依靠钧舌，所以為了讓自己維護和理解程序的負擔(dān)輕一些担汤，所以我會把所有已知的問題都花時間消除掉，這樣在遇到問題時我就不會分心去考慮這些已知的問題洼冻。已知的問題包括編譯器檢查出的所有告警崭歧，要么通過修改代碼消除掉隱患，要么自己要確信理解了編譯器告警的原因撞牢，并且明確這是無害的率碾。事實證明這個確實有效，我很為我以前維護過的程序的穩(wěn)定性和代碼質(zhì)量自豪屋彪。

是的播掷，那時我還不知道Clean Code和TDD，不然我一定也在自己維護的代碼中進行實踐撼班。

危機中的紀律

觀察自己在危機時刻中的反應(yīng)歧匈，就可以了解自己的信念。如果在危機中依然遵循著你守持的紀律砰嘁，就說明你確實相信那些紀律件炉。反過來說勘究，如果在危機中改變行為，就說明你并不真正相信常規(guī)行為中的原則斟冕。

如果在非危機時刻你會遵循測試驅(qū)動開發(fā)的紀律口糕，但是在危機時刻你放棄了這種做法，就說明你并不真正相信TDD是有幫助的磕蛇。如果在平常時候你會注意保持代碼整潔景描，但在危機時刻你卻會產(chǎn)出混亂的代碼，就說明你并不真正相信混亂會導(dǎo)致速度下降秀撇。如果在危機時刻你會結(jié)對工作超棺，但平時卻不結(jié)對，就說明你相信結(jié)對工作比不結(jié)對更有效率呵燕。

Bob大叔已經(jīng)說得很清晰了棠绘，我完全贊同。意識不到混亂會導(dǎo)致速度下降再扭，也許是因為還沒有合適的度量方式讓大家意識到這一點氧苍。想起CMMI顧問魏老師曾經(jīng)給過的一個建議：如果公司不為修復(fù)程序故障支付報酬，或者只支付固定比例的報酬泛范，也許對我們的交付質(zhì)量提升會有比較大的促進作用让虐。

應(yīng)對壓力

1：不要驚慌失措；2：溝通罢荡；3：依靠你的紀律原則澄干；4：尋求幫助。

第12章?協(xié)作

程序員正是因為不善于和人打交道柠傍，喜歡和機器打交道才選擇了這個職業(yè)麸俘。Bob大叔從程序員與雇主，程序員與程序員兩個方面討論了協(xié)作的問題惧笛，并且又是用自己親身經(jīng)歷來說法从媚。曾經(jīng)他做過獨行俠，忽略了雇主和公司利益患整，慘遭解雇的故事拜效。這部分簡單易懂，但很有警醒作用各谚，值得讀一下紧憾。

第13章?團隊與項目

有凝聚力的團隊

形成團隊需要時間。團隊成員需要首先建立關(guān)系昌渤。他們需要學(xué)習(xí)如何互相協(xié)作赴穗，需要了解彼此的癖好、強項、弱項般眉，最終了赵，才能凝聚成團隊。

有凝聚力的團隊確實有些神奇之處甸赃。他們能夠一起創(chuàng)造奇跡柿汛。

有凝聚力的團隊通常有大約12名成員。由12個人組成的理想團隊埠对，人員配備情況是這樣的：7名程序員络断、2名測試人員、2名分析師和1名項目經(jīng)理项玛。

這個團隊規(guī)模不符合5-9人的原則貌笨，不過可能平常我們是認為分析師（BA）和項目經(jīng)理（PM）是團隊外的人員，算起來也差不多稍计。這個規(guī)模差不多也是我們以前一個科室的規(guī)模，確實感覺很不錯裕循。記得團隊在解散的時候科室同事在公司論壇上留下一個帖子：“鋼七連要解散了臣嚣，實名留念”。我被別人叫做“七連長”（參考《士兵突擊》）剥哑，感覺這是我十幾年工作生涯中得到過的最高褒獎硅则。

團隊和項目，何者為先株婴？

試圖圍繞項目來構(gòu)建團隊是一種愚蠢的做法怎虫。按照這種做法，團隊永遠都不可能形成凝聚力困介。

專業(yè)的開發(fā)組織會把項目分配給已形成凝聚力的團隊大审，而不會圍繞著項目來組建團隊。一個有凝聚力的團隊能夠同時承接多個項目座哩，根據(jù)成員各自的意愿徒扶、技能和能力來分配工作，會順利完成項目根穷。

結(jié)論

團隊比項目更難構(gòu)建姜骡。因此，組建穩(wěn)健的團隊屿良，讓團隊在一個又一個項目中整體移動共同工作是較好的做法圈澈。并且，團隊也可以同時承接多個項目尘惧。在組建團隊時康栈，要給予團隊充足的時間，讓他們形成凝聚力，一直共同工作谅将，成為不斷交付項目的強大引擎漾狼。

第14章?輔導(dǎo)、學(xué)徒期與技藝

這是全書的最后一章（不算附錄饥臂，附錄說的是工具逊躁，和人無關(guān)），Bob大叔用自己的成長經(jīng)歷做了個總結(jié)隅熙，表達了對學(xué)谢海科班教學(xué)的失望，認為學(xué)校的教育并沒能教會學(xué)生編程囚戚，真正的編程是在工作中學(xué)習(xí)和錘煉出來的酵熙。這個確實是現(xiàn)狀，可能在中國和美國都是類似的情況驰坊，我自認自己只是個中級水平的程序員匾二，這個能力水平也是在工作之后讀了一些書做了一些實踐之后獲得的，剛畢業(yè)的時候確實很渣拳芙。

Bob大叔是雪鳥會議的發(fā)起者察藐，某種意義上說可以認為是敏捷宣言之父，他同時也是軟件工藝運動的推動者舟扎，他用這本小書向我們闡述了何為專業(yè)人士分飞，以及如何成為專業(yè)人士，為他的專業(yè)精神所折服睹限，推薦程序員都讀一讀譬猫，然后不再自稱“碼農(nóng)”。

很高興自己在兩周內(nèi)讀完了一本書羡疗，并且這也是唯一一本我寫完了讀后感的書染服，感謝Bob大叔的言簡意賅。

對了叨恨，其實還有最后的附錄工具沒有寫肌索，里面提到了配置管理工具svn/git，代碼編輯器IDE特碳，持續(xù)集成工具诚亚，問題跟蹤工具，自動化測試工具等午乓，提供的都是最優(yōu)秀的選項站宗，值得學(xué)習(xí)和參考。

我是有底線的