Clean Code：童子軍規則

評估開放原始碼程式庫的要素之一，是專案的活躍度，而活躍度的參考指標之一在於，作者是否經常對程式庫進行維護，更具體地說，程式庫提交（commit）的頻率。就我而言，找到一個程式庫時，總是會看一下它最近一次受到提交是什麼時候。

如果開發者手邊有個開放原始碼專案，想讓使用者知道他關心這個專案，該怎麼維持這種活躍度呢？由於手邊也有著dotSCAD/cqMore等開放原始碼專案，我經常在思考這個問題！

臭蟲修正？這不是想找就找得到！持續加點新特性？為了加新特性而加，只會令程式庫失焦，硬寫出來的功能也不見得好用，可能只是增加日後維護的麻煩！

童子軍規則／無情重構

維護程式庫終究要有目標，然而，其實不需要什麼太遠大的目標，我們只要遵循《Clean Code》第一章所提到的童子軍規則（The Boy Scout Rule）：「離開營地前，讓營地比使用前更加乾淨。（Always leave the campground cleaner than you found it.）」每次打開專案，我們就試著找個地方整理一下，讓程式碼的品質好上那麼一點點，就可以了。

Bob大叔認為，童子軍規則是個專業主義的象徵，在《The Clean Coder》第一章再度提到這個規則，並且進一步地闡釋「想要證明軟體易於修改，唯一的辦法就是『做些實際的修改』」，這種策略有時被稱為Merciless refactoring。

Merciless有殘酷無情之意，Merciless refactoring也就常翻譯為「無情重構」，這聽來有點嚇人，不過，這裡的merciless比較像是無心、無意，不用有太多情懷，做這類重構不需要設想太多的意思，單純就是離開前讓原始碼乾淨一些。

這是因為重構常給予人需要特定目標、手法，如果沒有足夠的經驗，沒能嗅出程式碼的餿味、沒對專案架構有一定認識，就別輕易動手的感覺；然而所謂的無情重構，希望的是沒經驗的開發者，也能輕易實現，持續、點滴地改進程式碼的品質，從而讓後續的程式碼修改變得簡單。

面對原始碼的童子軍

身為開發者，或多或少可能都學習過一些關於重構訊號、目標與手法的知識，應該知道一些整潔程式碼該有的樣子，但是，我們實行童子軍原則時，不見得每次都是以消除程式碼餿味、增加程式碼整潔為目標。

別的不說，就算是重新命名變數或函式，來增加程式碼的可讀性，其實，也是滿難的一件事不是嗎？畢竟它是程式設計師九大難題之首呢！

開發者只要找一段感興趣的原始碼，看懂它，然後有個修改的簡單理由，就可以了。最好是腦袋中一閃而過的想法，就算只是簡單地調整排版，也無所謂，就算排版只是做一點縮排，或按個換行，也沒問題。只要那些修改動作，是開發者看懂程式碼之後的想法、第一時間想做出的調整，就可以了，而在我們提交程式碼的訊息當中，寫明僅是做個排版，也就可以了。

可別小看縮排！這其實意謂著開發者理解到程式碼中，有個不同或相同的層次。

也別小看換行！這可能意謂著理解到這邊是一個子任務的結束、另一個子任務的開始。

就我個人的經驗而言，往往是在累積了一些程式碼排版的提交之後，而逐漸發現到有些可以抽取或合併的程式碼，或者進行資料結構封裝、架構調整之類重構的可能性。

簡而言之，「童子軍規則」的重點在於，為了在離開前，讓原始碼比使用前更加乾淨，開發者必須先讀通程式碼，就算只是一小段，也有了重新檢視、修改原始碼的機會。

修改的動機也可以是除舊佈新，像是知道了專案環境可以使用某個新語法、新特性、原生函式，可以在閱讀原始碼時，順手更新，移除一些過時的實作或被廢棄的特性等。

當然，如果對重構的訊號、整潔程式碼的樣貌擁有相當的經驗與心得，儘管去運用相關手法，在離開前清理原始碼，也是沒問題的！

面對專案的童子軍

有時讀完一些原始碼後，開發者可能還是沒有想法，這時該怎麼辦？雖然Bob大叔提及的童子軍原則，基本上，是針對程式碼的整潔，不過，施行對象其實可以不限於原始碼本身，也可以是對整個專案品質有助益的整理，例如文件、範例程式碼或測試等。

這令我想到許多開發者不愛寫文件，確實地，寫文件有時枯燥乏味，特別是撰寫API文件，而避免乏味的方式之一是，為API文件加入一些範例程式碼，這是強制從開發者的角度脫離，改從使用者的角度來看待API的方式，以便從實際文件撰寫、範例設計中，察覺API的設計是否合理、易於使用、有無彈性等，如果在設計範例程式碼時覺得麻煩，改進API設計就會是下次促進專案品質的目標之一。

另一方面，撰寫文件、設計範例程式碼，其實就是實行測試的另一種形式，因為在撰寫文件或範例的過程中，我們往往可以發現臭蟲或者效能等問題，這實就有了檢視、修改程式碼的機會。

因為有了文件、範例程式碼，下次在實現童子軍原則時，若真的沒想法，那就補點測試吧！我們可以將先前撰寫的文件、範例作為測試案例的來源，令其成為自動化測試的一部份。

有了文件、範例程式碼與更多的測試作為基礎，開發者面對專案本身的原始碼時，就更有信心去實現童子軍原則，而不用怕修改之後，破壞了什麼！

童子軍原則也可以套用在文件與範例，畢竟它們也是需要維護的對象，因為過時的文件與範例比沒有這些資訊還糟糕，所以，我們如果面對專案本身的原始碼真的沒什麼想法，那就去整理文件與範例，修正一些過時的東西、改幾個字詞、增減一些描述或純潤飾等都好。別忘了！童子軍原則也常被稱為Merciless refactoring，實行時不要設想太多。

童子軍規則的效益

Bob大叔說大多數人對軟體的理解是「修改是危險的」，其實正好相反，為了證明軟體易於修改，就要避免讓程式碼保持不變，只有修改才能發覺不易修改的設計，從而改進設計，讓修改變得容易，這是時時實行童子軍規則的效益之一。

開發者越是不改程式碼，就越來越不敢改，然後新功能只基於這些不想改的程式碼，持續地堆疊上去，有一天就會像Bob大叔說的：「不得不重構時，就會發現程式碼已經僵化了」。

就我的經驗而言，另一個效益是，實現童子軍規則，其實是在時刻閱讀、修改原始碼過程中，維持對專案的熟悉度，而且，效益會在持續累積熟悉度後逐漸呈現並擴大，當專案的品質與自身的熟悉度都到達一定程度，有些過去難以解決的難題，解決的方案可能會突然變得清晰，這時對專案往往會產生全新的目標與想法。

總體而言，我們在維護開放原始碼上若能實行童子軍規則，就可以讓專案維持著一定的提交頻率，而且並非灌水。這表示除了臭蟲修正、新增特性等之外，開發者也關心專案的其他品質，這些都會反映在提交記錄上，顯示出童子軍每次離開營地前的整理提交，都是具有意義的！