藍色系圖文排版教程（4萬字的整潔三部曲）

2023-04-21 20:04:28

6月14日晚7點半，一場以「解碼Bob大叔整潔之道三部曲」為主題的直播活動剛剛結束。

如果你知道Bob大叔，如果你對他的整潔之道有所耳聞，你一定能想像這場直播具有的非凡意義。從2001年敏捷宣言的誕生，到2009年《代碼整潔之道》的面世，再到之後的《代碼整潔之道：程式設計師的職業素養》，今年，剛好整整20年，Bob大叔創作的《敏捷整潔之道：回歸本源》構成了「整潔三部曲」，其背後的思想和歷程值得每一位希望寫出整潔代碼的程式設計師挖掘。

另外，還有一點難得的是，這場直播請到的嘉賓正是「整潔三部曲」的譯者，時隔十年，齊聚一起，為你解碼「Bob大叔」關於整潔代碼的核心理念和價值。

（這篇回放稿總共接近4萬字，在這裡小編儘量保證不曲解大咖們的原意，將其主要觀點和精華濃縮出來，呈現給大家，希望大家有所收穫。）

1 代碼猴子的整潔之旅

分享嘉賓：韓磊

網際網路產品與社區運營專家，技術書籍著譯者。曾任CSDN及《程式設計師》雜誌副總經理、總編輯，廣東二十一世紀傳媒新媒體事業部總經理等職。現任AR初創企業亮風臺廣州公司總經理。《代碼整潔之道》譯者。

觀點提要：韓磊老師從國內軟體行業現狀出發，講了「代碼產出能力變低」的原因、個人對「整潔」的理解，剖析了敏捷與整潔的關係，並猜想了未來軟體行業的發展。

主題由來

在2007年，我曾經到矽谷參加一個軟體開發者大會，在這個會上面，Robert C. Martin Uncle Bob關於軟體匠藝的分享讓我收穫頗豐。

一開場Uncle Bob就唱了一首歌，這首歌叫做《Code Monkey》，這首歌是一個叫Jonathan的程式設計師寫的，寫的是從前自己的一個生活。

2007年，Uncle Bob用代碼猴子這首歌來做開場，一方面是一種自嘲，另一方面也是形容很多程式設計師工作和生活有的時候是一團糟的。

對軟體行業的憂心

2010年我翻譯這本書，之後的10年裡，繼續看到很多爛的代碼在出現，繼續看到很多程式設計師每天下班九九六，有的是零零七，陷入在無邊無際的需求當中，其實這樣的情況是很令人痛心的，有的時候我們常常會怪罪外部的環境，但有的時候確實不見得完全是外部環境的錯。

任何一個軟體項目，當它相對而言略有複雜度之後，稍微略有複雜度的軟體項目進行到一定程度之後你們會發現代碼產出的能力，隨著時間的增長慢慢變得低下，這其實是有點不太合理的。

為什麼在一個程序組或者項目組裡面，生產會順著時間的增長一直往下掉呢？很簡單，當代碼量達到一定程度之後，你程序的複雜度增加了。再就是因為外部環境的影響產生了需求變更，就導致說你必須去修改以前的代碼，有的時候甚至需要修改以前代碼的架構。

這個時候問題就產生了，如果你的代碼不是一個方便修改的狀態，你的每次修改有可能導致更多的bug。咱們常常說一句話，當你修改一個軟體缺陷的時候，你可能引入了5個到10個新的軟體缺陷。需求的變更和缺陷的修補都有可能帶來質量的進一步下降，於是發現隨著時間的增長，我們的整個生產力一直在往下跌。

對整潔的理解

Uncle Bob提出整潔代碼這麼一個概念，從這幾本書的情況綜合來看，不是說光提整潔代碼，他也提到了整潔的架構，如何用敏捷的方法來實現整潔，也包括軟體開發者自身素質的提升，如何提升我們本身整潔的素質。

什麼是整潔代碼？整潔代碼一定是便於人類或者便於其他程式設計師閱讀的：

第一，能夠很方便的把它讀完

第二，能很方便的理解它

第三，很方便的修改它

我個人的意見，這就是整潔代碼裡頭最核心的三個要素，當你的代碼便於閱讀理解和修改，那麼代碼一定整潔。

當我們的代碼寫完之後，不再動它，這樣就結束了，完成了它的功能性的一方面就結束了。

