持續交付領域專家喬梁老師是一個好人，他講話特別委婉。喬老師說：“你不改變你的工作方式就不能得到 10 倍的效果。”大家聽了這個話以后就覺得，他講的是一個抽象的“人群”。每個人聽到這個話以后都有一個自我暗示：喬老師說的是其他人，我不包含在內。因為他是好人，他不肯把話說得太直白。其實喬老師批評業內敏捷現狀的話，說直白了就是斷水流大師兄的話：“我不是針對你，我是說在座各位……” 

當然這個現狀不完全是你們造成的。臺下的各位大部分還很年輕，這些現狀形成的歷史因素很可能你們還不了解。我今天分享的就是這些行業歷史的故事。

中國 IT 行業的發展不是自然而然的。有人認為，經濟自然發展到一定的程度就自然會推動信息科技的發展。不是這樣的。有一個反例就擺在面前，香港現在的 IT 行業就非常糟糕，經濟的發展并沒有自然而然地推動香港 IT 的發展。IT 是一個非常高端的行業，它不是自然就會發展起來，它需要政府有相當大的主導意向。

因“18 號文件”而興起的中國 IT 業  

大家可以查一下 2000 年 6 月頒布的國務院 18 號文件《鼓勵軟件產業和集成電路產業發展的若干政策》，中國的 IT 行業完全是這個發文推動起來的，其中給了這個行業很多的優惠政策，很多政策直到今天仍然在推動這個行業的發展。

在“18 號文件”頒布之前，2000 年的時候，中國 IT 行業從業人員大概是十幾萬人，是一個很小的行業。到 10 年以后，這個人群發展到了數百萬人。這個發展的速度，人的大腦本能理解不了。我們可以做個對比：中國的經濟發展也是很快的，每年 10% 左右；當時政府的預測是 IT 行業可以有每年百分之十幾的增長，超過 GDP 增速。但是實際上，從 2000 年以后的 10 年，IT 行業保持了每年 50% 以上的增長，這是“放火箭”一樣的發展，超出所有人的理解能力。在 10 年的時間從業人數增加了數十倍，這對整個行業來說是一個巨大的考驗。

很快，這個行業就遇到了挑戰：軟件質量差、交付進度難以保障，等等。這種現象大家很熟悉，軟件工程的教材上講過，這個叫軟件危機。當時專家的意見是：為什么會出現軟件危機，是因為技術環節不過關，社會化大生產沒有形成，解決的辦法就是要提高軟件工程水平。

這是 2001 年的行業大背景。當時的行業對軟件工程有一種非常迫切的需求。于是那個時候，行業就去引進了 CMM。

以 CMM 為代表的軟件工程理論準確識別軟件開發的基本功  

2001 年，我給《程序員》雜志社采訪了號稱“CMM 始祖”的一個印度人。CMM 在 2001 年左右傳入中國，非常明確給中國軟件行業指出了問題所在。它非常清楚地指出軟件開發應該具備哪些基本的能力：需求管理，項目管理，配置管理，質量保障等。這些能力就是 CMM 二級里面定義的，大家回頭找 CMM 二級來看一下就知道了。從這個角度來說，CMM 是一個非常有價值的框架。

國家對 CMM 做了很多的補貼。當時科技部主導，從北京市開始各地都有相應的補貼政策：通過 CMM 二級認證補貼 20 萬，三級 30 萬，五級 50 萬。

十八年后，行業的基本功扎實了嗎？  

有這么好的政策在這兒，十八年以后，我們行業的基本功補齊了嗎？我們行業的基本功扎實了嗎？

我覺得這個事情不能用非常抽象的方式來講，我來講幾個真實的“鬼故事”。

需求管理？  

比如說需求管理我可以講個故事。2009 年、2010 年的時候，我當時在很著名的某家通信企業指導一個項目，當時跟華為的兩個系統工程師去客戶那調研需求。去之前這兩位工程師說：“你不知道，我們這個客戶是妖怪，沒事兒就罵我們，動不動就改需求，特別的可怕。”我說我去看一下吧，了解一下這個妖怪的客戶都是怎么回事兒。

