如果宇宙是按照必然的本質在運行，那麼非本質的偶然是否就應該被忽略的呢？近代科學的演進，告訴我們在宇宙必然性的背後，其實存在相對的隨機性。雖然宇宙在表相的物質巨觀層面上，似乎可以預測必然性，但在微觀的粒子層面上，卻是以我們很難理解的隨機方式在運作。

也就是說，事物的本質不見得是單一地存在，而是可能以多種完全不同的樣貌來呈現，甚至會看到客觀的本質與主觀的存在會產生相互的矛盾。特別是在最近在網路上的討論中，同人就很清楚地看到這樣的矛盾如此深刻地影響人們的想法與行為。

真實只有一個？

Dororo 說沒有「善」與「美」，「真」就不能稱之為真。同人認為不應該只用單一價值觀來否定另一種的價值觀，否則很容易造成偏頗，我相信我和 Dororo 只是彼此對「真」的定義不同。然而，她卻堅持即使定義不同，真實只有一個，它一直在那裡，不會有不同的標準，甚至批評提出不同觀點的同人只是活在自己創造的否定裡。

同人實在不懂我在什麼地方創造了自己的否定，難道只是因為主張「真」、「善」、「美」三種不同出發點要彼此尊重嗎？我實在很難相信這樣的批判是出自認同新時代理念的人。她這樣批評與她不同觀點的人，顯然已經陷入不是這個就是那個的暴政中，忽略了真理通常是既是這個，又是那個。就如同科學上的量子力學所揭露我們其實無法精確預知事物本然的真實狀態。

當你愈確定粒子的速度，粒子的位置就愈不可測，反之亦然。此為測不準原理。當你用粒子來觀察光，它就是粒子；當你用波來觀察光，它就是波。但如果光是粒子就不應該是波，是波就不應該為粒子，此為光的波粒二元性。所以對一件事我們如何能下如此絕對的定論？我們認為對的事情在別人眼裡中可能是錯的，根本沒辦法以單一的現象來評斷絕對的是非或對錯！

Dororo 應該是深受新時代觀念薰陶的朋友，但她卻那麼執著地用她的真實來否定他人的想法。同人認為她大概是忽略或是誤解奇蹟課程「凡真實必不受威脅」的意義。縱使在宇宙中存在堅定不移的真理，但同人相信這種最純粹的「至善意願」並不需要將意志力凌駕或強壓在不同層面的意識上。因為真理之所以是真理，是因為它的真實不虛，而非貶抑或排斥不同的觀念，這樣做只是對真理的扭曲而產生不容異己而產生幻象。

同人看到 Dororo 所堅信事物的本質與多元價值認同的存在產生矛盾，她選擇以排拒否定的方式來化解本質與存在的矛盾。代表她並沒有足夠的包容力來看「真」、「善」、「美」的三種不同語言的對話，以帶來思想、意志及情感的發展進程。真實只有一個的說法並不是錯誤，而是要因應不同存在實體創造屬於每個人獨特的本質。本質不拘於特定形式，它不只存在於理性的思想，也同樣存在於善念的意志與情感的感受之中，只在於你決定如何將它表現出來。

理性創造的奇跡

對於本質與存在的矛盾，同人感受比較深刻的是與 Zulu 的一段討論。在噗浪河道上，他引用韋納《控制論》的觀點，提到「任何一門科學的建立，都必須以非孤立現象的存在為前提。如果世界是由一個沒有理性的上帝所統治，他可以一陣心血來潮地作出一連串的奇跡，那麼，在這個世界裡，我們就要狼狽不堪地被迫等待每一個新災難的到來（韋納，控制論，p. 48）。」然後隨後提出評論：反過來說，自然現象符合數學真理本身就是一個最大的奇跡…對笛卡兒來說，這未必是不言而喻的。

同人懷疑「科學的建立必須以非孤立現象的存在為前提」的真確性，雖然以科學實證的精神來看，這樣的說法應該是無庸置疑的，但對於「孤立現象的存在」，我們能否能夠因為它與通過驗證的數學真理產生矛盾而否定它存在的可能性，並且認為世界存在非理性的奇跡，只會讓人們狼狽不堪地被迫等待災難的到來？其實科學無法證實的事物不見得代表它不存在，只能代表科學無法合理地解釋它的存在。同人認為因為無法證實孤立現象的存在而否定它，其實本身就是一種非理性的偏見。

以一般科學家所信奉實證主義來看，知名的宇宙物理學家史蒂芬霍金在《胡桃裡的宇宙》提到的科學實證的精神：

任何站得著腳的科學理論，不管研究的對象是時間或是其它概念，在我看來，應該都是根植於最實用的科學哲學：巴柏等哲學家所提出的實證主義。根據實證主義的看法，科學理論只是一個數學模型，其目的是描述並量化我們觀測到的現象。一個好的理論，能以少量假設當作基礎，描述大量的自然現象，並能做出明確的、可檢驗的預測。假如預測符合觀測結果，這個理論便通過這項檢驗，但我們永遠無法證明它是正確的。

另一方面，假如觀測結果不符合預測 我們就得放棄或修正這個理論 （至少按理應該這樣做才對，但實際上人們常會質疑觀測的精確度，以及主事者可靠程度與道德操守）。倘若你像我一樣接受實證主義，你就不能說時間真正是什麼，而是頂多只能說何者是時間極佳的數學模型，以及它做出些什麼預測。

－葉李華譯（2001），《胡桃裡的宇宙》，p.31，大塊文化。

實證主義運用數學模型來解釋在世界發生的各種現象的可能性，並且透過預測與實驗來增加理論的說服力。但如果我們發現某個數學模型的推論符合真實世界的某個現象而未發生任何的矛盾，那麼它可不可以用來證明世界上的其它現象而不發生矛盾呢？答案是不一定，我們必須透過實驗才能確認數學模型推論的適用範圍。但科學的進展會不會進步到那一天，運用人類的理性，可以找到完全窮盡世界可能性的數學真理呢？

如果正如 Zulu 提到的推論，自然現象符合數學真理本身就是一個最大的奇跡。那麼對世界而言，這樣的奇跡到底是福還是禍？Zulu 認為主體對世界的影響還沒有結束，它的種種可能性也未必被完全窮盡，是福是禍還難論定。同人進一步問到世界的可能性會有被人類完全窮盡的一天嗎？Zulu 表示他沒法預測未來會發生什麼事情，但其實我們還是可以經由推論得知，人類應該是不可能窮盡世界所有的可能性。

為什麼呢？因為要窮盡世界所有的可能性，要嘛透過經驗來歸納、要嘛運用理性來演繹。歸納法須要仰賴人們對問題領域有足夠的了解，但問題是人類經驗總是有侷限的，而且我們很難知道未來會不會因為新的經驗，而修正我們現在的想法。但如果應用數理邏輯來演繹，只要我們可以找出可以用來證明一切真理的公理系統，然後運用嚴密而一致性的演算及邏輯推演，是不是就可以證得世界所有的真理？

但很不幸地，「哥德爾不完備定理」告訴我們找不到這樣的萬能公理。哥德爾證明了任何無矛盾的公理體系，只要它的強度足以容納初等算術的陳述，則必定存在一個不可判定命題，用這組公理不能在有限步內判定其真假。也就是說，「無矛盾」和「完備」是不能同時滿足：

第一不完備性定理：任意一個包含算術系統在內的形式系統中，都存在一個命題，它在這個系統中既不能被證明也不能被否定。

第二不完備性定理：任意一個包含算術系統的形式系統自身不能證明它本身的無矛盾性。^[1]

這告訴我們，沒有任何使用一階邏輯的公理系統，可以窮舉所有公理的可能性，而不會發生任何矛盾，當然它也沒辦法證明自己的一致性。也就是說，再如何嚴密的數學真理，總會有命題讓它無法證明或否認。因此，縱使我們無法預知人類將來會如何改寫奇跡，但我們可以確知可能性是永遠不會有定論，而且沒有完全絕對的真理可以判定其它真理的真偽。

相對性的世界

假如人類無法找到絕對的公理來窮舉世界所有的可能性，那就代表我們處在相對性的世界，而不應該用絕對的真理來看世界。當然，可能你也可能拿上面這句話來質疑同人，相對性世界的觀點到底是絕對的，還是相對的呢？因為哥德爾不完備定理的效果，我們沒有辦法用數理邏輯來證明或否認這句話的真確性。但我們仍然可以選擇體驗存在於自己所相信的世界，而且有趣的是，與我們抱持矛盾真理的人們，也可以選擇在他們的世界中實現他們的真理。

