本文摘自敏捷開發(fā)。

Robert C. Martin（?羅伯特·C·馬?。?，作為世界級軟件開發(fā)大師、設(shè)計模式和敏捷開發(fā)先驅(qū)、C++ Report雜志前主編，也是敏捷聯(lián)盟（Agile Alliance）的第一任主席，我們尊稱他為“?Bob 大叔（Uncle Bob）”。

如今，年逾六十的 Bob 大叔過著典型的“斜杠”生活，他不僅是優(yōu)秀的程序員、暢銷書作家、演講家，以及視頻制作者，還是一名柔術(shù)愛好者。?多年學(xué)習(xí)柔術(shù)的經(jīng)歷，帶給他的除了強健的身體之外，還有從中受到的有關(guān)“匠藝”的熏陶。他經(jīng)常受邀去各地進行演講，向當(dāng)下年輕一代的程序員們分享他所理解的敏捷?，F(xiàn)在，Bob 大叔也常常在 Twitter 的賬號（@Uncle Bob Martin）以及個人網(wǎng)站（cleancoder.com）上發(fā)表自己的觀點、文章。

Bob 大叔認為，?敏捷不是?項目管理方法，而是一套價值觀和紀(jì)律，可以幫助相對較小的團隊構(gòu)建中小型產(chǎn)品。這一觀點的提出源于他無數(shù)次的親身項目實踐。

瀑布開發(fā)之旅

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

為了縮短開發(fā)過程中反饋的時間，瀑布模型應(yīng)運而生。該模型很好地解決了生產(chǎn)效率問題，并在70、80年代間迅速地占據(jù)了軟件開發(fā)的大半江山，Bob 及其團隊也開始了“瀑布開發(fā)”之旅。

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

故事到這里還沒有結(jié)束，偶然一天，Bob 見到了那家公司的員工，才從這名員工的口中得知整個事情的前因后果：當(dāng)時公司為了推動產(chǎn)品提早發(fā)布，非但沒有重視代碼質(zhì)量，還一味地追求速度，導(dǎo)致員工代碼寫得亂七八糟，無法進行修改或管理，最終公司經(jīng)營慘淡，宣布倒閉?！扒Ю镏?，潰于蟻穴?！睆倪@一事件中，Bob 得出一個結(jié)論：代碼的整潔是需要引起重視的。他認為，?軟件質(zhì)量不僅依賴軟件架構(gòu)及項目管理，還與代碼質(zhì)量緊密相關(guān)。

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

敏捷開發(fā)的萌芽

20世紀(jì)90年代初，敏捷先驅(qū)們陸續(xù)發(fā)布了關(guān)于 Scrum 的文章。Bob 接收到這一變革的信號后，突然有種預(yù)感：?團隊可以嘗試一種新方式了。這一預(yù)感在他偶然接觸到 Kent Beck 關(guān)于極限編程的著作之后成真了。Bob 先后幾次拜訪 Kent，從他那里深入了解了極限編程（XP），并嘗試了測試驅(qū)動開發(fā)（Test-Dreven Development，TDD）。這才發(fā)現(xiàn)，原來在面向?qū)ο蟮沫h(huán)境中可以應(yīng)用這樣的流程，原來一套可以信任的測試能夠使代碼修改變得異常簡單。當(dāng)他覺得團隊完全可以在開發(fā)流程中，簡單并安全地修整代碼的時候，就無法再接受爛代碼了。

受此啟發(fā)，Bob 想圍繞代碼整潔和極限編程創(chuàng)建一個非營利組織，但這一想法在當(dāng)時并未得到大多數(shù)人的認可。于是到2000年秋天，Bob 又提出了一個想法：?讓相互競爭的輕量級流程倡導(dǎo)者聚集在一起，形成一個統(tǒng)一的宣言。這個想法得到了 Martin Fowler 的大力支持，兩人一拍即合，著手準(zhǔn)備會議的前期籌備工作。在籌備的后期，又加入了一名意向者——Alistair Cockburn，Alistair 的加入使這次的會議準(zhǔn)備更加完備，并將會議地點定在雪鳥滑雪場，這樣，雪鳥會議就被安排好了。

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

但這并不意味著 Bob 放棄了“代碼整潔”。2010年，Bob 出版了《代碼整潔之道》一書，他在書中正式提出“?代碼質(zhì)量與其整潔度成正比”的觀點。這本書一經(jīng)面世，就在軟件開發(fā)行業(yè)掀起了軒然大波??！按a整潔”認為，整潔的代碼是自解釋的，閱讀代碼應(yīng)該如同閱讀一篇優(yōu)秀的文章，見字知意，能夠一下子明白大概的代碼功能。代碼首先要能讀懂，其次才去要求功能實現(xiàn)，這一理念得到了數(shù)百萬程序員的追捧。Bob 大叔堅信，工作保證速度與質(zhì)量的唯一方法：盡可能地保持代碼整潔。很快，這個唯一的方法就不那么靈驗了。

貫徹“匠藝精神”

人們好像又陷入了一種誤區(qū)：只要實施敏捷、做好代碼規(guī)范就一定能給軟件項目帶來明顯改善。在這一誤區(qū)里，人們離真正的敏捷越來越遠。2016年，Bob 出版《代碼整潔之道：程序員的職業(yè)修養(yǎng)》一書，引導(dǎo)讀者認識到專業(yè)程序員肩負的責(zé)任重大，闡述了什么才是程序員的職業(yè)素養(yǎng)。此外，Bob 將“代碼整潔”在原有基礎(chǔ)上擴充了一番：整整30年，大家一直受困于“用大團隊干大事”的觀念，根本不知道成功的秘訣其實在于用很多小團隊解決很多小問題，而這就需要每個程序員具備“匠藝精神”，從而引導(dǎo)開發(fā)人員回歸真正的敏捷。

“匠藝精神”是指開發(fā)人員不再把工作當(dāng)作簡單的上班打卡，而是基于把事情做好的渴望，來提供專業(yè)的服務(wù)。Bob 提出的“匠藝精神”將關(guān)注點聚焦到了開發(fā)人員身上，并得到了很多開發(fā)人員的支持。為了提高軟件開發(fā)的水準(zhǔn)，并重新明確敏捷最初的目標(biāo)，一群開發(fā)人員于2008年11月聚集到芝加哥，發(fā)起了一個新的運動：?軟件匠藝（Software Craftsmanship），并形成了一套核心價值觀。

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

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