約到客戶上午 9 點鐘開始調研需求，我們幾個人走過去，這兩位系統工程師上去：“你好，現在你有什么需求，請告訴我們。”后來我看《人民的名義》那個片，我就聯想起這兩位系統工程師調研需求的場景，他走到那兒把手一伸：“請開始你的表演。”然后客戶就開始講，一上午三個小時，客戶大概講了 2 小時 58 分鐘，兩個系統工程師講了可能不到 10 句話，包括“你好”、“請開始你的表演”、“謝謝”。

然后需求調研就完了，中午的時間寫會議紀要，寫完以后給客戶發出去，20 分鐘以后客戶打電話過來開始罵人，整個辦公室都聽見了：“你們做的是什么需求調研？我一早上給你講了 3 個小時，講了 5 個要點，你郵件紀要發過來只有 3 個要點，你浪費我一早上時間逗我玩嗎？”

這個就是我們行業里面很領先的企業調研需求的方式。類似的行為我后來看到過很多次，大家去“調研需求”到底是干什么？就是走去：“客戶爸爸你好，請問你有什么需求，請你告訴我。”這樣調研需求，需要什么技能、需要什么專業能力？什么都不需要。這個就是人類本能好嗎？“我想知道一件事，請你告訴我可以嗎？”這個 6 歲小孩也會。從這些現象里，我后來總結出來一個概念叫做“全憑本能工作”。我們這個行業里有很多本來應該是專業人士做的專業工作，實際上是全憑本能在做，看不到專業的能力。

項目管理？  

說完需求管理我們再來說項目管理。我們這個行業的項目管理到底是怎么做？你找一個項目經理來問，你的項目管理是怎么做的？他能跟你講很多大道理。但你到軟件開發的現場里面去，到項目組里面待個兩星期，你看看項目管理到底怎么發生的。真實的情況經常是這樣：

項目經理走過來問：“你這個任務哪天可以完成？”

開發：“下個禮拜一吧。”

項目經理：“下個禮拜一？這個時間太長，禮拜五能不能完成？”

開發：“不行，這工作量太大了。“

項目經理：“就禮拜五，我們禮拜五就上線了。“

開發：“好吧，禮拜五就禮拜五，我加個班，挑戰一下！“

是不是我們真正的項目管理就是這樣發生的？你說這個項目管理，到底管理什么？真實項目里的工作量評估是怎么估的？

開發說：“做這個要 5 天。“

項目經理：“憑什么要 5 天，明明 2 天就做完了。“

開發：“那 3 天吧。“

這是項目管理嗎？這是賣白菜。

配置管理？  

然后我們再來說配置管理。我以前做一個持續集成的咨詢項目，我先非常自信地把代碼庫 check out 出來，然后我去打一杯咖啡回來再看看。打完咖啡，發現還沒有 check out 完，那我再去開個會。開完會回來看看，還沒有 check out 完，那我再去吃個午飯。吃完飯回來看看，還沒有 check out 完，我就納悶了。

我：你們這個代碼庫怎么這么久還沒有 check out 完呢？

客戶開發：你自己在 check out？，我們都不這么干，我們都是從別人那里拿一個移動硬盤拷過過來。

我：你代碼庫多大？

客戶開發：代碼庫有 5 個 G……

后來我拿一個移動硬盤把代碼拷過來一看，這個代碼庫有 5 個 G，上面有一千多個分支。這就是 CMM 五級的企業的配置管理水平。很多故事我都不好意思說，鬼故事講出來嚇死人。

質量管理？  

接著我們再說說質量保障。為什么現在行業里面大家搞迭代，周期都是兩個禮拜一個版本，成了行業共識？ 因為都是一幫測試小姑娘跟著屁股后面做人肉測試，你怎么敢繼續縮短呢？你縮短到一個禮拜發一個版本，然后小姑娘就得每個禮拜天天加班。這就是我們這個行業里的質量保障水平。