例如羅式幾何使用與歐式幾何的平行公設相互矛盾的公理，推導出與歐式幾何不同的結論，但後人證明出羅式幾何可以在歐幾里得空間的曲面上實現，也就是非歐幾何命題可以「翻譯」成相應的歐幾里得幾何命題。如果歐幾里得幾何沒有矛盾，非歐幾何也就自然沒有矛盾。^[2]

如果人們可以認同歐氏幾何和非歐幾何，它們用矛盾的基本公理所導出的命題，同時都可以被視作嚴密而完善的幾何學。那麼我們為什麼不能接受存在的差異而接納或包容不同本質的存在呢？因此，彼此相互矛盾的真理，如果其中一個是正確的，不見得另一個就必然是錯誤的。

因為我們找不到絕對完備的真理，我們只能在相對性的世界運用它們，而不是用它們以絕對性的眼光來看待其它真理。任何真理都只是一種可能性，我們可以自由決定在什麼樣的可能性來運作我們的真理。

人類用理性創造的奇跡不見得比「未知的」上帝所創造的奇跡還來得真實、非孤立現象的存在不見得會比孤立現象的存在還更有價值、沒有「善」與「美」的真也不見得就不是「真」。以上的命題理性沒辦法證明它們是錯的，但情感上卻有可能因為人們的偏見而扭曲它們。

因此有時候真相也可能是，無法靠理性得到的經驗說不定會比理性的思考更真實、沒有統計量化支持的孤立現象的存在也不見得應該被棄缺、而會以意志或情感質疑別人的思想不是真理，本身就已經失去善與美的初心，只會離真理愈來愈遠。

科學與人文的交會點

世界從量子力學的「測不準原理」被發現以來，人們愈來愈發現世界充滿了無所不在的隨機性，宇宙無處不擲骰子。當然，我們可以用統計學來處理世界隨機性的問題，掌握世界應該還是有規則與定律可言。然而，當我們以客觀大尺度的數學模型來看宇宙定律的同時，可能會忽略了主觀而小尺度的個體感受；他們可能會無法承受混亂的隨機性加諸在他們身上的後果。

這些科學定律以外的意外並非不存在，而是因為孤立而被排除，所以科學真理的另一面也可能是事不關己的冷漠，從最近的新流感疾苗與美國牛的事件，我們也看到真理的產生，科學是必須與人文充分對話的。

同人認為，本質與存在的矛盾是為了讓人們找到科學與人文的交會點，就如同電影《心靈點滴》中的故事一樣。當在醫學院就讀的男主角看到女主角深受自己的影響，主動去關懷精神異常的病人卻慘遭殺害，他一度想放棄他的理想與努力；希望以關心病人為原則來強調人性尊嚴的醫學理念。

但正當他想放棄一切之際，一隻蝴蝶跟在他身邊飛舞，讓他想起女友曾經說過：「從小，我最羨慕毛毛蟲，因為牠有朝一日，能蛻變成美麗的蝴蝶，牠可以忘卻從前任何的傷痕，不復記憶。」他看到自己能帶給別人歡笑的奇妙天賦。於是他回到學校繼續堅持他的理想，想要扭轉醫學院以病名、病號稱呼病人冷漠的文化傳統。

不過，保守的醫學院長視他的存在為眼中盯，並且威脅要他退學。還好最後在他幫助過的病人幫助之下，終於成功挽救他差點被退學的危機，並且順利成功地拿到醫科學位。在畢業後成立一個「健康中心」，徹底實踐他的理念，為病人建立一個充滿關懷和歡笑的醫療環境。

本質與存在的矛盾是個體的生命課題，它沒辦法用邏輯、理論、或是任何群體的道德觀點來評斷是非，而只有在面對疑懼中，面對自己展現個體決定的生命本質。我們必須先成為我們自己，才能在思言行當中展現出屬於自己的生命本質。但存在如果沒有意識到矛盾，就沒辦法創造更有意義的價值。因此在科學本質必然性的另外一面，不可忽略的是面對偶然存在的人文思考呀。

1. 百度百科編者(2006)，哥德爾不完全性定理，百度百科，最近更新日期: 2009/12/30.
2. 維基百科編者 (2009). 雙曲幾何. Wikipedia, . Retrieved 05:54, 2月 3, 2010.

同事好奇重構的決定是否有客觀的標準，同人表示這部分多半還是個人主觀的經驗居多。在同事後來開車載我回台北的路上，我們再次談到決定重構的時機。同事覺得重構的時機似乎不是一件容易掌握的事，同人進一步地解釋，當時我們在應用程式的開發沒有太多重構的機會最主要的原因，是因為在架構上力求簡潔而單純的設計概念，使得應用程式的開發已經變得很簡單，實在不太需要運用重構用來增加設計的彈性。

趁這個機會，同人向同事強調架構的彈性不應該以需求不得改變為前提，而是要能夠因應「有限度」的變化而發展而不斷地調整及演進。也就是好的架構並非從恒久不變的核心來出發，而是要先去識別出問題的輪廓才找得到適用的核心。同人經常在軟體開發的實務中看到，人們花費了太多的心力來堅持不變的核心，到最後才會發現原來問題是出在自己對問題假設錯誤。

那麼，在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。

設計演進的基準

軟體開發與其它的產品開發有一個很大的不同，在於軟體通常很難在一開始就定義出明確的需求規格，取而代之的是軟體的發展方向，是用來解決利害關係人在真實世界所面臨的問題。這也是使用 IPO 傳統目標導向來開發軟體經常遇到的困難，當需求的改變不可能不經常發生的時候，軟體開發在品質文化上就不應該採用「照章行事」的模式，而是應該建立具有回饋機制的開發系統來把穩軟體的開發方向。

可以「把穩方向」的軟體開發系統應該具有什麼樣的回饋機制呢？根據溫伯格在他的軟體管理學的觀點，管理者賴以把穩方向的回饋機制，必須是可以直接及穩定的觀察專案目前的狀況、並且比較專案目標與現況的差異、然後以後續如何減少差異為目標改變或調整計劃、最後再根據計劃採取行動來改善專案狀況。其中有關於直接而穩定的觀察，直接代表肉眼可直接觀察的專案結果，穩定代表不同觀察者每次觀察的結果都相同。

相信從以上的觀點，我們可以清楚看到「把穩方向」的品質文化與敏捷開發調整式規劃的關連。規劃的目的不是為了得到一個巨細彌遺的計劃讓我們照表操課，而是指引一個達到目標的概略方向，然後因應專案實際現狀來調整計劃，來使我們不致迷航。基於這樣的觀念，運用 TDD（測試驅動開發）剛好可以提供對專案進行直接及穩定的觀察。

TDD 改變我們對解決問題的假設，不假設用什麼方法來解決問題，而是假設問題情境來思考各種可能的方法，並發展出最經濟的解決方案。假設方法如何解決問題並不是不好，只是這樣很容易讓開發者把他所熟悉的方法當成黃金錘，但最後所開發出來的軟體卻不見得符合使用者實際的需要，而且通常要花費很長的時間才會發現以上的落差，因此不會有足夠時間和資源來符合使用者的需求。

如果能儘早驗證開發的成果是否符合實際的需要，開發者就可以在早期得到使用者的回饋，進而調整努力方向來改善開發成果。傳統的開發方法沒有辦法做到早期回饋，是因為使用者要等到軟體開發出來才能接觸到系統，而且通常他們缺乏軟體開發的專業知識，所以在這之前他們是很難給予開發者有效的回饋。TDD 的開發思維則是促使開發者從思考軟體的使用情境出發，不要太早接觸繁複而細節的設計或實作，而是因應實際的需要而定義出界面規格，然後依據這些規格來決定該如何驗證問題能夠被解決。

因此，TDD 可以直接而穩定的在早期觀察開發狀態，提供設計演進的基準。這樣的基準可以讓開發者在開發過程中，直接面對目標而開發系統而不致迷航。也就是因應現實問題情境的需要，開發者未必有足夠的時間與心力來把設計做到盡善盡美，而是嘗試定義出最主要的功能需求，先採用最簡單的方式來滿足它們，然後再視使用者回饋的實際需要增添或修正功能，必要的時候甚至可以進行重構來維持設計簡潔與完整。換言之，TDD 是用來使開發者面對目標，讓開發範圍不要無謂擴張的一項有力工具。

延緩設計的決策

然而，當開發者採用了 TDD 的開發模式之後，是否正意味著我們儘快將使用者需要的功能實作出來，並不需要進行太多的設計工作，是否代表設計對使用 XP 實務的開發者來說是不重要的呢。但依照同人自身的經驗來看，對於使用 XP 實務的開發者而言，設計並非不重要，而是留下為實際的問題改進設計的彈性。

TDD 並非不做設計，而是把做更周詳的設計的時間延後到可以得到更佳設計決策的時候。或者更根本地來說，TDD 本身就是一種設計手法；而不是因為它以寫測試案例開始，而就把它當做開發的測試過程，這樣的誤解反而違反 TDD 的基本精神。

