敏捷史話（六）：也許這個人能拯救你的程式碼 —— Robert C. Martin

Robert C. Martin（  羅伯特·C·馬丁），作為世界級軟體開發大師、設計模式和敏捷開發先驅、C++ Report雜誌前主編，也是敏捷聯盟（Agile Alliance）的第一任主席，我們尊稱他為“  Bob 大叔（Uncle Bob）”。

如今，年逾六十的 Bob 大叔過著典型的“斜槓”生活，他不僅是優秀的程式設計師、暢銷書作家、演講家，以及影片製作者，還是一名柔術愛好者。  多年學習柔術的經歷，帶給他的除了強健的身體之外，還有從中受到的有關“匠藝”的薰陶。他經常受邀去各地進行演講，向當下年輕一代的程式設計師們分享他所理解的敏捷。現在，Bob 大叔也常常在 Twitter 的賬號（@Uncle Bob Martin）以及個人網站（cleancoder.com）上發表自己的觀點、文章。

Bob 大叔認為，  敏捷不是專案管理方法，而是一套價值觀和紀律，可以幫助相對較小的團隊構建中小型產品。這一觀點的提出源於他無數次的親身專案實踐。

瀑布開發之旅

1970年，18歲的 Bob 在一家名為 A.S.C.Tabulating 公司做程式設計師，起初寫程式碼的時候，Bob 及其團隊度過了一段艱難的日子。當時的工作是劃分白班和夜班的，白班時，程式設計師先用鉛筆把程式碼寫在編碼表格上，然後用打孔機在卡片上打孔，把仔細檢查過的卡片交給計算機操作員，操作員則在夜班時進行編譯和測試。但這一番操作下來，通常會花費幾天的時間，且之後的每一輪修改都會花費大約一天的時間，團隊就在日復一日地編碼、編譯、測試、修復 Bug。這種開發模式在當時尤為普遍，因此生產效率低下的問題亟待解決。

為了縮短開發過程中反饋的時間，瀑布模型應運而生 。該模型很好地解決了生產效率問題，並在70、80年代間迅速地佔據了軟體開發的大半江山，Bob 及其團隊也開始了“瀑布開發”之旅。

但是想象中精細的計劃、完美的策略所打造的卓越成果並沒有出現，Bob 只能重新尋找能真正符合他期許的開發流程。在尋找過程中，35歲的 Bob 與搭檔 Jim Newkirk 相繼加入新的公司——Clear Communication，與此同時，有家公司寫了一個很流行的殺手應用，許多專業人士都買來用，這其中也包括 Bob。但令人感到失望的是，這一程式的釋出週期變得越來越長，Bug 開始積壓，載入的時間也越來越長，系統崩潰的機率也越來越大。最終，大多數使用者都選擇不再使用這個程式。果不其然，在那之後不久，該公司就關門大吉了。

故事到這裡還沒有結束，偶然一天，Bob 見到了那家公司的員工，才從這名員工的口中得知整個事情的前因後果：當時公司為了推動產品提早釋出，非但沒有重視程式碼質量，還一味地追求速度，導致員工程式碼寫得亂七八糟，無法進行修改或管理，最終公司經營慘淡，宣佈倒閉。“千里之堤，潰於蟻穴。”從這一事件中，Bob 得出一個結論：程式碼的整潔是需要引起重視的。他認為，  軟體質量不僅依賴軟體架構及專案管理，還與程式碼質量緊密相關 。

意識到程式碼整潔的重要性之後，Bob 心想，如果把瀑布模型與程式碼整潔結合在一起，那一定很完美。於是，在接下來很長的一段時間裡，他同團隊一起努力按照“  分析—設計—程式設計”的方式試圖實現產品交付。但這行不通。即使大家對程式碼整潔做出了規定，並且每次對需求的分析與設計非常正確，但一旦進入開發階段，事情就開始變得不可控了，最終的衝刺會再次打亂之前做好的全部計劃，導致產品交付不能如期進行。在一次一次的實踐過程中，Bob 逐漸發現瀑布開發束縛住了自己的思想。就在他覺得連程式碼整潔也拯救不了這混亂的流程的時候，敏捷開發初見苗頭。

敏捷開發的萌芽

20世紀90年代初，敏捷先驅們陸續釋出了關於 Scrum 的文章。Bob 接收到這一變革的訊號後，突然有種預感：  團隊可以嘗試一種新方式了。這一預感在他偶然接觸到 Kent Beck 關於極限程式設計的著作之後成真了。Bob 先後幾次拜訪 Kent，從他那裡深入瞭解了極限程式設計（XP），並嘗試了測試驅動開發（Test-Dreven Development，TDD）。這才發現，原來在物件導向的環境中可以應用這樣的流程，原來一套可以信任的測試能夠使程式碼修改變得異常簡單。當他覺得團隊完全可以在開發流程中，簡單並安全地修整程式碼的時候，就無法再接受爛程式碼了。