所以，像我這種工作時間長的人就非常好奇。我 2001 年就看見了當時搞 CMM 的時候，有很多的培訓公司講課，然后政府又有補貼，通過 CMM 的公司非常多。那這個事情到底是怎么跑偏的？為什么大家搞了十幾年的 CMM，到現在行業里面的能力是這樣的，各個公司都是全憑本能在工作？前兩天有一個群里有人說：“我們公司的研發管理做減法，不寫文檔了，做完減法之后我們非常敏捷。”我說你們從來就沒有研發管理，做的什么減法呢？你們有一堆文檔，但是文檔跟真正發生的研發根本就是兩碼事，實際上的研發就是大學實驗室的工作方法，大家全憑本能在工作。

軟件工程是如何跑偏的？  

那么軟件工程到底是什么時候跑偏的呢？我去年寫《敏捷中國史》的時候看了很多的材料，然后發現很多的事情是從根子上跑偏的。一開始，很多專家把軟件的生產和制造業相關聯。但是非常有趣，盡管這些中國軟件工程專家經常講制造業，但是他們對制造業根本不懂，他們根本不知道這個制造業是怎么發展。

1995 年左右，美國里海大學亞科卡學院受國防部的委托，做了一個叫做《21 世紀制造業挑戰》的研究，這個研究報告里講 21 世紀的制造業有什么特征？是需要高度的定制化、高度的柔性，需要減小批量。聽著像什么？像敏捷。而我們國家的軟件工程專家們根本不了解制造業的這些新發展。他們在腦子里面自己想象了一個“制造業”，然后說我們的軟件工程應該像制造業。他們想象的制造業是少數的精英在上面做設計、下面有大量的軟件藍領把精英的設計一模一樣的寫出來就完了。

基于這么一個模型，他們就開始搞培訓，要求程序員踏踏實實搞工作，不要去想別的，不要去跟需求方打交道，這就是軟件藍領。而同一時期，美國的制造業在說：不應該嚴格區分設計和制造，不應該限制員工思考的空間。這些專家想象的制造業，跟制造業的發展方向根本南轅北轍。

CMM 是如何跑偏的  

那么 CMM 明明已經提出了很好的問題，為什么這個問題沒有得到解決？國內軟件專家的誤解呢，只能說他的知識不夠多，不知道國外的軟件和制造業到底是怎么樣的發展，所以有了自己的想象。而 CMM 我認為很大程度上是個人品問題。從最早的“CMM 始祖”Ron Radice 開始，CMM 周圍就一直有這種人品問題。

這個號稱 CMM 始祖的人 2001 年到中國來訪問，我當時參加了對他的采訪。當時總共有 5 家媒體對他做了采訪，宣傳做得到處都是。我后來做了對這個人比較深入的調查，他是在發明 CMM 的研究小組里面一個研究員，他大概只發表過 2 篇論文，沒有什么重要的學術著作。他在 CMM 的創始過程當中只能說起到了非常輔助的作用。據說印度的總理專門接見了他，我起碼花了 5、6 個小時的時間嘗試去找到這么一個接見的報道，沒有任何結果，我認為這是編造出來的。

我覺得這個人非常有象征意義：CMM 從傳入中國的第一年開始就充滿了編造、吹捧、虛假、欺騙。2002 年的時候，這種現象已經引起 SEI 的關注了。SEI 認為一家企業在一年時間里從 CMM 二級過到五級，這是不可能的事情。而這個不可能的事情在中國 2002 年、2003 年連續發生了三次。所以當時 SEI 自己開始撇清關系了，就說我們認為這是非常不可能的。

這么不可能的任務，這些公司是怎么做到的？非常簡單，叫做裁判下場踢球。非常簡單的一個邏輯：公司想要這個認證，找誰做咨詢？這個咨詢師就是未來的評估師。咨詢師收了你 10 萬以后，然后他自己做的咨詢，他自己回頭再來評估，當然評估就通過了。就是一個很簡單的玩法。那么企業為什么要花這個 10 萬來請這個咨詢師？因為有政府補貼。政府會補貼你 20 萬通過二級。所以就成為了一個完整的利益輸送鏈，咨詢師、主任評估師和企業聯手搞一個認證通過，就可以從政府那兒掏錢出來，企業白拿一個證，從政府那套的錢比它自己花的經費還多。這是一個完整的利益輸送鏈。