就設計的觀念來看，設計概念的完整性會直接影響設計的良窳。因此開發者應該盡全力來找出解決問題最重要的概念，同時隱藏或略除不必要的實作細節，來使設計更容易了解與實作。這也就是設計關鍵在於抽象化的道理，但問題是在對問題認識未盡全面以及成本或時程的限制，開發者通常沒辦法在第一時間找出解決問題最適當的核心概念。

因此，TDD 在還沒寫實際的程式之前，先撰寫測試案例。其所關注的問題並不是有效率的測試，而是務實的設計。先以測試案例的方法來識別出系統的大致輪廓，目的是以解決問題為前提，把問題的範圍限制在開發者可以全局掌控的情況下發展解決方案。而不是為了解決方案的堅持而使問題發散，最後反而使問題失焦而終致失控局面的發生。

如此，縱使軟體開發的變化是難以預測的，但只要每一次的變化都可以將廣大的可能性，限制在某一部份，那麼開發者就可以在系統的穩定與彈性之間維持良好的動態平衡；既不會讓需求的變化造成設計的崩壞，也不會因為技術的限制而造成設計的僵化。

穩定的設計可以在環境改變的情況下，不致使系統失去控制，彈性則是可以適應需求的變化而改進系統的設計。期待設計在一開始一次到位，這通常是不切實際的期待，還不如面對現實，先用簡單的方式滿足需求，然後隨著對問題的更深入理解，自然而然地演進出可以適應變化的設計。

這樣的觀念是把軟體開發的焦點放在系統邊界，然後隨著環境變化而逐步演進核心的設計，與傳統機械觀點的隱喻所不同的是，軟體開發不是努力去製造一些東西，而是運用生物演化觀點的隱喻：軟體開發是為了改變一些事情而努力。TDD 與 Refactoring 的搭配，正是促成軟體開發演化出複雜適應性以適應變化的實務方法。它們可用來避免軟體設計求道之過，所謂「道可致而不可求」不去強求而自然得到，才是真正的致呀。

提早整合的行動

其實軟體開發專案要把穩方向是很困難的，溫伯格認為主要的原因多半是管理者介入無效的管理作為；沒辦法掌握好「動作要小，行動要快」的原則，結果更增加專案的複雜度與風險，使得問題更加難以處理。

因此，如果使用 TDD 與 Refactoring 這兩項實務，可以讓我們具體地用測試案例來直接而穩定地觀察開發成果，運用簡單的設計來解決問題，又可以在必要的時候施重構來改善設計，以增加適應變化的彈性。那這樣還有沒有可能沒辦法掌握好設計演進的節奏呢？同人認為唯一的可能就是開發者沒有提早整合的行動，例如沒有在早期接受回饋以調整測試案例與重構，使得行動太慢，動作太大。

為什麼開發者會沒有提早整合呢？理論上，當開發者開發的程式完成 TDD 的測試程式之後，照理要進行清理程式碼的動作。比如說進行重構來去消除程式碼的重覆性或使程式碼看起來更簡潔而易懂。這樣可以讓程式碼在每一次的修正之後，都還是最乾淨的情況下，所以是不大可能會增加程式碼複雜度而造成未來難以維護的問題。

然而，在考量專案實際的問題下，開發者不見得每一次都會有足夠的時間來整理他的程式碼，使之形成良好的程式寫作風格與結構。而且管理者也很難知道開發者到有沒有力行這樣的原則，除非能夠對每一支程式來進行 Peer Review，否則只有「完成功能之後必須清理程式碼」的說法，而沒有為提昇程式碼品質而在每支程式交付時，提供改善回饋的具體措施，對專案其實並沒有太大的助益。

可能有人會認為搭檔編程的實務，就是讓每一次的程式開發都提供回饋。基本上同人並不反對這樣的說法，但要這樣做必須注意開發團隊的文化是否能夠支持這樣的做法。

同人以前曾有專案成員調動到使用搭檔編程的專案團隊，雖然看起來搭檔編程似乎讓她能力有所成長，但我也發現到她也出現適應不良的現象而心生抗拒，而當同人與他當時的主管當時的關心，也很難讓他願意分享自己的心情。由此看來，似乎還是有人習慣自己一個人寫程式，而不喜歡由兩個人共同開發一支程式，而且開發資源的分配者也不見得能夠支持這樣的觀念。

當然，要針對每一支程式做到 Peer Review，在實務上還是有很大的困難的。同人認為問題並不是 review code 要花費多少時間，而是專案需不需要針對程式碼進行儘早的回饋，以在最適當的時機採取最適當的行動？這其實是取決於專案願意花費多大的代價來提昇軟體的品質，不然當品質不合乎需求時，專案所節省下來的預防與檢驗成本將會為造成更大的失敗成本。

要落實提早整合的行動，專案團隊每天早上的 Daily stand-up 會議與採用 Daily build 持續整合的機制，是讓開發團隊的反應能力可以「與時俱進」的回饋活動。就像同人在分享會所分享的實務，在 Daily stand-up 會議得到開發實際碰到的問題，其實是幫我們識別關鍵設計概念的機會。由於過去問題尚未出現或對它們還不太明瞭，所以我們不需要或沒辦法進行設計的深入考量。而在 Daily stand-up 會議中，我們可以及時得到用來演進設計的資訊，並討論如何在後續的計劃中調整設計。

至於 Daily build，每天都會整合出可以實際運作的軟體。在 build 軟體的過程中，會自動執行 TDD 的自動化測試，以確保系統功能都是正常的。如果在 build 的過程中發生問題，馬上會立即通知相關的開發者立即解決問題。這樣可以在每天都讓每個開發小組都能密切地保持緊密的溝通與整合，發現問題立即處理而不需要等問題擴大之後才動大刀。

Daily stand-up 會議與 Daily build 的活動，讓每天都持續溝通與持續整合，每次都讓專案都朝向目標前進一小步，更重要的是，讓成員與時俱進地掌握設計演進的節奏！

同人最近才剛搬完家，一些還沒整理的東西都封裝在一箱一箱的紙箱中，我們也只能將它們暫時堆放在固定的角落，等到我們有空再慢慢整理。不過，老婆在育嬰假即將結束之前，剛好女兒的三歲生日也快到了，她希望幫女兒辦一個生日派對。邀集常和女兒在一起玩的小朋友以及他們的媽媽來我們家玩。

有了之前大家搓湯圓的經驗，辦生日派對應該不成問題，只是家裡有很多東西都還沒整理好，客廳也亂糟糟的，要如何邀請朋友來我們家玩呢？

所以要邀請朋友來我們家幫女兒辦生日派對，第一要務就是要把家裡整理乾淨，至少客廳要整理到看起來像個樣子。在沒有足夠時間整理之下，我們應該把客廳已經拆封紙箱內的物品，可以歸位的就將它歸位，還沒辦法歸位的物品則必須找地方將它們暫放，而尚未拆封的紙箱則必須在書房找位置整齊堆放，以免阻礙平常生活所需的動線與空間。

不過，也不能只把沒有拆封的箱子全部「藏起來」，客人來家裡參加生日派對，有關吃的、喝的、玩的相關物品，我們都必須將它們找出來，才能滿足為女兒舉辦生日派對的需要。

所以基於為女兒舉辦生日派對的需要，我們把派對需要用到的東西找出來，把與舉辦派對無關的東西收起來，等有那一天需要用到的時候再拿出來用。屆時，原來在派對需要用到的東西可能又會變得不符合實際需要的東西，我們會將它們收起來或是清理掉。不過，慢慢地，我們會清楚在我們搬過來的這個地方，我們會愈來愈清楚我們真正需要的物品是什麼，然後封箱的物品會愈來愈少，讓生活空間變大，可以容納更多生活對空間的需求。

以軟體開發的觀點來看，測試驅動開發的測試案例就好像整理房間的功能性需求一樣，為了符合舉辦生日派對物品及空間的需求。當決定了這個準則以後，我們就會知道我們實際上需要什麼東西，不需要的東西該放到什麼地方。於是我們可以花最少的努力來達成我們的目標，就好像測試驅動開發用最簡單的實作方式完成功能。至於重構是，當發現需求改變時，我們會再次調整空間的使用並整理需要的物品，以容納實際使用的需要。

其實，如果時間足夠，整理房間最完美的方式是把東西拆封定位，放到該放的位置上，並且清理掉不需要的東西。但現實的問題是，我們沒有足夠的時間，以及我們並不知道那些東西是我們真正需要的。有時候，今天我們認為需要的東西，明天可能根本就用不到，但如果丟掉它們，改天需要用的時候卻會遺憾我們已經丟掉了。