但是，在更多的場景裡頭，代碼是需要被其他人，有的時候是自己過一段時間翻過來再看一遍，再去修改它。這很多時候是來自於業務的需求，這種業務需求的變更或者業務需求的增加導致代碼修改情況越來越頻繁的發生。

在這個時候，如果你的代碼不夠漂亮、不夠整潔，不具備方便修改的特性，那麼你會變得非常痛苦。

在這我還想再展開說一下，業務需求變更問題。在過去很多年裡頭，越往前，來自業務變更、需求變更的壓力會是越小的，那個時候我們整個軟體業界的做法都是你去做一個產品，寫出來，然後你能賣出去，不管是賣給企事業單位，或者說賣給大眾，編譯之後，那你這個版本就算完成了。

越往後面，這件事情就變得不一樣。尤其是到了現在這個時代，尤其是做To B、To G的業務，就可以發現很痛苦，為什麼痛苦呢？需求永遠在變更。當你做一個To C產品的時候，你可以按版本去做你的規劃，但做To B、To G，上業務的時候就會很鬱悶了，因為客戶不會試圖理解你關於版本的想法，而是不斷要求按照他們的想法來做更改。

還有一個點，傳統做To B、To G的時候，你還可以說我交付一個版本之後就結束了。現在有一個新的趨勢，政府和企事業單位會傾向於不做一次性採購，而是用租賃或者長期服務的方式來購買這個服務。

這樣子一個業務模式帶來很嚴重的後果，意味著程式設計師每天都有可能應付新增的需求或者更改，這就讓我們的項目組、程式設計師痛苦。尤其是在代碼不夠整潔的時候，你的代碼寫完了，你交付完了之後，客戶說你給我改改這吧，拿過來這個需求一看。我們先說一個小的更改吧，你改一個小的地方，發現有5個到10個bug突然出現了，你就不知道該怎麼弄。

有的時候涉及到價格上面的更改，你都不知道從何改起，這都是現實中我們會遇到的狀況。從業務的方向來理解，這個狀況會越來越頻繁。

敏捷和整潔的關係

第一個點，我認為敏捷不會讓項目更快。之前大家都會有一個很大的誤區，在相關企業裡面，可能老闆引入敏捷的目的是希望讓項目變得更快，或者讓我們的軟體開發變得更快捷，這是一個極大的思考誤區。

為什麼呢？在整個敏捷開發裡面，你會做在傳統軟體開發過程當中不會做的事情，這些事情在老闆的觀念來看有可能是毫無意義的。

敏捷真正的目的是說讓項目變得可控，就是你能夠知道項目的進展是怎麼樣子的，這是我的一個觀點。

但是寫整潔代碼不見得讓項目更慢，而且越往項目中期、晚期去，甚至到第二版、第三版進展的時候，越整潔的代碼會讓你的項目或者讓你的開發更快。

第二個點，變化一定是會發生的，不變化的情況非常少，這個變化來自於外部的一些影響。為了變化的發生，你一定要做好響應準備，從很多層面都要去做到響應準備，後面我也談到了業務層面的準備。

代碼從架構到每一類、每一函數，甚至到每一行代碼，這個響應準備是隨時要有的，如果你沒有做好相應準備，面對既定會發生的變化的時候，你就會措手不及。

軟體的根本目的還是為人服務，為人服務的前提是說軟體的質量一定是高的，軟體一定是根據人的需求變化而變化的。

第三個點，這也是很重要的，在過去一些年裡頭我一直在思考的。前些年我記得網絡上有討論，有一派觀點認為代碼的注釋是沒有必要的，因為代碼本身就要讓他寫的足夠有說明性，另一派認為代碼注釋非常有必要，因為再有說明性的代碼你都不能夠講的足夠清楚，用人的語言講的足夠清楚。

從我個人的觀點來看，注釋的必要性也許是存在的，但是如果我以注釋為藉口，而不把代碼寫的可讀，這絕對是不可以接受的。代碼本身必須具有足夠的說明性，包括它對應的單元測試，其實證明自己說能夠修改。

我現在越來越認為，整潔是敏捷開發的結果。敏捷開發貫徹的越徹底，對代碼整潔度的要求就會越高，因為代碼整潔是敏捷開發的一個基本要素。

未來軟體行業的發展

我覺得未來會發生的趨勢是什麼呢？未來所有的工作都會更加的社會化和去力度化。