我經常講，“18 號文件”做了很多的好事情，但是其中的一件事情做的非常糟糕而且匪夷所思，就是對 CMM 的補貼。對 CMM 的政策補貼，這是中國改革開放史上前所未有的事情，不知道以后會不會有來者。前所未有在什么地方？中國改革開放史上有很多的產業補貼，比如對光伏的補貼，對大數據的補貼，對出口創匯的補貼，但是這些補貼政策至少都有一個出發點，就是你得做東西，對吧？你要領光伏的補貼，你得做出光伏來。你要領出口創匯的補貼，你得出口創匯。而對 CMM 的補貼是中國改革開放史上僅有的一個：你這個企業什么都不用干，不用開發軟件，不用有收入，不用提升團隊的能力，就可以領補貼。這是一個非常奇怪的政策。在這個政策的鼓勵下，CMM 全國到處一片瘋，所有的企業都去搞這個事情，因為是可以賺錢的。這就是政策補貼之下的亂象。因為有了這個政策補貼，搞 CMM 的全是騙子，沒有一個例外。現在，我經常跟搞 Scrum 認證的這些朋友在打交道，我跟他們開玩笑說你們搞 Scrum 幸運就幸運在沒有什么補貼，沒有補貼就不怎么招騙子。所以搞 CMM 的全是騙子，你們搞 Scrum 的不全是騙子。

一線的實踐者在干什么  

CMM 咨詢師在騙錢的時候， 一線的實踐者在做什么？在一線干活的這些人是真正感受到了非常迫切的對軟件基礎能力的訴求，所以是有一些人在干一些很扎實的事情。

林星當時在廈門國際銀行做項目經理，他在 2001 年發表的幾篇文章，很大程度上講的就是極限編程里面用戶故事這一部分的內容。

另一個極限編程的先行者石一楹 2001 年的時候在杭州，他是國內最早翻譯跟重構相關內容的技術作者。他發表了這個系列文章以后，我看到這些文章覺得非常的激動，其中對于代碼的理解、對代碼的質量和美感的追求，對我來說是一個很重要的啟蒙。后來我知道，他是看了《重構》這本書以后，從里面提取的內容。我后來翻譯《重構》這本書，和石一楹給我的啟蒙是有很大的關系。我看了他的文章以后非常受鼓舞，就在《程序員》雜志上做了《重構》的技術專題，后來又做了極限編程一系列的文章。

2002 年時候，人民出版社引進了極限編程系列叢書，這是中國第一本關于敏捷的圖書，這本書直到今天去看還是非常有價值的。

唐東銘這個同學他其實是一個相當傳統的軟件工程改進的這么一個人。他后來在 18 年的職業生涯當中，沒有真正的做過敏捷的項目。人生的機緣巧合就是這么難以預料，他最早引進敏捷的書，可是一直沒有得到機會去做敏捷的項目。

當時中興有幾個人，包括鄧輝、孫鳴他們，對敏捷非常有想法。鄧輝 2003 年翻譯出版了《敏捷軟件開發》這本書，我翻譯的《重構》也是 2003 年出版的。這些敏捷的基礎理論的準備基本上 15 年前就已經完成了。直到現在，很多人問我這個問題怎么解決、那個問題怎么解決，我拿出來的答案都是 15 年前的書。

十八年來唯一真正抓基本功的方法  

18 年來，行業里有很多的方法來來去去，真正可以抓軟件開發的基本功、真正可以提升軟件團隊的能力的方法，我覺得就只有極限編程。CMM 提出的這些核心能力，只有極限編程真正提供了。

一件事應該怎么做，你在書上看到一個說法，和你真正在工作上能做這件事，是相差很大的。

再比如項目管理，極限編程會告訴你迭代怎么去管，根據什么來看項目的進度。當然項目管理這一部分，我認為 Scrum 也是很好的，非常有效地告訴大家項目管理的方法。