所以，比較敏捷的做法是整理現在需要用到的東西，以回應我們最重要的需求。一開始的需求不複雜，所以不需要花很大的心力來整理，等到對房間空間利用的需要更清楚的時候，再來更進一步的整理房間擺設。

整理房間是如此簡單明瞭地表現敏捷軟體開發的開發邏輯，相信寫到這裡，大家可以更清楚為什麼測試驅動開發並不一定要馬上重構程式碼了吧？尤其是徹底重構，整理房間的例子很清楚呈現：如果可以徹底重構，那我們也可以在第一時間把房間整理好，那也沒有重構這回事了。但從過去搬家整理房間的經驗看到，這根本就做不到呀！

延伸閱讀：（其它與測試驅動開發與重構的文章）
測試驅動開發的精神
測試驅動開發要徹底重構？
測試驅動開發的步驟

假如上面的話是成立的，那麼代表只要徹底重構系統就不會造成「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」嗎？如果是這樣，那 XP 根本就不需要 Refactoring 這個實務來改善程式的結構，因為你都徹底重構程式，程式結構變差的情況是根本不可能發生。

而且依照本人 20 年來軟體開發的經驗，我還不沒有看到有程式一開始就寫得很好，到後來可以不用改變架構而符合新需求的。倒是隨著對問題的更清楚，或是程式需求的變化，讓程式必須重構的現象時常履見不鮮！

所以如果自以為自己博覽群書，很懂得TDD的實務。也不要忘了用心思考，以免自己對TDD的最佳實務的認知，不小心犯了根本上的邏輯繆誤？

結果，後來同人在 Facebook 的 Scrum community in Taiwan 看到 Steven 做了以下的回應：

先說件簡單易明的事情，其實我很不喜歡閣下把 TDD 放到 『精神』 層次，卻忘記了基本步驟。

之前的討論根本連事實層次都被忽略，根本談不上是什麼多少年的經驗或者如何用心思考，連 TDD 的最基本步驟也忘記，TDD 的基本步，不是閣下做多少年工作就可以把人家的定義去改變的，我也不明白為何有 20 年工作經驗就可以把 『Refactoring』 說成 『並不必然是 TDD 的必要的步驟』，這不是邏輯問題，更不是有過什麼開發經驗然後用心思考就可以改變的事情，這是就算對軟體開發的認知不夠閣下那麼 『全面』 的都能看出的謬誤，如果閣下這樣就認為是因為說不過閣下就建議多看書本，本人深表遺憾。

我是來討論問題的，我沒有興趣去傷害閣下感情，好好閱讀書本，只是反映 TDD 三個步驟是什麼根本不存在爭議，更沒有 『好好閱讀什麼書或文章才能跟我討論』 的意思，我還未自大得要別人看過多少書才可以討論問題，亦正如討論問題我也不用跟別人說我有多少年工作經驗一樣，而且本人是衷心認為多讀書是有益的（不管是閣下還是什麼人），多讀書亦不是為上來辯論的，不過閣下如果感到有所不悅的，我就先行道歉，還是希望冷靜一點討論問題。

而簡單的例子也是思辦的過程的一部份，一方面是簡單易明地討論問題，另一方面是如果連簡單的例子也說不通，又怎麼能去談更複雜的問題呢？

上面提到：』那XP根本就不需要 refactoring 這個實務來改善程式的結構，因為你都徹底重構程式，程式結構變差的情況是根本不可能發生。』

不如冷靜一點再讀讀這句子，』XP 不需要 Refactoring 是因為徹式地進行 Refactoring』，我就看不明白這是什麼邏輯，一邊說不需要，另一邊說徹底地進行。

這裡的問題是軟件是會改變的，可能是新增功能，也可能發現有其他問題，每次帶來的變更其實都需要進行重構的。所以說 XP 不需要 Refactoring 也不正確。

世上的確沒有一寫就好的代碼，而且世界是會變的，Refactoring 就是避免以後的更改越來越困難。把 『徹底地進行重構』 理解成 『XP 不需要重構這實踐』 完全沒有邏輯可言。

我也沒有反對不用改變程式架構就能滿足新需求，亦沒有否定 Refactoring 的重要性，只不過我還是建議新的功能以 TDD 方式進行開發，有測試、有代碼、然後進行重構的。

在足夠測試覆蓋下進行重構是可使系統在不斷演進及需求不斷改變之下，使架構或設計仍然處於可以維護的狀態，相反我指出的是，如果程式架構和設計越來越難維護，是重構的力度不足夠。

前面還提到：』但重構的目的為何？就重構的定義在不改變功能的情況下改善程式結構，以增加程式碼的彈性以利未來增加或改變功能。因此如同那第三步所言，為了去掉重覆性而重構。』

如果重構只是為了去掉重覆性，那 TDD 的第三步不如叫 『Remove Duplication』 好了，無可否認代碼重覆是很常見的問題，但把這裡的重構限制成消除代碼其實會局限系統的將來發展，而且到了 TDD 的第三步，系統是應該有足夠的測試去覆蓋系統，重構的力度沒理由只局限於新增功能和現有程式的重覆。

我就相信閣下是 Refactoring 的專家，也應該會知道一些 Refactoring 的模式是完全相反的，例如 『Pull Up Method』 和 『Push Down Method』，更是需要觀察當時的情況來作決定，而沒有一面倒那個才是好的模式，我實在不明白為何要把 TDD 的 Refactoring 局限到只做 『去掉重覆性』。

這是實務上會發生的事情，消除代碼重覆以外的重構還是會發生的，如果只是單單只是 『消除重覆』，這會是另一個我認為進行重構不夠徹底的事情。

上面已經不單單是用心思考，而是由理論到實踐都可以看得到的事情。

跟討論 Refactoring 和 TDD 觀點以外的聲音，就引用 Chet Henderickson 的說法，全部都是我錯好了，現在可以解決問題嗎？

看了 Steven 的回應，同人當下的反應是不想浪費時間與心力與他周旋下去，但後來想到或許是因為 1/9 敏捷開發分享會我要分享實施 XP 的經驗與心得，也許這是一個巧妙的同步事件。我可以趁這個機會，導正對 XP 或是 Agile 的一些錯誤觀念。

例如敏捷開發並不是教條式的照本宣科，開發者要懂得變通最重要的是用心思考，而非把必要的思考都看成精神層面的問題，這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應，但一些詞句有略為做過一番修飾，以清楚表達我對測試驅動開發步驟的看法。

呵呵，Steven Mak 的回應很有趣，把別人說成錯的不代表自己就是對的。這跟他先前面對觀點的差異就要人好好的看書的行為是如出一轍，但問題是要別人好好看書也不代表說這句話的人書看得比別人廣泛或是深入。更何況，看很多書是一回事，有沒有讀懂書中作者所傳達的意思又是另外一回事。從 Steven 喜歡用斷章取義的方式解讀我的觀點，以抽取他想要的意義來看，恐怕他看書的目的只是揀選他要的部分，沒有弄懂作者想要傳達的意思的可能性可能居多吧！

對了，我忘了 Steven 的中文可能不夠好，沒辦法弄懂我所表達的意思。如果是這樣，他其實大可以告訴我，我不會叫他去好好地學中文，或是嘲笑他那麼簡單的句子都看不懂，而是想辦法要怎麼表達才會讓他了解我的想法。省去他猜錯我的意思，而顯露出他並沒用心體會或是根本不想思考別人的觀點的窘態。

當然，以上的假設可能是不成立的，他的中文其實很好。但如果是這樣，他的邏輯思維能力真的要加強，因為思考為什麼是最基本的能力，不是什麼經神層次。

記得去年同人應邀到中山大學演講，有機會與鄭炳強教授在餐敍之中交流軟體開發的觀念。他特別強調軟體工程最重要的不是 know how，而是 know why。因為遇到不同需要而要採用適當的方法，唯有具備 know why 的能力才能做到。以 Steven 那麼重視看書來增加知識的態度來看，他應該也很重視軟體工程的學界權威的看法吧？可是如果鄭教授看到 Steven 把 know why 的思維定位成精神層次，我想也很可能會令他很搖頭吧！

回歸正題，Robert C. Martin 在《敏捷軟體開發》這本書（林昆穎，吳京子，2005）中提到測試驅動開發法，他說：

所有的產出的程式碼都是為了讓失敗的單元測試通過而編寫的。首先，我們先寫一個單元測試案例，由於它所要測試的功能並不存在，所以它不會通過，然後我們再編寫程式碼，使得測試案例通過。

編寫測試案例與程式碼之間的反覆來回非常快速。只花費一會兒的功夫。測試案例與程式碼一起演進，而測試案例會比程式碼更早一點。