過去幾個月以來，因為疫情的影響，很多人在家上班，也有研究指出，在家上班的效率也許是更高的。我們當然不去說生活跟工作混同這個問題，這個先撇開不說。在未來，我相信各個商業機構也會發現這樣一個情況，當我的員工在家裡工作效率沒有特別變低，甚至更高的時候，我是不是有必要每天把大家放到一起來。

當員工在家也能夠做事情的時候，那麼這個員工是不是非得是我的僱員，我認為這個變化很快就會出現，以後極有可能說我們會通過各種各樣的社會服務來實現軟體的整合。

在這個過程當中，每個人提供的服務就會更加的個體化，我們服務力度會變小，每個人提供微小的服務，這些微小的服務如果放在軟體開發的情況裡面來看，就變成一家公司。

這些程式設計師一定是遵循某種敏捷的模式，而且他的代碼一定是整潔的，一定去符合一個持續提升的觀念。當其中任何一小部分程式設計師發生變化的時候，一定有新的人員可以方便來接入。

在這個變化的大趨勢裡面，我認為整潔代碼將會為軟體從業人員，尤其是程式設計師，讓你具備一個適應變化的基礎能力，千萬不要覺得說代碼寫的快就好，未來一定是持續交付的，在持續交付的環境裡面你能不能去適應，我想這是給我們最大的一個啟發吧。

2 文武雙全，方為正道

分享嘉賓：餘晟

長期在網際網路行業尤其是後端開發領域打拼，經歷了從個人貢獻者到團隊領導者的轉變，對技術的價值和定位也形成了自己的看法。業餘時間寫作、翻譯、審校了若干技術圖書，對技術文化建設方面也有一些經驗。《代碼整潔之道:程式設計師的職業素養》譯者。

觀點提要：餘晟老師以自身經驗出發，講到程式設計師的「文武之道」，從追求專業性、不隨便承諾、敢於拒絕等方面深入講解了一個程式設計師應有的職業素養。

主題由來

這個主題來自於我自己很長工作以後，對經驗的總結和感悟——把自己定位為一個能寫代碼的管理者。

「武」其實是非常容易理解的，就是我們說的硬功夫，你編碼有多快。而關於「文」的方面，很長時間之內其實是被程式設計師所排斥，或者內心是有所牴觸的。翻譯了Uncle Bob《Clean Coder》這本書之後，我才開始慢慢意識到我們必須要做一個文武雙全的程式設計師，這對我們的職業發展是非常重要的。

程式設計師應有的職業素養

企業讓程式設計師以代碼為工具，運用數據結構和算法去開發系統，最終創造價值。

這樣的過程中，整個價值鏈中間還有幾個更重要的因素，第一個是企業，第二個是創造價值，程式設計師的工作是在這樣一個大的視角裡面才能夠真正的體現出價值。

1、專業對於程式設計師來說非常重要

這本書強調的第一點，專業對於程式設計師來說非常重要。你越會編程，你的系統越複雜，你的能力越強大，對於外人來講，對你的不安全感也就越深，也就越強。

這個時候只有你體現出足夠的專業素養，你才能夠跟更多的人合作，你才能夠贏得更多的機會，你也才可以得到更大的利益，這一點是我希望所有做開發的朋友都應該要意識到的。

2、內心要有對專業的追求

我也看到很多程式設計師吐槽，說培訓機構或者怎麼樣怎麼樣的人，他們能寫代碼，就來搶我們的飯碗了；或者希望能夠保持當前的水平、當前的收入就ok了，沒有更多的追求，所以當你提高對他的要求的時候，他會覺得不值，覺得沒有意義。

我想說的是，隨著你工作時間的增長，只要你內心對專業有追求，你的專業素質在不斷提升，你的競爭力就不會受到影響，所以我們內心一定要有對專業的追求。

Uncle Bob在這本書裡面也講到了，你一周如果工作40個小時，那你至少是要投入其它的20個小時來提升自己的專業素養。

一周工作只有40個小時，對很多人來講是奢望，但是我仍然希望大家能夠多出足夠的時間，來尊重自己的專業，花足夠的時間來追求自己的專業。

3、不隨便承諾，承諾必須靠譜

程式設計師怎麼估算工期呢，其實是一個非常簡單的事情，就是你讓經驗最豐富的程式設計師，你問他說做這個事情要多長時間，比如說他說18個月，你得出來的結論是18個月乘以2，就是36個月，然後再加兩個月就是38個月，這38個月大概是一個比較靠譜的估計，這充分說明了我們程式設計師承諾的可靠程度是什麼樣的。