再說配置管理。到底什么是配置管理？其實配置管理落到根本上就是持續集成。有持續集成，你就有有效的配置管理；沒有有效的持續集成，就是沒有配置管理，就是這么簡單的事情。沒有持續集成，你可以說在紙面上有很多配置管理的流程，但真到了需要軟件的時候你怎么辦？你只能依賴一個配置管理員來手工打包。越是你著急需要打包軟件的時候，這個人就越出錯、越是打不出包來。好不容易打出來的包一測有問題，然后大家一起加班。所以我說配置管理很簡單，你有持續集成、每天可以有一個候選版本通過持續集成打出來，你就有配置管理；出不來，你就沒有配置管理。

那為了讓持續集成有效，最后的最后一切都會落到重構和單元測試上面。是不是擁有高覆蓋率的、可靠的、運行快速的單元測試，這是一個決定性的分水嶺。而高覆蓋率的、可靠的、運行快速的單元測試集，得到這個東西最有效的辦法，就是測試驅動開發，就是你必須先寫測試、再寫實現，你才可能得到這么一個有效的測試集。有很多人跟我講，我們先趕緊寫完了實現，回頭再去補單元測試。“寫完實現再去補單元測試”，這個鬼故事，我每年都聽十幾次，你們誰見它真正發生的？我們經常聽到這個對話：

領導：單元測試很重要，我們要寫單元測試。

開發：好好好，等我改完這個版本我就補單元測試。

改完了這個版本就有空了嗎？有空了還有下一個版本呢。你在寫代碼的時候根本沒有考慮怎么單元測試，為什么你認為寫完實現代碼以后就可以補上測試了？你補不上。你會對著一大堆草率堆上去的代碼長嘆一口氣，因為你一開始寫代碼的時候就沒考慮代碼的可測試性。

這件事情我覺得非常有趣：軟件工程的教科書里面都寫著，單元測試是軟件開發的重要環節。所有人都認同單元測試的價值，但是誰也不做。然后到了實踐里面，大家說我寫完這個版本我就補單元測試，然后這個版本完了之后沒有補，然后下一個版本來了之后又說，我寫完這個版本就補單元測試，下一個版本做完也沒有補。這種現象使我對于人類作為一個整體的學習能力非常擔憂，因為大家沒有從歷史中學習的能力：補單元測試這個事情是從來沒有發生過的，所以未來它也不會發生，這才是合理的。你根本就不應該相信“我做完這個版本補單元測試”這種話。

所以一切的一切最后都會歸結到有沒有有效的單元測試集。得到有效的單元測試集最直接的辦法，叫做測試驅動開發。我翻譯《重構》第二版的時候跟另一個譯者林從羽開玩笑說，你告訴任何一個敏捷實施當中遇到的問題，我都可以告訴你這個問題是因為沒有做好 TDD。

Scrum 為何僵尸化？  

比如說前段時間有人發明了一個詞叫“僵尸 Scrum”，什么意思？大家早上開晨會的時候都低著頭無精打采的：“我昨天在做這個任務，我今天繼續做這個任務，我沒有什么問題。”就跟一群僵尸一樣的，毫無生氣。你們都見過這個現象吧？為什么會有僵尸 Scrum？因為每個人的任務、每個人負責的代碼，是一塊一塊隔開的，誰跟誰都沒有關系。那為什么要把開發一個個隔開呢？因為誰也不敢改別人的代碼，別人的代碼看也看不懂，看懂也不敢改，改了也不知道有沒有引入 Bug。為什么別人的代碼看不懂、不敢改、改了不知道有沒有破壞功能？因為沒有單元測試嘛！為什么沒有單元測試？因為你沒有 TDD 嘛！

這就是個例子。我半開玩笑說，你告訴我任何一個跟敏捷實施相關的問題，我都能給你推導出來，是因為你沒有 TDD。但是這個邏輯太繞，太曲折，很難跟人講通。我昨天在一個敏捷群里面又跟人吵架。我說我的標準非常簡單，有 TDD 的敏捷就是好敏捷，沒有 TDD 的敏捷就是偽敏捷。再多的邏輯我都懶得跟他們講了。郭德綱有一個話，說一個外行跑去跟火箭科學家說你們火箭的燃料不行，得燒煤，還得是精煤，水洗的不行，那科學家要是拿正眼看他一眼都輸了——我就輸了，那群里的“敏捷專家”連代碼都不會寫，我還跟他講 TDD。