結果，一組非常完整的測試案例隨著程式碼一起增長，這些測試可讓程式員檢驗程式是否正常運作。如果有一組小搭檔做了些小修改，他們可執行這些測試案例，以確保修改並未對程式碼造成任何破壞。這會極有利於進行重整。

咦，堂堂一位敏捷開發大師級人物，怎麼他也沒提到 TDD 要重構，只說可以有助於未來的重構，難道他也擅改了 TDD 的步驟了嗎？讓我們看另外一本書。點空間的朱子傑和陳盈學翻譯的《The object primer 3/e 中文版－靈活模型驅動開發與UML2》中有更具體說明TDD的步驟，而且還附了流程圖（有興趣自己買書來看）。

1. 快速地加入一段測試，基本上只要能夠測試一段程式碼即可，此時你的測試結果會是失敗的。
2. 執行你的測試，一般是全部的測試套件（test suite）。有時候為了速度上的考量，你可能只決定執行這一部分的測試。目的是確認新的測試結果確實是失敗的。
3. 更新你的功能程式碼，使得測試可以通過。
4. 再次執行你的程式。
5. 如果測試還是失敗，再執行步驟3。
6. 如果通過測試，便重新開始（此時若有重複的程式碼，你便需要重構你的設計）

上面的步驟有提到重構，但也提到重構的前提是如果有重覆的程式碼才要重構。那如果沒有重覆程式碼，那還需要重構嗎？還是如 Steven 所說，去除重覆的程式碼的重構還是不夠徹底的重構？

答案很顯而易見，TDD的步驟本來就沒有規定一定要重構。事實上，重構對有經驗的開發者就是像吃飯或喝水般如此直覺，在開發程式的過程中，諸如像改變函數或變數的名字讓它們變得有意義或容易了解，一段重覆被呼叫的程式碼把它們提取成函數或類別。他們經常無意識地去重構，但有意識地面對他們開發過程所遇到的問題，諸如程式碼的重覆或不易了解等問題，而不是漫無目的的為重構而重構。

是以在開發功能的程式碼，因為編程手法的熟練，重覆碼根本就不存在，難道還需要一個重構的 process 嗎？由此可知，Steven 的徹底重構之說，其實就是邏輯上所謂的以偏概全，用部分的事實擴大到全面性的觀點。但真相是 TDD 未必要進行重構，除非你需要它。所以這當然是邏輯的問題，其實從我指出他邏輯的矛盾之後，他的反應更顯出欠缺邏輯的思辨能力。

不如冷靜一點再讀讀這句子，』XP 不需要 Refactoring 是因為徹式地進行 Refactoring』，我就看不明白這是什麼邏輯，一邊說不需要，另一邊說徹底地進行。

Steven 上面的質疑乍看來似乎有道理，但仔細看看，原來他把時間的因素拿掉了，有偷換觀念的嫌疑。我原先的說法是說因為先前徹底地重構，所以未來就不需要重構了，被他偷換成一邊說不需要，另一邊說徹底進行。

照他原來的邏輯，如果先前徹底重構的程式碼到後來還需要再次重構，那原來的重構還能叫徹底重構嗎？我們常看到有些人會在問題發生的時候，會說因為別人寫的程式碼出問題，是因為沒有徹底的重構，但在明眼人的眼中，這種說法可以用台語說「出一支嘴」！要嘛有徹底重構先見之明的人，你就再一開始就告訴大家什麼叫做徹底的重構，保證以後不會出問題，省得以後出了問題再說重構不夠徹底，後見之明說重構不夠徹底，這種說法誰都會說但卻根本做不到！

更何況重構的方法有好幾種，決定該怎麼重構的時間還沒到，如何徹底重構？或許有人會想依據未來的預測來徹底重構，但這樣想的人大概忘了敏捷方法是不進行預測的，只有因應現實而改變。

蘇格拉底說：「事情的好壞不重要，重要的是你的想法和看法。」本來針對事情來討論是一件好事，目的是為了思考彼此之間的差異點而獲得成長。無奈 Steven 一開始為了捍衛他的觀點，就針對和他觀點不同觀點的人，拼命強調同人說 TDD 不必然需要 Refactoring 的觀念是錯的，叫我要多看書暗示我不夠用功，其實這樣的行為模式突顯他面對意見紛歧沒有反省思辨的能力。

至於同人提出邏輯思辨的想法就叫做精神層面的說法，同人只能說這其實表現出 Steven 自以為是的「自我感覺良好」，運用修辭技巧閃來閃去還是難逃嚴謹的邏輯批判。他要表演這些同人其實沒什麼意見，他可以繼續活在他的象牙塔之中。但對於同人而言，我的收穫只是多看到一個負面教材，這對我 1/9 敏捷開發分享會的聽眾和閱讀我文章的讀者來說可是一大貢獻呀。Steven 說他不小心傷害我的感情；呵呵，少來了，不禮貌與不尊重的行為代表他不夠理性，只是顯出他的無理而已。

…here’s what we do: we drive development with automated test, a style of development called Test-Driven Development(TDD). In Test Driven Development:
* Write new code only if an automated test has failed
* Eliminate duplication
……

The two rules imply an oder to the tasks of programming.
1. Red – Write a little test that doesn’t work …
2. Green – Make the test work quickly…
3. Refactor – Eliminate all of the duplication….

Red/green/refactor – the TDD mantra

在這段敘述中，Kent 認為 Red/green/refactor 是 TDD 的三字箴言，是 TDD 這個 practice 重要的工作。

所以 Steven 才會強調在做 TDD 時，』測試是第一步』，』Refactoring 本身是 TDD 三步之中其中必要的一步』

假如正如 David Ko 所說，測試與 Refactoring 是 TDD 很重要的一環，而來強調 TDD 不應該忽略 Refactoring 的工作，這樣的觀點我可以接受，但同人隨後又看到 Steven 的說法，覺得他自以為是的論點讓我很遺憾。

本人從來沒有指出 TDD 是測試 Practice，亦沒有認為測試是 TDD 的目的。

上面的 『功能』 指代碼的內容規格，寫測試時候就是思考新功能的行為，用測試用例的方式去表達出來。就正如：

AssertEquals(3, add(1,2))

那麼簡單，已經是對 add() 作出規範，投入兩個參數，輸出一個數字作結果，並規範了新 fn 的名字是 『add』。寫這句 Assert 時候就應該思考到 add 有兩個參數，投入 1 和 2 就會得 3 這個數字。

重構是 TDD 其中一步，不存在混淆點，再者，沒有測試覆蓋下的根本不能說成重構；另一方面，先寫代碼後補測試是很痛苦的事情。

如果像閣下文中說：「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」，我則認為是在進行 TDD 時候沒有徹底去重構系統。

我建議閣下好好閱讀 TDD 的書本，Refactoring 是 TDD 必需的步驟，由 Kent Beck 到 Robert Martin 以至其他不太有名的 TDD 書本作者，都指出 TDD 的第三步是重構，而不是 『Refactoring 並不必然是 TDD 的必要的步驟。』

看到「我建議閣下好好閱讀 TDD 的書本」這種不尊重不同觀點的說法，同人根本就不想浪費時間來跟對方爭論。即使耐著性子仔細看他的論點，像那些「沒有測試覆蓋下的根本不能說成重構；另一方面，先寫代碼後補測試是很痛苦的事情。」、「如果像閣下文中說：『系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護』，我則認為是在進行 TDD 時候沒有徹底去重構系統。」等說法，更讓同人懷疑他對 TDD 的認知，其實是過於偏向理念化而不夠切合實際。

不過，對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法，同人倒是覺得有探討的必要。以下分享我在 Facebook 的 Scrum Community in Taiwan 回應 David Ko 的觀點，這些觀點應該可以解釋為什麼測試開發不需要徹底重構；其實重構並不是問題，而是到底什麼叫做徹底？而且如果 TDD 可以徹底重構，那麼代表一開始就可以讓設計一次到位，那寫好的測試程式以後也用不著了，不正是多此一舉？
—————————————————————————————————
柯兄，

我想在點空間，您應該曾看到我與某些只談理論忽略實際的顧問級大師論戰吧？即使當時我和他私下交情還不錯，但看到他用簡單的例子把軟體開發化約成不需要研究 how，或系統分析不需要懂領域知識的觀念，就不得不告訴他，他對軟體開發的認知是不夠全面的。這次對 TDD 實務的分歧點，我想也是差不多的情況。

只不過我不喜歡』我建議閣下好好閱讀 TDD 的書本』這樣的說法，在實務上我看過太多空談理論而不懂思辨問題的人，這種自以為是的論調讓我不想浪費時間回應他，但以下針對柯兄所提來說說我的看法。