還有關於質量的判斷，程式設計師交付出去的很多東西，說做好了、做完了，這個「完」其實是非常廣泛的描述，有的人說的做完是代碼寫完了，有的人說的做完是測試做完了，有的人說的做完是能夠部署了，還有的人說做完是確實能夠上線，沒有問題了。

Uncle Bob在這本書裡面強調的是說，我們如果要做一個專業的程式設計師，我們就不要隨便承諾，當我們說做完的時候就真的是做完了，這個東西可以交付了，而且可以上線了，完全沒有問題了，達到用戶能夠正常使用的程度，你才能夠叫做完，否則你的承諾就是不靠譜的，一旦你的承諾不靠譜，你的專業形象就會受到影響。

他還專門提到了一個東西，就是不要隨便說試試看。我知道說試試看的時候，程式設計師表達的意思是說大概能做成，大概也做不成。但是對於外人來講，對於跟你合作的不懂技術的這些人來說，他認為有80%-90%的機率是能夠做成的，所以我們一定不要隨便說試試看，說可以就可以，說不可以就不可以。

4、敢於拒絕

別人提了一個需求，你拒絕的時候，很可能爭論的焦點就會變成你到底有沒有本事。很多人會不願意承認說我能力不到位，我沒有這個本事，於是他就會把這個問題接下來，或者至少他不會當面拒絕。一旦你沒有明確的拒絕，對其他人來說就意味著你同意了。

這樣的同意，其實本身就蘊含了非常多的矛盾和衝突，這也是後來非常多的衝突，包括矛盾發生的根源。

所以，對於程式設計師來講，你一定要有明確的概念，就是說我敢於拒絕，這個東西我不做，不應該做，我們不要做這樣的事情。

又很多人在問怎麼樣說不呢？我沒有辦法說服其他人說不行，雖然我知道這樣做不行，但是我沒有辦法說服其他人。

這點就引申出來Uncle Bob講的下面一點，對於程式設計師來講，理解業務其實是我們終極的追求。

一旦你能夠站到業務的角度，一旦你能夠從利益的格局裡面去看待你的工作，你就會掌握更多的話語權，所以我希望大家能夠充分的意識到這一點，遇到溝通困難的時候不要縮回去，你要勇敢去理解義務，然後你才真正能夠獲得更多的話語權。

3 正本清源：Bob大叔欲對敏捷行業清理門戶

分享嘉賓：申健

優普豐敏捷學院首席敏捷教練，自2007年開始敏捷實戰。國際Scrum聯盟CST培訓師和CTC認證教練，極限編程實踐者。擅長結合教練技術等軟技能助力金融、通信、網際網路企業進行敏捷轉型諮詢和落地。《敏捷整潔之道:正本清源》譯者。

觀點提要：申健老師以「Bob大叔對敏捷清理門戶」這樣極具話題性的主題，展開講解了人們對敏捷的誤解，批判了大型偽敏捷，最後給出了敏捷在企業落地的建議。

主題由來

敏捷這個概念太火了，吸引了方方面面的人進來，傳統的諮詢行業，一些賣工具的都來了，都打著敏捷的旗號，把這個行業就搞亂了。

所以Uncle Bob在這本書裡講了業務實踐、技術實踐、團隊實踐，然後告訴大家我們本來的敏捷是怎麼回事，不是你現在賣的那套東西。

對敏捷的誤區

對敏捷最大的一個誤區——敏捷就是快，用了敏捷以後，原來3個月的項目，我現在一個月就能做出來，那都是不可能的，那都是騙子。

敏捷其實是想要打破原有傳統的瀑布式工作方法，以前很多公司的項目開發流程都是先做需求，把需求都搞清楚，再做開發，然後再做測試，然後再做上線。

你會發現這個方式並不適合於軟體開發這種智力型的、創造型的行業，早在1970年，這個人叫Winston Royce，他寫了一篇文章，批判階段性Gate based process，說這個方式不適合，結果瀑布模型流傳到現在，很多公司，包括我們一些客戶的公司仍然還是這樣一個開發模式。再加上2000年左右，由於CMMI傳入中國，不能說它們沒有作用，當時可能是對中國的軟體工程行業也起了一些作用，但是逐漸就演化成一種企業自治的一種方式，諮詢師跟評估師串通一氣，給你刷一個證，最後發現能力完全還是沒有提高。