持續交互、研發云、微服務、DevOps...  

再往后就有了很多新的方法，持續交互、研發云、微服務、DevOps......，每一波我都經歷過。每一波新方法流行，就會有客戶來問我對這個有什么看法。每一次他們來找我問的時候，我發現他們要解決的都是同一個問題。這個問題就是軟件開發的質量很差、速度很慢。然后就開始想各種辦法繞過這個問題。

比如說微服務流行那年，大家想的是：如果說開發一個單體應用質量很差、開發很慢，那我們是不是可以把單體應用拆分成若干個微服務，每個人負責一小塊微服務，然后就可以對質量的要求沒有那么高？最后發現，還是不行。一波一波的浪潮過去，看多了之后，我終于明白一個很簡單的道理。最后決定開發的質量和效率的是什么？是持續集成，是持續集成里面運行的測試集的效率和質量。你可以得到一個高效率、高質量的測試集，你就能做好軟件。沒有高效率、高質量的測試集，軟件開發的效率和質量就不會好。

于是我們又回到這兒來了。大家一波一波的嘗試解決同一個問題，但是從來不去解決這個問題的核心，都在繞著問題走，都在想可以用什么樣的流程和工具去解決問題，就是不敢直面核心的問題：我的人基本功不行，我們不會 TDD。一次一次去繞，一次一次繞不開。《敏捷宣言》第一句怎么說？人和交互重于流程和工具。但是搞敏捷的公司在做什么？十幾年了，一次一次想用流程和工具解決人和交互不行的問題。

以前我做咨詢的時候，我必須要為了項目的需要、為了公司收入的需要去配合這些客戶，跟他們一起想辦法，用流程和工具稍微緩解一下問題。現在我不做咨詢了，我終于可以說實話了：這個核心問題繞不開，沒有辦法。軟件開發的質量和效率不行的問題，它就是一個人和交互的問題：“人”就是個人能力的問題，“交互”就是團隊能力的問題。人的能力和團隊的能力不提升，基本功沒有扎實，用什么樣的工具都解決不了這個問題。

沒有基本功，什么花哨套路都白搭  

軟件做不好，就是因為不知道怎么開發。沒有基本功，什么花哨的套路都玩不了，玩到最后你都會面臨同樣的一個問題：我今天在這兒改一行代碼，我怎么知道改完以后整個系統到底是不是好的？怎么回答這個問題，是決定性的分水嶺。如果你沒有一套完備、可靠、快速的測試集，那么回答這個問題唯一的辦法就是改完這行代碼然后叫測試部的小姑娘來回歸測試。但是測試部的小姑娘她會很反感老是這么人肉回歸，她就會打我。她打了我之后，我下一次不敢隨便找她了，于是我就多攢一堆修改再去找她：“姐姐，給我一起回歸一下唄。”現實就是這樣的，軟件開發的周期就是這么被拖長的。沒有 TDD，你就解決不了這個問題。所以軟件開發的核心問題，不管講 DevOps 也好，講持續交付也好，最終都得回到極限編程這里來。

之前有大概幾年的時間，我對這個信念產生了懷疑：我說極限編程是不是太難了？是不是不適合這個行業？其實細想想這個說法也挺不好的。當我說“是不是極限編程不適合這個行業”的時候，我心里面想的是：在座的各位智商是不是有點不足，所以你們掌握不了極限編程？但我覺得實際情況不是這樣。我覺得大家都是有這個能力的。所以我重新堅定了信念。

回到極限編程，回到軟件開發基本功  

今年不是講“不忘初心、牢記使命”嗎，我現在重新找回了我的初心和使命：極限編程是正確的，極限編程是真正有效的軟件開發方法。所以我們一幫朋友把極限編程的中文網站做出來了。網站做出來以后非常的有效：別人問我很多軟件開發方法和管理方法的問題，我直接從極限編程網站找一段，截一個圖甩過去，很多問題直接就可以解答。