單就字面來看，測試是第一步，重構是最後一步，看起來是沒錯，但問題是為什麼呢？測試先行我想應無疑義，我文章也談了很多，在此不再多說。但重構的目的為何？就重構的定義在不改變功能的情況下改善程式結構，以增加程式碼的彈性以利未來增加或改變功能。因此如同那第三步所言，為了去掉重覆性而重構。

但為什麼需要去掉重覆性呢？答案不外乎兩種，一種是日後重覆性造成程式維護的困難與增加錯誤機率，另一種是程式員擔心發生以上的現象或是因為個人對程式設計的信仰所致。

第一種狀況的重構是合理的，因為開發者是針對現實來解決問題；第二種狀況的重構很常見卻不見得是應該被鼔勵的做法，因為開發者是針對理想或信仰來行動，卻不見得符合實際的需要。但這兩種狀況都可以用重覆程式碼的壞味道的概念來合理化重構的行動，所以重構是正確的行動嗎？答案是視情況而定。

一些 TDD 的書籍或教本所舉得例子都很簡單，使得每一步驟都顯得理所當然。但真實的專案真的是這樣嗎？但個人當初在導入 XP 實務的時候，所遇到的困難，都沒辦法從那些書中得到答案，而是要親身體驗；書中教你的 what 其實需要你實施後的 how 及 why，才能更為全面把那些實務做到好。

最後，提一提測試涵蓋面的問題。在我還沒實施 TDD 的時候，當時我很肯定 TDD 的方法，但我想到的問題是測試程式要寫到什麼程度。但等到我開始實施 TDD 的時候，才發現測試程式的涵蓋面根本就不是問題，而是你需要 test driven 幫你做什麼。如果問題具體而明確，那那會有涵蓋面或不涵蓋面的問題？這時，才了解 Peter Ho 及盈學兄當年在點空間說過 TDD 不是測試而是設計的手法。還有那三句擺在我心中的經典名言：

Without refactoring, there is no room for plugging in new functionality to adapt the coming force.

Without testing, we couldn’t know where the edge is.

Without integration, the spark of life will die out.

一點淺見，供參考，但我絕不會叫別人好好閱讀什麼書或文章才能跟我討論…

聽到有人說 TDD 是個測試的 practice，跟 RD 不是那麼有關，我想這是誤會了。TDD是一種設計的活動，它並不是單純在做 verification，它是一種 spec 確認的活動。

David Ko 還分享了一篇探討 TDD 的文章供大家參考。這讓同人想到我之前曾經對 InfoQ 的一篇有關軟體開發信仰問題的文章做過的評論。

在那篇文章的評論當中，同人認為作者不應該拿 TDD 與驗收測試相提並論，因為 TDD 並不是測試的 practice，而是設計的活動。如果這兩種實務可以相提並論，似乎就像是爭論有了良好品質的設計就可以省略測試，或是增加測試的效率就可以取代設計的重要性。同人當時在我的評論中提到：

測試的涵蓋面要夠廣，軟體開發所需的開發成本與時間就要增加，所以與其靠檢驗來控制品質，還不如把設計做好。所以，品質是設計出來的，而非檢驗出來的。

不過，雖然品質並不是檢驗出來的，但軟體要具備足以信賴的品質，卻不能省略測試。舉個例子來說，不管開發者如何確保他的開發所產出的品質，驗收測試是絕對不可能省略的，否則客戶是很難信任軟體是合乎他們需求的。良好的軟體設計可以減輕測試的負擔與壓力，但它絕對無法否定軟體測試的價值。

因此，同人認為不該拿 TDD 來與各種形式的測試來做比較，但在 David Ko 提出這個主題後面的討論，我卻看到一個我不太認同的說法。Steven Mak 提到：

世上總有些傻人愛做傻事，阻止不了他們的 不單是由測試去訂定功能規格，更不要忘了 Refactoring!

同人以為由測試去訂定功能這個觀點不符合 TDD 的精神，因為正如同我之前一直強調的，TDD 並不是測試。至於 Refactoring 是不改變功能的情況下使程式的結構可以更有彈性或是更簡單，它也無法用來訂定功能規格。但 Steven Mak 卻說：

TDD 就是由測試去驅動開發功能，寫測試就是第一步，到底有什麼不符合 『TDD 精神』？還有，Refactoring 本身是 TDD 三步之中其中必要的一步，沒有訂定功能用的。但我相信把 TDD 以為是測試的人是忘掉了 Refactoring 這一步。

看來 Steven Mak 以測試驅動開發的第一步就是寫測試程式為理由，以為測試並沒有不符合 TDD 的精神，只是認為人們忘卻去做 refactoring，才會以為 TDD 只是用測試來訂定功能規格。同人認為這樣的觀點混淆了測試驅動開發的目的不在測試驅動本身，而是主導開發過程中可以具體落實簡單設計。也就是說測試並非目的，而只是手段而已！

事實上功能不是由測試來訂定的，而是由使用者實際需求來決定。測試程式只是讓開發者找到更具體的方法，來具體驗證使用者的實際需求，這也就是 David Ko 所說確認規格的活動。因此，測試驅動開發的目的是讓我們開發的程式碼能夠符合實際的需要，用可驗證的程式來確定我們開發的程式是符合實際需要的，以避免 over-engineering 或是 under-engineering，所以其目的是為了讓我們發現更符合實際需要的設計。

運用測試驅動開發，可以讓開發者的設計儘量簡單，因為開發的目標很具體地呈現在眼前。開發者已經事先對需求的確認花過一番心思考量，把現階段已經確認而且最重要的需求寫成測試程式，一旦開發的程式符合測試程式的要求，那就代表程式已然滿足實際的使用者需求，而使開發者不致浪費心力在不重要或是目前無法確定的需求上。

因此測試驅動開發可以讓開發者立即用最簡明而單純的設計完成開發工作，好處是讓開發者知道自己在做什麼，而非浪費時間在做沒有意義或無關緊要的事。但任何一開始簡明而單純的設計，在系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護。這時候單靠 TDD 的簡明與單純也可能沒辦法容納這種複雜性，而是要運用 Refactoring 來增加設計的彈性；也就是在不改變系統功能的情況下，改善系統設計的結構，使它可以因應未來增加需要的功能。

因此 Refactoring 與 TDD 是兩個相互獨立的 practice，雖然 TDD 可以讓重構更為可行。但兩者不必要要混為一談，也就是 Refactoring 並不必然是 TDD 的必要的步驟。

在大部分的情況下，用 TDD 落實簡單的設計就已經夠用了，除非我們真的發現到我們需要更大的彈性才需要進行 Refactoring 的行動。敏捷開發不是強調方法論的教條，因此不管是 TDD 或是 Refactoring，都是為了真實世界的問題的需要，而非方法論的信仰，這也是同人之前評論 InfoQ 那篇文章，最主要想要批判的重點。

因此，雖然 TDD 這三個字母或是測試驅動開發這六個字當中，測試驅動就佔掉了這個名詞的 2/3，但切莫以為 TDD 就是以測試去訂定功能規格，這只是對 TDD 流於表相的認識，而看不清楚這個名詞最重要的兩個字「開發」的真相。

測試驅動開發的精神，不應該用一般機械論的觀點來進行工作或任務的化約，而是基於複雜理論的重要觀念；維持穩定與變化的動態平衡，不在於掌握系統核心而在於邊緣，讓變動限定在人們可以掌握的範圍內，這或許才是測試驅動開發最關鍵的精神吧！

我常在做的 『教練』 工作大部分是在講一些基礎的東西與衍生的技術, 但是倒沒有想過要將團隊變成 『一致性』 , 試想, 你身為經理確發現實作的工程師缺乏某些觀念時, 你不得不著急,但是這種狀況出來的時候, 產品也開始出現許多問題, 這是技術經理面臨最大的挑戰。但是當技術經理開始當 『教練』 已經離開工程師角色一段時間, 這又是另一個挑戰

同人很高興 MaoYang 能夠針對這個主題提出討論。對於他所提到的問題，我常看到的是技術經理不能因材施教，所以究竟來看也是身為教練本身指導的彈性不足，也是多樣性的問題，尤其在軟體開發專案更為常見。

而且有時候工程師不是不懂那些概念，而是他們碰到一些技術經理不重視或忽略的問題，但如果沒辦法幫他們解決那些問題，如何讓他們接受那些觀念。教練就只會流於說教的自說自話。所以是管理能力的不足而非技術，也是我文章著墨於領導觀點重於技術觀點的主要原因。

對於領導，MaoYang 認為最好的領導是當顧問而不是教練；他提到工程師可以自己發現問題，來請教 『顧問』 ，當然如果工程師都看不到問題，那麼就另當別論。MaoYang 還提到他很欣賞上次 David Ko 在敏捷開發分享會提到的經驗；團隊主動提出要使用 Scrum，這時候身為經理的 David 只要做順水推舟的工作即可。