在現實中，人們對敏捷現在還有其它的期望。

第一，我抄。我沒有什麼創新能力，但是我抄競品，比比皆是。Uncle Bob說了，敏捷不見得能幫你少花時間，只是能讓你該去抄哪，你抄作業得抄對了吧。

第二，少招點人，資源利用率提高點，這也沒有錯，但敏捷不見得能幫你提高產能，只是能增加一些可管理性，可管理性來自於哪呢？來自於透明性，信息可視化、透明性，然後你才有機會做檢視和調整。你如果信息不夠透明，你也沒有機會檢視、調整。

第三，按時上線。按時上線當然也挺重要，但是敏捷不見得能幫你確保時間，它只是摧毀你不切實際的幻想。什麼叫不切實際的幻想？就是我到每個時間點，我想要的東西都能上去，不太可能，即使都上去了，通常你也會得到程式設計師的偷工減料，因為程式設計師都是高智商人士，他們是非常清楚如何偷工減料，所以你逼他，他就會給你採取那些辦法。

第四，營業額。用了之後，我的經營業績是不是能提升，營業額增加了，客戶量也增加了。恐怕不行，敏捷只是能讓你更早的知道你哪個產品方向行不通，但是並沒有辦法讓你知道你哪個方向能夠行得通。

而且敏捷是一套工作方法，它能夠助力你業務功能上線、交付，但是它與營業額、用戶量或者錢的增加，並沒有直接的關聯關係。

最後要講的一點，不管是極限編程還是Scrum，他們都是一些框架和實踐集。但我們很多客戶想要落地，要的是敏捷轉型或者叫變革管理，這是正交的兩回事。在這裡先放一句，你要分成兩個角度去看，實踐集放在那裡，但是我們怎麼走過去，這是另外一回事。

不管是哪種方法，都是通過一種叫做加速反饋機制來破解複雜性，為什麼要敏捷？大家常見的需求經常變更、軟體質量差、可維護性差，導致項目失敗率。

首先他們講需求沒有不變，因為業務就是在變的，因為市場是在變的，所以不要幻想說我代碼能夠整整齊齊寫乾淨，然後放在那裡供起來，這是不可能的。

第二個就是你的團隊、人員、資源能力是一個動態的變化，人員有流動，今天走倆，明天來倆，太正常了。這個敏捷就靠什麼呢？就是我們走一步看一步吧，「天下難事必作於易，天下大事必作於細」，你把困難的事拆成簡單的，大事拆小，才能夠去應對，敏捷裡面就能把大的組織拆成小團隊，把大的產品需求拆細，拆成用戶故事，拆成小任務，把大的時間周期拆成小的、迭代的周期，然後把代碼也寫的越小越好，都是在破解複雜性，就是反饋機制才是敏捷的根本。

批判大型偽敏捷

市面上有一些方法論，號稱叫規模化敏捷，套了一個敏捷的帽子，其實就是原來的瀑布改了名字，仍然是一個傳統的矩陣結構，這是一種誤區。

還有人說敏捷宣言沒區分IT敏捷還是業務敏捷，他就沒搞明白，IT敏捷和業務敏捷之間是不是一回事，IT敏捷是幹什麼的，軟體開發敏捷是怎麼達到的，是通過屏蔽驗證達到的，把代碼寫清楚，然後通過咱們講的持續集成、開發迭代，去看跟需求方講的是不是一樣的，是不是人家要的。

業務敏捷是什麼？你的訴求是說我的公司能夠在市場環境裡面增強能力，聽起來沒錯，但是業務方向，戰略上其實不一定是通過迭代來進行或者達成的，它可能是通過資源交換來達成，另外它可能是通過廣撒網來達成，所謂廣撒網就是我孵化好幾個業務方向，我看哪個行我就做哪個，像騰訊叫賽馬機制。

Martin Fowler當然也是極限編程，和Uncle Bob一樣，是極限編程的發起人或者是主要成員之一。他們都在噴SAFe的一個所謂規模化敏捷的東西，包括敏捷宣言其他創始人都對這個東西Say No，說這個東西根本就不是敏捷，套上敏捷的帽子來騙人。