受此啟發，Bob 想圍繞程式碼整潔和極限程式設計建立一個非營利組織，但這一想法在當時並未得到大多數人的認可。於是到2000年秋天，Bob 又提出了一個想法：  讓相互競爭的輕量級流程倡導者聚集在一起，形成一個統一的宣言 。這個想法得到了 Martin Fowler 的大力支援，兩人一拍即合，著手準備會議的前期籌備工作。在籌備的後期，又加入了一名意向者——Alistair Cockburn，Alistair 的加入使這次的會議準備更加完備，並將會議地點定在雪鳥滑雪場，這樣，雪鳥會議就被安排好了。

這次的雪鳥會議歷時兩天，十七位不同流派的敏捷大師在阿斯彭會議室裡進行了長達兩天的討論，意在尋求所有輕量級過程和軟體開發的共同點，最終他們從  互動 、  軟體 、  協作 、  變化 等四個角度搭建出了敏捷價值觀及十二原則。但令人遺憾的是，為了求同存異，這次會議所簽署的《敏捷宣言》  並未對“如何程式設計”這一部分作過多的解釋，同樣沒有將 Bob 一直提倡的程式碼整潔納入 。

但這並不意味著 Bob 放棄了“程式碼整潔”。2010年，Bob 出版了《程式碼整潔之道》一書，他在書中正式提出“  程式碼質量與其整潔度成正比”的觀點。這本書一經面世，就在軟體開發行業掀起了軒然大波  。“程式碼整潔”認為，整潔的程式碼是自解釋的，閱讀程式碼應該如同閱讀一篇優秀的文章，見字知意，能夠一下子明白大概的程式碼功能。程式碼首先要能讀懂，其次才去要求功能實現，這一理念得到了數百萬程式設計師的追捧。Bob 大叔堅信，工作保證速度與質量的唯一方法：儘可能地保持程式碼整潔。很快，這個唯一的方法就不那麼靈驗了。

貫徹“匠藝精神”

人們好像又陷入了一種誤區：只要實施敏捷、做好程式碼規範就一定能給軟體專案帶來明顯改善。在這一誤區裡，人們離真正的敏捷越來越遠。2016年，Bob 出版《程式碼整潔之道：程式設計師的職業修養》一書，引導讀者認識到專業程式設計師肩負的責任重大，闡述了什麼才是程式設計師的職業素養。此外，Bob 將“程式碼整潔”在原有基礎上擴充了一番：整整30年，大家一直受困於“用大團隊幹大事”的觀念，根本不知道成功的秘訣其實在於用很多小團隊解決很多小問題，而這就需要每個程式設計師具備“匠藝精神”，從而引導開發人員迴歸真正的敏捷。

“匠藝精神”是指開發人員不再把工作當作簡單的上班打卡，而是基於把事情做好的渴望，來提供專業的服務。Bob 提出的“匠藝精神”將關注點聚焦到了開發人員身上，並得到了很多開發人員的支援。為了提高軟體開發的水準，並重新明確敏捷最初的目標，一群開發人員於2008年11月聚集到芝加哥，發起了一個新的運動：  軟體匠藝（Software Craftsmanship） ，並形成了一套核心價值觀。

許多開發人員對敏捷未來的發展方向感到失望，這是催生軟體匠藝運動的誘因之一 。一部分人覺得敏捷太過於業務，而另一部分人覺得匠藝太關注工程，因此認為敏捷與匠藝水火不容，但 Bob 大叔對此持相反觀點。不論是敏捷還是匠藝，本質都是為了交付高質量、有價值的工作，兩者缺一不可，68歲的 Bob 大叔如是說。2020年，為了引導新一代軟體開發者剛起步就把敏捷用對，他推出新作《敏捷整潔之道：迴歸本源》，幫助讀者理解敏捷價值觀與匠藝精神在敏捷團隊中的重要意義。

如今，我們的 Bob 大叔——Robert C. Martin，作為2001年在猶他州雪鳥小屋中推動雪球的十七人之一，他身體力行地維護著程式碼整潔。對程式設計擁有無盡熱情的他，也  開始嘗試推動敏捷和匠藝的攜手並進，從而修復業務與開發之間的鴻溝 。他的故事仍在繼續。