不過同人倒是認為，David Ko 的經驗是可遇不可求的。同人的經驗顯示，在台灣的軟體開發機構，是很少經營者有願意改變的胸襟與勇氣，即使有些老闆在口頭上說改革，但骨子裡卻是很畏懼改變而使所謂的改革只是流於表相化。

MaoYang 提到他在職場現實看到的一個現象；他說我在文中提到教練最好可以不給答案，而是提出問題讓工程師去思考。但是他在現實職場看到的是一堆人在揣摩老闆在想什麼？要怎麼做，老闆才會滿意？因此有時候他反而不太喜歡這樣的領導模式。同人覺得 MaoYang 這段說到重點了，但為什麼會形成這樣的企業文化呢？

MaoYang 說他覺得在中國人的企業都會有這種問題，這是為什麼 『雍正王朝』 被列為某些企業的管理教材。在雍正王朝裡面一堆這種範例，沒有正確答案，正確答案在主子的腦袋裡面。 這種文化要改，可能是領導者的腦袋要先改。

然後 MaoYang 還分享後來他想到他說技術經理下來當教練是不得不，意思是說理論上應該不用走到這一步，問題出在當初找人時，沒有嚴格把關，沒有找到對的人。他還提到 《Peopleware》 裡面也有講要如何 interview 工程師，所以《從 A 到 A+》裡面也有講企業要成功，要找到對的人。所以他認為技術經理當教練的徵兆對一家公司其實是不太好的，技術經理應該去看前瞻的東西，而不是當一名 『教練』。

其實同人很同意找到對的人來做事的想法，但事實上這卻是不容易做到的，尤其是軟體開發工作的專案，更難以找到對的人來做事。這種困難包括兩種情境，一種是找不到合適的人才來執行任務，另一種是把真正的人才放到不正確的任務上。

第一種情境雖然很常看到，但經常也可能是技術經理沒辦法慧眼識英雄或因材施教，而使好的人才淪為的犧牲品。在這種情狀下，其實問題不在找不到人才而是經理人本身領導或管理的問題。寫到這裡，我想到溫伯格在《第一級評量》講的一句話：沒有不好的士兵，只有不會帶兵的將領。

所以技術經理當教練如果對公司是不好的徵兆，問題應該還是出在領導上，誠如同人過去發表過的文章所講的：強將手下無弱兵，但也不會有強將。沒有辦法訓練培養人才的教練，還是因為技術經理不諳教練之道呀！

技術經理有時候要扮演 『教練』 的角色, 這時候要將正確的觀念傳遞, 這是有點困難的, 因為往往會被自己的極限所限制, 想起了一位朋友,他是長笛老師, 他說他知道那個音要如何如何才是完美的, 但是他確無法示範出來

對於 MaoYang 兄的觀點，通達人認為 MaoYang 的朋友應該要學如何示範，不然就不是個夠格的老師。這代表了技術經理應該要學習如何正確示範，否則就不能算是個好教練。MaoYang 兄進一步解釋他對技術經理擔任教練角色的觀察：

在公司內部, 技術經理當 『教練』 並不是明定的工作, 但是當團隊的程度良莠不齊的時候, 技術經理帶頭出來當 『教練』 , 是不得不的, 但是技術經理有時當管理職太久, 要把許多實作交代清楚, 這是當技術經理累人的地方

以上的解釋，通達人認為他同意當「教練」並不是技術經理明定的工作，但為了要避免身為技術經理的時間都被部屬瓜分了，較佳的方案還是當教練，讓部屬有成長的機會和空間。另外，有一位噗友 Daniel Li 也認為，身為技術領導者，給部屬魚吃不如教他如何釣魚。因為總是有一天，他們會離開教練單飛，就像教小孩走路；我們不可能一直挨著他隨時扶著他，只能教他方法、鼓勵或強迫他嘗試，並獎勵或誇大他的小成功。

在觀念上，以上的討論已經將技術經理擔任教練的動機及基本觀念，詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事，事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題，可以從兩方面來探討，一個是技術經理要教練的東西為何，另一個則是技術經理擔任教練的目的為何。

技術經理應該要教導他的團隊成員什麼東西呢？MaoYang 的長笛老師朋友說知道什麼才是完美音符，但自己卻不知道怎麼示範，然而如果技術經理知道如何示範他所知道的完美，那麼是否他就能夠傳遞正確的觀念了呢？答案並非如此，因為在這個地方存在一個陷阱；對於藝術而言，或許追求完美是有所意義，但在技術的領域中，完美真的是那麼絕對而必須去追求嗎？

在科技的領域中，我們通常找不到真正的完美。站在解決問題的角度來看，以前被認為是完美的方法，也許在今天會無法解決我們面對的問題。換言之，很多表面上看起來相似的問題，但在問題的本質上卻是全然是完全不同的，而且人們通常沒有辦法一眼認清它們，而是要深入研究後才能知道如何找到適合的方法來解決問題。這其實也是技術開發工作最困難的地方，很多問題很難找到最佳的解法，而只能基於現實用最適解來處理它們。

所以對於逐漸不再接觸技術的管理者而言，他們過去以為的完美是否到了今天還是那麼如此絕對呢？答案未必見得。就像溫伯格評論「成熟度」是偏頗字眼的道理一樣；所謂完美通常是基於個人信仰的價值判斷，這只是基於個人的感情需要，而非專案的真正需要。

因此，技術經理應該要教導他的團隊成員的東西，不應該是他已經知道的東西，而是他還不知道的東西，這樣他的團隊才能不被自己的所知有限而限制住。但如何可以做到呢？同人認為好的教練不會給答案，而是提出關鍵的問題教人們去思考，使人們在困惑產生學習的動機，以及有勇氣質疑權威與傳統上以為的理所當然。這樣才能增進團隊成員解決問題的能力，提供答案不會讓他們得到成長，只會造成依賴而削弱他們的力量。

至於技術經理擔任教練的目的為何，MaoYang 說當團隊的程度良莠不齊的時候，技術經理才不得不帶頭出來當 『教練』。那是否意味著技術經理當教練是為了讓團隊素質可以齊一化呢？但如果答案是肯定的，那代表在團隊的多樣性會慢慢消失而由—致性來取代，那麼喪失一致性的代價是否值得。但如果答案是否定的，那麼技術經理擔任教練的目的終究為何呢？

對同人的這個疑問，通達人認為在保有多樣性的同時，也必須注意—致性。因為一致性是合作的基礎，就像足球隊隊員們都須熟練基本技巧「控球」和「傳球」，才能在實際比賽中透過一系列交互傳球得分。通達人說的沒錯，但在實務上，同人經常看見技術經理會犧牲團隊成員的多樣性來增加一致性。

比如說運用制度或規章來抑制團隊成員的行為，不希望成員面對問題採取不一樣的想法與做法，但這通常是因為技術經理的管理彈性不足，才會對團隊成員處處設限。因為依據「必要多樣性法則」，系統的行為會由系統最有彈性的部分來掌控，如果技術經理的彈性不足，那麼團隊的多樣性將會造成他在管理上的困難。因此他必須設法降低多樣性才有辦法管理好他的團隊，但如此一來也等於抑制成員的創意，常會使得問題的解決更加困難。

當然團隊合作需要一致性，但技術經理當教練當拿一致性來取代多樣性卻不見得是明智的。就拿所謂的基本動作來說好了，很多人都忽略了基本動作需要以成員背景能力與組織文化為前提。因為如果不考量專案臨時與獨特的特性，你可以找到適合的人依據某種方法來訓練，但專案的特性讓你找不到適合的人來達到目的。

因此對專案而言，基本動作是夠用就好，但何謂夠用，正考驗著經理人面對現實的勇氣與智慧；縱使團隊的一致性可以降低管理的困難度。但一致性不是技術經理當教練的目的，只是用來達成最終目的－提昇團隊績效的手段之一。因此，如果解決專案問題的需要更高的團隊多樣性，恐怕如何提昇管理的彈性，才是技術經理成為好教練的關鍵因素吧！

月亮：主導潛在的特質,遇到突發狀況的立即反應！月亮星座很重要，是指情緒、第一時間的反應… 比如說當你的車子被人撞凹了，第一時間反應是打人還是報警？是看月亮星座…

同人直覺到上面這段話有問題。就我所知道的占星學觀念，月亮星座的確和突然狀況的立即反應有關，是代表情緒反應沒錯，但這種反應是否就是一般人所認知的第一時間的反應？同人認為這是很有問題的。然後，我又看到車子被撞凹後的行為反應是看月亮星座，這顯然並不是精確的說法，而是有以月亮星座簡化性格之嫌。