同時，我想證明一件事情：極限編程沒有那么難，它不是在座各位不可以掌握的，它不是一個有著巨高的智力門檻的事情，它是所有人都可以掌握的。為了證明這件事情，我到現在為止開了 5 期的極限編程的練功房，每一期幾百人，到現在為止大概有 2000 人在我的練功房里面學 TDD，學重構。事實證明這些東西不是學不會的，還不會的這些同學缺的就是刻意練習，你沒有動手去練而已。

基本功的提升辦法只有一個：刻意練習  

什么是刻意練習？

刻意練習有三個要素。

第一是大量的重復練習。你在書上看到一個東西，不等于你就會了這個技能。看完書以后你可能可以跟領導去白活兩句，面試的時候可以吹一吹，但是你肯定不會。這個技能，你在工作中用不出來，這個就是不會。要掌握一個技能，就必須要練，必須要大量重復的練習。

第二，要在學習區去練習。那就需要有人來設計練習的節奏，設計每天該練什么。大家可以去看 Kent Beck 的《測試驅動開發》那本書，非常好的一本書，由淺入深循序漸進的。但是很多人看那本書，一上來就被打懵，根本看不下去。為什么？我做了這些培訓之后才知道，很多人自己的電腦上開發環境沒有準備好，JUnit 測試怎么寫、怎么運行都不知道。所以一定要有人給你設置每天練習的目標，給你拆解每天該練什么、掌握什么技能，才能一步步練下去。

第三是要有及時的反饋。有人告訴你今天練得對不對。在這些練功房的培訓里面，我看到跑偏的太多了，跑偏的方式千奇百怪。所以必須有人看到，這個同學今天這個練習是跑偏了，然后要告訴他正確的練習方法是什么樣子的，他才會有所進步。

做了這些練功房的培訓以后，我最近開始反思另外一個問題：我們這個行業里面的培訓、知識付費，這些東西到底在干嘛？我前兩天跟另外一個知識付費的平臺談合作，他說他們的課程是以音頻為主，要給學員聽聲音。我就好奇了，什么場景下大家需要一個音頻為主的學習方式呢？他說，比如說我們學員早上開車的時候就可以聽這個課，晚上睡覺之前可以抱著手機聽一節課。你早上開車的時候聽一節課可以學到什么有效的知識？你什么都學不到。你只能獲得一種幻覺，這個幻覺叫做“我今天早上開車的時候學到知識了”。

所以我突然之間發現，這個行業里面大量的知識付費都是騙子，因為他根本沒有讓你掌握一個技能。比如說我舉個例子，吳恩達的機器學習的課，你如果不去做他的練習，你就看一遍他的視頻，甚至于更糟糕的，你聽一遍他的音頻，你可以學會機器學習嗎？不可能的。你一定要反復練習，要有人告訴你練習的效果，你才會學到東西。那這些知識付費到底在干嘛？這個問題非常的困擾。

包括線下的培訓也一樣。線上培訓的采購是這么一個邏輯：學員給老師打分，然后采購培訓的這個人根據學員的評分來看老師的水平怎么樣。那學員怎么給老師評分？如果老師拿一個教鞭逼著學員好好練，練不好一鞭子打下去，你覺得學員會給老師打高分嗎？不會的。學員打高分就是這個老師講得很好，講得很風趣，老師穿插了很多的游戲，寓教于樂，我就給老師打高分。結果我們看到現在的企業培訓是一個什么場景？老師恨不得在臺上表演：“培訓是一門語言的藝術，講究說學逗唱……”這不是在學本事，這是小劇場聽相聲呢。那我們這個行業到底變成了一個什么行業？是一個傳授人技能的行業還是說相聲的行業？

所以，我現在不做這種音頻、視頻的知識付費了，現在開練功房就是學員們進來，我設計好了每天的練習任務，學員自己練，自己反思，練完了拿出代碼來我點評。人就是得反復練，才能養成新的習慣。