Uncle Bob在《敏捷整潔之道》這本書裡講了一句話，他說敏捷是解決小團隊的問題，不是解決大團隊的問題，他說大團隊、大項目的應對之道，幾十年前就已經解決了，怎麼解決？咱們講的矩陣式結構、層級式結構，這就是解決之道。事情分解，已經解決了，但是小團隊如何協作的問題沒解決，這是提出敏捷的原因。

敏捷在企業的落地

所謂敏捷規模化，在大型產品裡面多團隊合作、多人合作的時候，解除依賴才是敏捷應對之法。

架構怎麼組，不是說我畫一個所謂的規模化敏捷圖形架構問題就解決了，他一定是靠不斷的溝通，跨團隊的協調機制，你放一個集中化的架構團隊架構師，仍然解決不了這個問題。

剩下還有一些組織的轉型、組織障礙的移出、內部社區等等還有自動化測試這事怎麼做，都知道自動化測試好，都知道重構好，大型遺留代碼，幾年甚至十幾年留下來的，想補，別說想補重構，補自動化測試，你看都看不懂，人員流動你看都看不懂，你怎麼補，所以這也有一個策略的問題。

另外就是績效考評，這個在企業中是繞不開的，敏捷方法，各個方法都沒有提到說應該怎麼考評，那我覺得績效考評根本也不是敏捷要去直接解決的問題，他就是看你公司的導向，你想公司業績是什麼樣的或者工作方法像什麼，你就考核什麼就行了。

另外還有一些配套的事情，包括我們給一些企業做落地轉型，發現產品經理能力不行，或者BA需求分析能力不行，就是編程基本功的問題，最後都會落到基本功的問題，你就是不會，你用什麼方法論他也做不出來。

程式設計師的基本功寫代碼，你知道程式設計師最頭疼的事就是起名字，再加上英語不好，業務領域知識不知道，就只能起到像Run、Process、Handle等等這個水平。Uncle Bob在之前的一本書也提到你要想知道代碼質量的好壞，就是數數這個程式設計師在閱讀別人的代碼時心裡罵了多少次WTF。

怎麼練基本功，Uncle Bob提出來極限編程，現在市面上其實也有一些練基本功的培養的方式，包括線上線下的基本功練習，程式設計師練功房、工具箱練功房等等，Scrum聯盟他有一個CST的課程也是在講這些極限編程手藝，還有一些朋友在做直播，直播就是寫代碼，直播做重構，直播給你講集成，這些都是值得大家去參考的一些資源。

另外還有敏捷合同，敏捷合同像Scale Lam等等給出了一些合同的思考和模板，因為你如果像傳統像項目管理籤的這種合同，時間範圍成本都定死了，當不可避免的需求到來的時候，你就沒有任何變化的餘地，所以敏捷合同籤署也是有一定學問的。

最後是教練式的領導力，這個特別有意思，在Clean Agile這本書裡面，Uncle Bob除了講團隊實踐、基礎實踐和業務實踐之外，特意開了一章講敏捷教練的事情，我理解他以前這些事情管理的東西其實不是特別在意，但是現在隨著敏捷教練行業的興起，他也提出了一些自己的想法。

我們知道市面上比較流行的敏捷教練的入門學習可能就是美國Scrum聯盟CSM培訓認證，但是上了這麼一個課並不代表你對敏捷有了了解，只是一個入門。再往上就是要真正成為一個敏捷教練要發展自己的軟技能，軟技能通常指Patient會議引導的技巧，還有coaching教練式對話的技巧，包括教練式領導力的技巧才是幫助人們慢慢去轉變的一個方式。

總結一下，用Uncle Bob這句話說，敏捷是一種幫助小團隊運作小項目的小方法，任何大項目都是由若干小項目組成的。所以以小見大，夢想要大，步子要小，別總扯什麼大型敏捷，大型諮詢，沒有用，先把小團隊運作好了，然後慢慢暴露組織中的組織結構問題，互相依賴的問題，去推進整個組織或者更大範圍的轉變才是正道，上來就想搞一個大型敏捷框架也好，實踐也好，往上一套基本上就是輸在起跑線上了。

所以我也奉勸行業中的各位敏捷教練，包括我們自己，一起共勉。還是先把小團隊的敏捷之道搞好，如果丟了代碼年頭太多，想法拾起來，如果沒有任何代碼基礎，給別人做敏捷諮詢的話，最好先學學潘石屹，了解一下程式設計師的工作情況才能更好的理解敏捷到底是怎麼一回事。我想分享的內容就這麼多。

-END-