其實月亮星座的反應僅限於內心情感的情緒層面，而不會讓命盤主採取行動。或者用更精確的說法是，命盤主會選擇用行為來處理他的情緒反應，是因為其它星體的性格而非月亮星座。雖然月亮星座直接與情緒反應相關，但那並不代表月亮的情緒會直接連結到行為的表現上。因為月亮是陰性特質的星體，它不會用行為來直接表達情感，而是由其它陽性星體來表現情緒反應所造成的行為。

比如說水星代表適應，象徵人們在面對變化基於心智活動的反應，傾向於口語或文字的行為表現。金星代表協調，象徵人們在遇到價值衝突基於多方設想的反應，傾向參考別人意見來行事的行為表現。太陽代表意志，象徵人們為了維護形象形諸於外的反應，傾向於重視標準化言行的行為表現。

火星代表行動，代表人們在面對衝撞時基於能力的反應，傾向運用能力優勢來求勝的行為表現。木星代表體驗，象徵人們在面臨環境變遷以改變行為來擴展活動領域的反應，傾向用身體力行來增廣見聞的行為表現。

所以說月亮星座的反應並不會表現出行為，而是由以上陽性星體的星座性格來表達月亮的情緒反應所展現的行為反應。有了這樣的觀念，我們才能用占星學來解釋，為什麼有人心理會很生氣，行為上卻不會表達他的憤怒。其實人的行為通常是多面的性格所組合而成的，不應該只看一顆星體的星座來論斷，這樣很容易發生簡化的偏頗。

假如星盤中的月亮與某些陽性星體產生相位，命盤主就會傾向以那些陽性星體的性格來回應情緒事件。但如果產生相位的陰性星座，那麼命盤主就會傾向以內在的方式來處理情緒反應；比如呈現陰性特質水星的碎碎唸、陰性特質金星的用睡覺或享樂來發洩情緒、或是土星的隱忍。相位吉代表是健康的情緒處理方式，凶相位則代表星體代表的情緒處理方式容易導致後遺症。

不過，如果月亮並沒有與任何星體產生相位，前面提到陽性星體的星座還是可以看到命盤主在情緒反應後的行為模式。因為性格是存在的，只是它們不會對命盤主的生命歷程造成重大事件的影響。當然，遇到流年星還的引動還是有可能會發生情緒反應的行為，造成突發的意外事件。

Zulu 的文章提到蘇格拉底和格勞孔的對話。蘇格拉底說，沒有人願意甘願當統治者去糾正別人的惡，因為在統治發布命令的時候，並不是為了統治者，而是為了被治理的對象。所以我們想要讓有人願意擔任這種工作時，必須給予他名或利，如果他不願意，就給予懲罰。

格勞孔不大明白蘇格拉底提到用懲罰來當做報酬的道理何在。蘇格拉底說，懲罰可以使最優秀的人來領導人民，他們視貪圖名利為可恥。因此，好人不肯為了名利當官。他們不肯因擔任治理工作公開領取報酬，而被當成佣人，更不肯假公濟私，暗中舞弊，被人當作小偷。名譽也打動不了他們，因為他們並沒有野心。於是要他們同意當官，就只能用懲罰來強制了。

蘇格拉底提到大家看不起那些沒有受到強迫，就自己想要當官的人。但最大的懲罰莫過於，自己不去管人，卻被更壞的人管了。他認為好人最怕這種懲罰，所以勉強出來。他們不是為了自己的榮華富貴，而是迫不得已，實在找不到比他們更好，或同樣好的人來擔當這個責任。

蘇格拉底以為，假如全國都是好人，大家會爭著不當官，就像現在大家爭著當官一樣熱烈。這樣就可以清楚看到，一個真正的統治者追求的不是他自己的利益，而是被統治者的利益。所以聰明人寧可服從他人，也不願要他人服從自己。

以上有關「好人從政」的觀點，同人一開始沒有看得很清楚，以為與中國人的傳統觀念是相違背的。我想到〈論語述而篇〉的一段對話：

子謂顏淵曰：「用之則行，舍之則藏，惟我與爾有是夫。」子路曰：「子行三軍，則誰與？」子曰：「暴虎馮河，死而不悔者，吾不與也。必也臨事而懼，好謀而成者也。」

Zulu 也提到論語也說「邦有道則現，無道則隱，又說，危邦不入、亂邦不居。」他指出孔子對自己的家鄉沒有民族主義式的情感。

因此，從中國的傳統觀念看來，在世道混亂之際，具有德性與才能的君子不該淌政治的渾水，似乎與蘇格拉底認為應該用懲罰來迫使好人從政的觀點是相違背的。不過，同人後來仔細地看這篇文章，終於看懂這篇文章所要表達的觀念。

同人發現其中的關鍵就在於好人如果不從政，那被壞人治理，反而會讓人們受到更大的危害，這樣對好人算是難以接受的懲罰，而迫使他們出來從政。不過，觀察台灣的政治圈，好像大多的政治人物都說自己從政不是為了名利，而是為了服務大眾。然而在政治上，鮮少看到有人爭著不要做官，而表面上說自己不慕名利的人，卻還是常常看到他處處在算計自己的政治利益。

同人在最近幾年來隱隱覺得，現今在政治上握有權力的人，總是認為自己具有「好人」的形象，所以應該治理別人來糾正別人的錯誤。但慢慢地，人們發現所謂的「好人」並沒有足夠的領導能力來治理人民，而當他們在面對質疑時，卻表現出態度上的傲慢，讓我們不禁開始懷疑讓好人從政的理由，是否真的足夠充份呢？

就像當年胡自強先生戲稱「拋磚引玉」，引出馬英九先生出馬競選台北市長的場景一樣，這正是「人們看不起那些沒有受到強迫，就自己想要當官的人」的有力寫照。馬英九說他不忍心好友擔負起那麼大的壓力與責任，於是趕在前面宣布參選。或許也是因為這種不得不從政的形象，而讓他獲得當票當選台北市長。但同人今天已經不再相信馬英九當年選台北市長是迫不得已的，而我們看到的可能只是一場政治操作的策略而已。

Zulu 問我那是不是代表馬英九很奸詐？對這個問題同人沒有確定的答案，因為我不知道他從政的動機是為了自己還是為了別人好。但據説五百年才會出現一個聖人，而身為凡人能夠為不為自己好而為別人好的人實在太少了，因此我們不該期待政治人物不為私利而只為公眾利益。Zulu 說得好，我們都被馬基維利騙了，以為政治人物應該人格崇高。其實他們只是演員，負責讓劇情發展到人民期望的樣子。

因此，討論到這裡，同人認為還是讓正常人來領導人民吧！Zulu 則認為正常人享有太大的權力，就會變得不正常。但如果正常人享有太大的權力就會變得不正常，那麼過去未經過個人利害關係試煉的「好人」，會不會也開始追求榮華富貴更甚於人民的福址呢？

Zulu 說在蘇格拉底的年代，當時的希臘公民一般來說並不工作維生，大家都過得很逍遙。這樣看來古時候做好人比較容易，不像今天要「在亂世中做人」實屬不易。從荀子的性惡觀點，我們可以看到「人之生固小人」的觀念，認為人原初即是鄙陋的，即是「小人」：

人之生固小人，無師無法則唯利之見耳！人之生固小人，又以遇亂世得亂俗，是以小重小也，以亂得亂也。君子非得勢以臨之，則無由得開內焉。－－《荀子‧榮辱》

如同同人閱讀《在亂世中做人》的這本書，作者蕭政邦先生所提到的觀點。他提到《荀子》並無貶損人存價值或尊嚴之意。一方面這種見解是為肯定人文教養與人性陶冶的重要性而設，代表重視「教育師法」的功用和價值。另一方面，這種見解肯定人文化成的絕對意義；當人們稟持人文教化與一己的修養，而成為發揚善道的君子時，正顯示人足以透過自身努力以彰顯人存的價值與尊嚴。

蕭政邦認為《荀子》的看法使我們有機會領會「理想的人」其實是「發展性」的個體；不論人性原初具備了什麼特質，「善」總得以在人存的發展過程中逐步實現，甚至即便從一個鄙陋的基點出發，人還是有可能成就完善的人格，這是《荀子》相當特殊而值得重視的地方。

從以上的觀點看來，讓好人來領導國家，未必會為人民帶來福址。因為他可能還沒經過環境無情的考驗，還沒有學會該如何帶領人民迎向幸福，也或者是心態並未調整準備好接受領導人必須面對的挑戰。

畢竟當好人與好的領導者是兩回事的，好人還是必須要學習才會成為好的領導者，而在這之前，君子應沉潛自己來培養君德。《易經文言》九二曰：「君子學以聚之，問以辨之，居以寬之，仁以行之。易曰：見龍在田，利見大人，君德也。」而人民也必須學習認清「好人」的形象也只是政治人物眾多光環效應之一呀。