假如上面的話是成立的，那麼代表只要徹底重構系統就不會造成「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」嗎？如果是這樣，那 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 說他不小心傷害我的感情；呵呵，少來了，不禮貌與不尊重的行為代表他不夠理性，只是顯出他的無理而已。

經過一個月來的使用，這台 FE3000 用起來還蠻順手，直到最近因為無法透過 USB 連接線輸出照片，才發現 USB 的連接埠故障。老婆到總代理元佑實業要求維修，才發現 OLYMPUS 這個世界名牌數位相機的維修服務，竟是如此糟糕而令人失望。

同人聽到老婆告訴我客服要求我們付錢才能維修，這實在令人感到不可思議。老婆轉述客服的話說，連接埠的故障是因為人為操作錯誤造成，因為連接埠上的接頭凹陷下去，他們認為正常操作絕不會出現這樣的狀況。

老婆當然不能接受客服的說法，但客服說完卻忙著處理另一位客戶的大發雷霆；因為他送修的機器沒修好而吵著要找元佑的總經理處理問題。這時候，輪到另一位女性的客服人員來處理老婆的問題，她還是說這是人為操作不當，如果是按照正常的操作，USB 拔插 10 次都不會有問題。

老婆聽到客服人員這樣說，立即反應說：「這是什麼爛照像機，USB 只能使用 10 次，我以前用過其它廠牌的機型都沒有這樣的問題！」客服人員這時表示請老婆不要生氣，但她還是堅持修理 USB 連結埠故障必須要收費，要不然就只能買讀卡機來處理相片的輸出。老婆因為帶著還不到三歲的女兒，沒辦法也不想花太大的精神找對方理論，只好悻悻然地帶著相機回家。

聽到老婆送修數位相機的過程，實在讓同人覺得這個名牌數位相機維修服務真是離譜。在台灣的今天，竟然還有如此缺乏品質意識的公司，真是令人匪夷所思。

OLYMPUS 的 FE3000 並不是我們家所使用的第一台數位相機，過去我們用過很多其它廠牌的數位相機，而且也經常利用數位相機所附的 USB 界面來進行照片的影像輸出，從來也沒發生過 USB 連結埠那麼不堪使用的問題。

如果真如客服說是因為人為操作不當而造成損壞，那麼什麼樣的操作會造成這種問題呢？老婆轉述客服說可能是接頭方向對錯了，我聽到客服人員這樣說倒是想請對方表演如何將 USB 接頭反接給我看！事實上，這台相機的 USB 插槽有防止反接的缺口設計，根本就不可能發生將 USB 傳輸線反接的現象。

如果使用者不可能將 USB 傳輸線接反，再加上我們並非第一次使用 USB 的傳輸界面，對我們而言，連結 USB 傳輸線是那麼單純而簡單的步驟，我們應該不可能會弄錯而導致 USB 連結埠的損壞。如此看來，USB 連結埠的損壞的原因根本就並非人為操作不當，而是機器本身的設計不良或是構件本身的瑕疵。

所謂設計不良是指使用者在正常操作下會造成機件故障的比率。換言之，就像客服人員說得 USB 傳輸線正常拔插 10 次也不會故障。假如她說的沒錯，那麼就代表這台數位相機的 USB 傳輸線拔插的設計，只能保證正常使用拔插 10 次不會導致連結埠的損壞。因此站在使用者的觀點來看，這種設計當然是設計不良。

然而以常理來推論，實在很難讓人相信 OLYMPUS 的 USB 連結埠會設計成只能拔插 10 次而已。這樣看來，如果 USB 連結埠損害的原因不是因為設計不良，那麼就是 USB 連結埠構件本身的瑕疵，才會如此不堪使用。而那位客服人員如此缺乏 common sense 的說辭，不是想掩飾產品品質不良的真相，就是想要推拖維修的責任而刁難顧客。

這種罔顧客戶權益的行為，是客服人員的素質太差，還是因為元佑本身的企業文化所致？有網友告訴同人，在網路上元佑的相機維修，早就劣跡斑斑了。聽過老婆跟元佑接觸的經驗，再看看到網路上的文章、以及一些網友的經驗，讓人相信除了客服人員的問題之外，更嚴重的問題是他們的企業文化根本不重視「服務品質」這回事；對於客戶的維修需求，能夠推掉一件就賺一件，如果推不掉就再來修。換句話說，就是會吵的孩子才有糖吃。

一件商品在正常使用之下，在保固期內廠商竟然會拒負保固服務的責任。在這近幾年來，同人還是第一次意識到台灣會發生這樣的現象。不過有趣的是，有朋友認為消費者碰到這種情形不應該生氣。而是要怪自己沒有看清楚服務條款，以免因為憤怒而喪失理智，但同人認為這樣的想法反而會助長劣質服務的氣焰。

因此，相機的保固問題自然有法律來保障我們的權益，但除此之外，我們仍舊可以將不愉快的相機維修經驗，用來降低其他消費者因為資訊不對稱而增加的交易成本，以自然淘汰不良的服務品質。希望透過這篇文章的分享，也能夠讓更多人了解，數位相機除了品牌形象與功能外，不要忽略了售後的維修服務呀。

網路上其它有關元佑維修的討論：

數位相機不防水

戰勝元佑的例子

同人曾經和老婆一起探索我們的家族圖，那是她在研究所「家族治療」課程的家庭作業。我協助她繪製出我們婚姻結合的家族圖，並且透過探索與討論，我們看到家族之間的三角關係是如何影響雙方的家庭，並且發現那些傷人的秘密其實是因為上一代關係的需求沒有被滿足，轉而將希望投注在下一代身上。而下一代就不知不覺地受到上一代的陰影所影響，甚至因此造成一些家庭悲劇。

那麼家族中的三角關係是如何形成的呢？當父母沒辦法從他們之間的關係得到滿足時，通常會傾向於向兒女要求援助或尋求慰藉，而在多方拉扯之間形成三角關係。舉個例子來說，當母親表現出受到父親不盡責任以或是暴力相向時，孩子常會站出來幫忙母親來對抗父親，或是母親會希望孩子幫她跟父親交涉。

但這往往使父母之間的問題變得複雜，父母會變成依賴孩子，孩子也會因為父母而不勝其擾。而更嚴重的是，讓父母無法為發生在自己身上的事情負起責任，而孩子也沒辦法為自己的生命而活，並且會不知不覺地遺傳父母的行為，讓悲劇一再地重演。

以薩提爾的家族治療觀點來看，她說父母因彼此相同而在一起，因發現並尊重彼此差異而成長。但尊重與成長不是自動發生，兩人最初的希望落空，常為事實染上其它的色彩。一些未實現的夢想可以引發內在或外在的對話，如自我懷疑、指責、衝突、有時則是暴力。或是人們可能相信他們的夢想不再是必要的，只有接受現實。

父母之間得不到滿足，通常會指望孩子。他們常在粉碎夢想之餘，期望他們的孩子代替他們去完成夢想。因此，孩子不知不覺地將父母的渴望納入他們如何看待與應對這個世界的一部分，這就是生命以一種被投射的方式在自我完成。

由此可知，父母與孩子之間的三角關係是如此深遠地影響我們，陷入其中的我們已難以評斷其中的是非恩怨，生命也只有成熟度的問題而沒有對錯可言。

從同人自身的親身體驗，我很清楚上一代的恩怨要由上一代自己去解決，這一代有這一代的事情去面對，實在沒有多餘的心力來幫上一代解決問題，這是相當吃力不討好的事情。尤其是介入上一代的恩怨只會削弱父母面對及處理問題的動機與能力，在這種情況下，除了複雜的情感糾葛之外，他們不會滿意孩子為他們所做的一切。因為扮演弱者與強者之間的依存，只是逃避自由的一種心理機制。缺乏心靈上的極積自由，他們其實沒有認真想過，到底他們想要得到的東西是什麼。

要處理好家族的三角關係，同人認為我們應該加強自我分化的能力。分清楚自我與父母需要的差異，做好在情感上支持父母的角色，但不去介入幫他們處理問題，而是促成由他們處理自己的問題。只有「割斷臍帶做大人」，才能發展出成熟、穩定而健康的人生，也讓父母的關係按照他們想要的方式去發展。

或許有人會認為孩子要幫父母解決問題，這一切都是孩子應該面對的宿命，而且，也會擔心父母自己沒有辦法把問題處理好。但宿命其實也只是我們對生命的一種選擇。事實上，我們還有其它不一樣的選擇，這也是我們無可避免的成長課題。如同薩提爾的觀點所言：家人因為彼此相互尊重差異而成長。

因此，痛苦不是理所當然的實相，而是要我們從過程中學習成長，用更寬闊的視野來看生命，才能用更成熟的方式來處理家族中的三角關係。「幻滅是成長的開始」我們必先清除存在我們心中不切實際的期待，同時也讓父母瞭解到他們的問題只有自己才能解決。身為子女最多也只能在精神上支持父母並給予關懷，這樣才能讓家族之中成員的情感，產生健康而均衡的連繫。

在生活中放下掌控是一件不太容易做到的事，因為掌控是讓我們做一些事情好讓我們感到對問題不用再焦慮。然而，當被我們控制的對象會因為受到掌控的焦慮而與我們關係緊張時，那將會產生我們更大的焦慮，而造成我們人生的憂鬱。如此我們將得不到屬於我們生命的意義，讓我們的生命感到快樂而充實。

為什麼我們無法感受到快樂而充實的生命呢？因為我們心目當中，所謂的「優質世界」圖像無法實現，無法和對和我們有關係的人一齊去做有趣的事情。但為什麼做不到呢？因為掌控拉開彼此的距離，更有甚者，關係惡化到必須改變我們優質世界的圖像，而這樣的結局又讓彼此都很痛苦，尤其是我們總是傷害我們心愛的人最深。

假如我們可以認清生命的意義，就可以放下掌控以實現我們優質世界的圖像。但問題我們總是習慣的本能反應總是讓我們情緒受不了刺激乃至於失控，而看不到事件所突顯的意義所在。這些意義不是在表相上可見的選項，而是必須深入內在需求的真相，然後才能創造出可以豐富生命的意義。

特別是當我們面臨兩難而進退維谷時，要如何在關鍵時刻認清意義呢？我們選擇了一個意義而放棄了另一個意義，但它卻和我們所選擇的意義一樣，同時存在我們的優質世界圖像，取捨之間不見得是重要性可以解決的問題，當我們面臨這樣的情境時，將會使我們痛苦不堪。

怎麼辦呢？葛拉塞博士在他的書中提到碰到這種困難，一種方法是不要馬上作選擇，而是讓時間來慢慢浮現我們的需要，到時我們的取捨就不會那麼令人痛苦。但還有一種更好的方式，就是找到從兩難困境中去尋思自己真正需要的東西，然後以新生活重建新的生命價值與意義。就像葛拉塞博士在書中提到他輔導類似麥迪遜之橋故事情境的婦人一樣。在責任感與所愛之間的兩難，藉由讓當事人體會到衝突矛盾的背面，其實是突顯她的生命需要更新意義，然後才能找到重拾生活重心與希望的方法，而走出憂鬱。

或許是因為對生命秩序的期待，人們總是習慣以有限生命的經驗來認知意義。但人生處處充滿驚奇，有沒有恒久不變的意義可以讓我們發現呢？或許每個人有不同的答案，但如果你堅信這樣的價值觀，可能會比不堅持這樣信念的人碰到更多的困難。原因在《奇蹟課程》的前兩課說得很清楚：

在這房間我所看到、聽到的一切事物，並不代表任何的意義。
在這房間我所看到、聽到的一切事物，它們的意義是我所賦予的。

只有在體會到事情不必然按照我們的期待來發展，我們才會真正發現生命的樂趣。我們不用控制身邊的人事物，不管他們到了明天會變成怎麼樣，我們都可以控制我們生命的品質，放下掌控而盡情享受生命。也就是可以決定當下我們可以成為真正的自己，以創造出更不凡的生命意義。這樣來看，我們與其說認清生命的意義，同人更喜歡說決定自己的意義，不去期待該怎麼做或不該怎麼做的答案，而是聚焦於生命品質上，使我們優質世界的圖像得以實現。

我們在泰北高中站下車之候，老婆提到那位司機脾氣真大，我說大概是因為司機工作壓力大吧。這時老婆表示壓力抒解真的很重要，她還說她看到其他乘客對悠遊卡的使用也不清楚，但那位司機面對詢問甚至相應不理。同人認同老婆的看法，如果那位司機真的是壓力大而對乘客態度變差，或許只是無心之過。不過顯然這樣已經影響到他在工作上的專業表現，從命運的觀點來看，那位司機以憤怒對抗不滿，只會讓他創造出憤怒的人生，也著實足以令人心生警愓。

當然，憤怒的人生其實沒有什麼不好。事實上，新時代的價值觀本來就是不去批判任何人的人生，而是觀察不同的人生對我們生命進展的影響，並讓我們選擇體驗自己所賦予生命的意義。生命，每個人所賦予的意義都有所不同，因此批判不同的人生並沒有意義，這樣只是強迫別人要依照我們的方式來生活而徒增困擾。然而，當觀察到憤怒的人生時，可能會讓我們產生一些疑問；體驗以憤怒抗爭的意圖到底何在？它對展現生命意義到底有沒有效果？如何沒有效，為何我們還要以憤怒來回應生命的衝突呢？

會產生憤怒的情緒，是上天賜予我們的一項重要的禮物，只不過生氣並非我們所看到的表相。不是生命出現令人難堪的事件，而讓我們必須抗爭到底，才能讓它們遠離我們，相反地，它們卻是出自被曲解的善意；為了體現完美的人生、為了完成靈性成長的目的，我們必須創造一些不怎麼完美的事物，才能藉由不完美來體驗完美。因此，面對這些看起來不完美的人事物，與其用憤怒的抗爭來加諸在它們身上，還不如面對並接受它們的存在，並從中學習由它們帶來生命成長的課程。

很難做到嗎？就像那位客運司機可能會想，明明車上的標示那麼清楚，為什麼那些乘客總是不用心，或是不能體諒司機的辛勞，卻一再地問笨問題來加重駕駛人的工作負擔，真是令人生氣。會這樣想其實是把人生過度簡化了，以為人生是關於自己。但《與神對話》卻說：我們的人生並不是關於自己，而是關於這世上的每一個人。

這正是「一切即一」的道理；在這世界上除了自己之外，沒有其他的人存在。因此，一切你碰到的人事物，都只是你自己的一個分身，並藉由他們來體驗完整的人生。所以，如果司機不能接受乘客的不完美，其實意謂著他無法接受自己某一部分的不完美。我們也可以說他只是在對自己生氣，不滿意現況卻無力改變，憤怒只是表達自己的無能為力，這樣將難以跳脫自己所創造憤怒的實相。

《與神對話》說：命運是來自各處的意念（From all thoughts everywhere）。碰到生命的對立，如果我們一再地以憤怒來抗爭，也只是讓我們的人生充滿對抗與負面批評，而使我們的生命難以開展，因為我們將執著於生命的表相之中而無法突破厄運。要避免落入這樣的迷失之中，我們應該面對困境停止評斷以放下我執。不管我們碰到什麼，首先要感謝上天讓我們體驗這一切，來堅定我們對生命的信心與勇氣，然後好事即將會發生。因為所有我們需要的東西早就已經為我們準備好，只需要有信心地宣告自己「我是誰」，並且勇敢地體驗生命再創造（recreation）的過程，生命也必然會從此改觀。

開發者 D 君問同人：「規格好像沒有提到欄位空白該如何處理？」

同人回答：「沒特別說明就是代表將該欄位填入空白。」

D 君說：「為什麼不是未指定欄位內容呢？」

同人說：「如果是那樣，該欄位不應該在交易訊息中出現；但如果該欄位的內容是空白，那就應該不指定訊息欄位的值。」

D 君說：「不過，從交易訊息的定義來看，那個欄位是必要欄位，不可能不出現。」

同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」

D 君說：「那規格應該交待這個細節？」

同人說：「不需要，規格文件不寫語法而只會記載語意，因為語法是屬於 common sense，沒必要詳盡記錄在規格文件中。不然，如果連 common sense 都要寫在文件上的話，那是否意味程式設計者也不需要懂程式語言了，反正文件上都會寫。」

D 君說：「我知道了，你的意思是說我沒有 common sense！」

同人說：「如果你覺得我那裡說你沒 common sense，請明說我可以向你道歉，否則你這種情緒化的言論，只會讓人感到不舒服！」

D 君：…

同人將這件事寫在噗浪上，有噗友認為這類的開發者能力不行，沒什麼產值卻會製造問題。不過，在此事我所看到的問題倒不是開發者能力，而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通，這才是我認為最可怕的事情。

以同人的觀察來看，許多開發者看規格文件，通常不會站在問題的角度來思考，而是要求別人把答案準備好，然後告訴他們照著把功能做出來。

他們認為文件必須要註明他需要用到的所有資訊，而不要期待他們了解問題，因為他們不想花太多的心力來弄懂它，如果程式照規格開發而出現問題，那必然是規格問題而不是他們的疏失。因此，他們根本不在乎規格記錄語法或是語意，反正有寫就照著做，沒有寫的就不用管它，也不用思考合不合乎他們的 common sense。

同人認為這種心態正是忽略軟體開發的複雜本質，特別是軟體開發常會碰到半結構化、甚至是非結構的問題，使得規格文件難以事先將所有可能遇到的狀況都定義清楚。

舉個常見的例子來說，系統發生某些特別的異常狀態多半不是事前可以預料到的，沒有人能在事前發現問題，但等到發生意外才會發現問題在那裡。而且當我們發現到愈多問題，我們就會發現更多難以預料的未知的問題。

因此，開發者期待文件詳盡到無所不包，在專案現實是不可能做到的。實務上，通常文件規格的重點在於瞭解問題或如何解決問題，而並非得到詳盡的規格。但不明究理的開發者總是不去瞭解問題，只關心規格實做上的細節，當然很難掌握解決問題的要領。同人想到溫伯格說的「沒問題病候群」，他建議碰到這種人還是閃遠一點吧。

其實，表面上 D 君碰到的問題，好像是更改對語法的定義就可以解決問題；客戶認為交易訊息中的欄位不應該是空白的，所以訊息中的欄位空白應該代表該欄位內容未指定。但這樣的想法將會使得語法會受到業務規則的衝擊，而破壞設計概念的整體性與一致性，而影響軟體的設計結構。事實上，語法是不應該受到業務規則的影響，而是用語意來解決業務邏輯的合理性問題。

如果該欄位是必要欄位，那訊息中此欄位出現空白就應該認定資料錯誤；但如果它並不是必要欄位，那麼就應該定義訊息此欄位為非必要欄位。而在前者的狀況下，我們應該增加一條業務規則來檢核必要欄位不可為空白，否則將拋出異常的回應。如此就非常簡單解決問題，而不該採取自廢武功的作為，因為那只會顯露出開發者缺乏抽象化思考的 common sense 呀。

人們對於周遭的人總是會抱持著一些期望，希望他們能夠按照我們的意思去做。然而，每個人對同一件事的想法不盡相同，當發現對方出現行為落差時，人們很容易因為感到失望而產生困擾，使他想要採取行動來解決他的困擾。

我們該如何解決失望所產生的困擾呢？一般人多半會採取行動來干擾對方的行為，以反制對方的行為來控制對方的行為。這樣做除了可以發洩不滿的情緒，使自己覺得好過一點之外、還可以讓對方感到恐懼而令他們改變。但實際上，對方真的會因為我們的干擾而改變他們的行為嗎？其實並不然，我們的干擾行為不但沒辦法令他們改變；而且還會對我們採取相對反制的行為，讓我們更加失望，就如同下面的動態模型所示。

因為我們的干擾行為也會使得對方失望。人同此心，心同此理，對方自然也會採取反制行為以干擾我們的行為。於是，彼此的行為結構產生讓人更失望的增強環路，使得雙方更加失望而讓衝突愈演愈烈。如此可以想見，彼此的關係會因此受到衝擊，讓彼此關係出現裂痕，問題就更難以解決。

那麼我們該如何解決對方令我們失望的事件不斷重演呢？我們應該改善彼此關係而非糾正對方行為。就像同人在〈憤怒無補於事〉中曾經提到過的：

我們不一定要用生氣的情緒來回應事件。打破情緒失控的行為模式，最有效的方式就是換一種更積極的行為反應；也就是設法改善我們與對方的關係，增進彼此互信與降低衝突的可能性，才能真正的解決問題。

我們的干擾對方的行為，或許能夠在懲罰對方讓他不好過。但同樣地，對方的反制之舉也只會讓我們更生氣，這樣除了嚴重傷害彼此感情之外，對於解決問題也只是於事無補。

然而，如何在意見分歧的情形下，以不傷感情的方式進行有效溝通，來解決對方令我們希望的問題呢？同人認為最重要的是不要期望改變對方，而是要尊重對方與我們的差異，才能進一步理解為何為彼此之間會出現行為落差，然後再針對問題進行對話，才能在維繫雙方的關係下，為解決問題而共同努力。

沒有人可以改變除了自己以外的人，因此期待他人改變往往最後只會招致失望，而干擾行為則是招致失望的具體舉動呀。

領導他人是發揮我們的影響力，讓別人去做我們希望他去做的事情。相信很多人會以為自己無法有效領導他人是因為權力太小與位階不夠，無法讓人聽從我們的指揮。但本書的作者麥斯威爾卻認為，領導最大的挑戰就是領導自己。

麥斯威爾認為無論領導者帶領什麼人、或成就什麼事，領導自己一直都是領導者遇到最大挑戰。他指出歷史上功業彪炳的領導者，總以為他們是天之矯子；但如果我們認真檢視他們的生命，不難發現他們自己總需要經過一番掙扎。這就是「自己才是最難領導的人」的原因所在。

麥斯威爾分享他對領導自己的親身體會，他認為領導者應該力行學習服從、培養自律精神、磨鍊堅忍精神、追求負責精神等行為來領導自己。特別是在追求負責精神方面，他指出「領導是信任關係，而非權力關係」，因此領導者必須比別人更早自我「校正」。

儘管絕不自我膨脹是艱難的課題，但無論如何，不管領導者位階多高、掌握多大權力都必須力求做得對。領導者除了為自己負責之外，更得為追隨受自己領導的人負責，這樣的領導才值得受到他人的信任。

看了麥斯威爾上面的觀點，同人想到過去看到那些運用位階或權威的領導者。表面上看起來好像他們是威風八面，但其所表現出來的行為卻是領導無方。當他們動用自己的威權來使他人屈服之際，卻只會讓人發現他們缺乏領導能力，並在不知不覺當中，破壞了領導與被領導之間的信任關係，使得他們更加難以領導他人。

記得兩年前，同人就曾碰過這樣的領導者，當時他是某專案所指定的專案負責人。他對專案應該如何開發有不同的見解，認為專案開發應該照他在二十年前開發軟體的作法，但大部分的開發者認為，這樣做會讓專案失敗而反對他的意見。尤其同人更是擔任烏鴉的角色，基於我的專業，提出很多意見讓這位專案負責人覺得非常頭痛。

後來，在彼此意見分歧達到頂點時，專案負責人運用了位階與權力強迫別人聽命行事。當時他命令同人「不准說話」，結果讓團隊發生了嚴重的關係衝突。當時他可能是想動用權位，來逼走讓他最頭痛的團隊成員，不過此舉卻讓高層注意到他的領導能力出現問題。雖然礙於他在組織及與客戶的關係而無法將他換掉，但也開始削弱他對團隊的影響力，而且最後還是讓同人在此專案受到重用。

當然，這段關係衝突的經驗，讓同人對軟體專案團隊的衝突解決與信任的關係產生興趣，成就我的碩士論文也算是額外的貢獻。而獲益更良多的，大概是雖然沒有見賢思齊，但至少可以見不賢而內自省吧。

正如我們所預料的，在解約過程中，賣方與她所委託的仲介表現出不友善舉動。她們都用言語的指責來批評買方，而且表現得相當情緒化。雖然她們會有這樣的反應是人之常情，但這種不理性的舉動，卻看不到賣方仲介的專業與熱忱。

這不禁讓同人想到「態度決定一個人的成功，而非成功之後才改變態度」這句話，從賣方仲介表現出這樣的工作態度可知，她將很難在房屋仲介的行業中成功的。當然，她最後能否成功對同人來說並不重要，但倒是提供我們在工作上借鏡與反思的機會。

依據老婆告訴我解約的經過，一開始代書對老婆表現得很冷淡、愛理不理的，直到他發現自己在契約書寫錯買方地址的缺失後，態度才轉趨和善一些，但賣方委託的仲介卻一再地對老婆多加指責。

她提到我們前後看了房子五次，好不容易他們願意犧牲若干服務費來讓這間房屋買賣成交，沒有想到我們竟然如此不知好歹要取消交易。她說的話讓同行的妻舅感到莫明其妙，於是很不客氣地向對方反駁，另一位由我們委託的仲介看氣氛不對，於是叫他的同事閉嘴，才得開始進行解約的後續作業。

解除買賣契約的手續，賣方必須在場，但等了很久仍不見賣方出現，於是請仲介打電話催賣方前來。結果賣方一出現就抱怨：沒有人通知她今天要來這辦理解約；搞了半天，原來是賣方仲介根本沒通知她。

賣方仲介熱絡地向賣方示好，似乎是刻意藉此冷落老婆與妻舅，買方仲介見狀也問老婆是否要倒茶水，老婆不以為意示意不要。而賣方在看到老婆後，就一直批評我們夫妻不懂得為他人設想，說我們就是自私，而對這樣的批評，老婆在當時並不想和她計較。

後來，由賣方仲介負責傳真解約相關文件到總公司，傳了一個多小時，文件就是傳不過去。對此，賣方仲介還特意譏諷說文件傳不過去，想藉機調侃老婆。

妻舅看到文件傳不出去，加上賣方仲介表現出輕忽的態度，於是不動聲色地隨手就在解約條款中加一條聲明。提出要等買方收到退款解約才算完成，結果買賣雙方的仲介都不敢簽名以示負責，只好由買方仲介慫恿賣方簽名同意這項附加條款。

最後，在買方仲介協助下，文件終於傳真出去了。但後來老婆看到履保專戶中，存款餘額數字卻有短少的現象。進一步再查閱交易記錄才發現，原來仲介公司早在簽約過後沒幾天，就已經把一半的仲介服務費拿走了。於是老婆當場向仲介追討短少的金額，結果仲介公司直接以現金歸還這些差額。

聽到以上解約的經過，同人覺得賣方仲介的表現，實在是沒有什麼專業與熱忱可言。見微可知著，由解約過程她所表現情緒化就可以知道，習慣以情緒反應來取代理智思考，這就難怪她處理事情，總是出現零零落落的現象。

從提供不完整而沒有賣方簽名的〈不動產現況說明書〉、到負責海砂屋檢測的連絡事宜，每次都讓我們發現她辦事粗糙不堪，亳無品質可言。就連解約也沒有及時聯絡賣方、連傳真文件都可以虛耗一個多小時的時間，這些都讓人懷疑她有足夠的專業來把事情做好。

尤其她抱怨我們房子看太多次更是一絕，虧她多花心思幫我們計算看屋的次數，不然我們還不知道這間房子看了幾次。不過，如果她把這些心思用在如何把她的工作做好，我想就能提供更好的服務品質，也就不用怪顧客使她如此辛苦與勞累。其實房屋仲介並不是製造或買賣業，而是服務業，所以如果她覺得帶客戶看房子深感痛苦，可能她並不適合從事房屋仲介的工作，她應該怪自己選錯行業才對。

賣方仲介說這間房子物超所值，指出我們把價錢壓得很低，逼她們要犧牲一些服務費才能促成交易，但這種的說法更是顯得似是而非。因為以常理來推斷，如果仲介無利可圖，她們根本就不會讓這個交易成交，也就不需要犧牲服務費來讓交易成交了；既然交易成交了，那就代表這是買賣與仲介三方之間都能夠接受的價格，不然就是仲介與賣方之間有什麼特殊的協議。所以，買賣因故未成再回頭來責怪買方出價太低，根本就不成道理。

所以，對於賣方會在解約過程中指責我們自私，同人懷疑那應該是賣方仲介的誤導與挑撥，沒有告訴她正確的觀念，使她對我們帶著恨意與偏見。不然，我想賣方如果能夠將心比心，她應該不會為求房屋的脫手，而要我們承受海砂屋陰影下的承重壓力、也不會沒有想到我們的女兒有過敏體質，她的身體健康不應該為她的房屋脫手付出慘痛的代價呀。

其實以上仲介與賣方對我們的批評與指責，在解約過程本來就不該出現。因為即使買賣雙方對海砂屋的認知，存在相當大的歧見，但也經過協調會的溝通而達到雙方解除契約的共識，實在不應該再爭論誰對誰錯的問題，而是應該按照協調內容來解除契約，這才是對買賣雙方有實質意義的事情，還好除了那位不濟事的賣方仲介之外，大家都還能明白這個道理。

雖然在過程中，讓我們發現仲介公司早已扣掉我們的服務費，卻在協調會中強調沒有拿我們一毛錢的說法，感到缺乏誠信而產生不滿，但起碼大家還能對彼此的差異相互尊重，以共同面對問題來進行處理，這還是值得稱許的。只是讓我們看到賣方仲介的醜態畢露，實在讓同人覺得有點美中不足，我想除了她的修養可能不夠之外，就是還需要公司或是環境讓她再教育。

從事軟體開發的工作，同人常觀察到一些開發者不懂藏拙的智慧，意欲表現自己很有能力，但卻總是被人看到他們虛有其表的黔驢之技。通常這種人不懂得用虛心受教來充實能力，而只會把問題的責任推到他人身上。

我們當然很希望這樣的人，不要出現在工作經驗當中。但很不幸地，世事總是難以如我們的預期，如果不幸在工作碰到這樣的人，我們應該如何自處呢？

同人最近就碰到這樣的人，我所參與的專案在訊息交換時出了錯誤，後來有人發現當 XML 訊息中沒有出現某些標籤時，就會產生問題。此時，負責開發接受端程式的開發者表示，XML 訊息中的所有的標籤都必須要存在，即使沒有用到也不能省略，要補一個空的標籤，這是 XML 的標準做法。

他的說法馬上得到其他人的質疑，明明 XML 訊息中不需要用到的標籤可以不用出現，這才是 XML 的標準做法，因此程式產生錯誤的問題，是出在他拆解訊息的程式寫得不夠強固，而不是別人沒有按照標準傳送訊息給他的程式。然而，他對大家的質疑，卻立即用下面這段話來提出反駁。

從我這麼多年寫 XML 程式以來，XML 的標準規格就是照我說的；沒有用到的欄位要用空標籤來表示。

雖然同人並不認同他的看法，但為了溝通彼此的想法，我還是提醒他這個時候強調自己多有經驗，其實無益於彼此溝通，只會流於各說各話；同時我也提到了 XML 訊息中，使用空標籤並不能代表用不到該標籤對應到的欄位。

同人以為有經驗的開發者應該都知道上面提到的觀念，空標籤代表應對的資料內容是空值，而省略標籤則代表不知該資料的確切內容，或是指該資料在此刻並「不適用」（N/A，Not available）；但沒想到這位堅持己見的開發者不能理性對話，竟然叫我不要說話。

他說他在和負責寫訊息傳送端程式的人在溝通，所以我不應該講話。可是我身為系統分析師，訊息界面規格是我制定的，為什麼我不可以表示意見！不過，既然他如此不可理喻，我也不想生氣浪費我的時間。

我向負責寫訊息傳送端程式的人表示：「不管你決定怎麼做，請堅持專業」、並告訴專案經理說：「如果訊息格式有這樣不合理的限制，只會出現彼此各自為政而整合困難的現象，也會讓問題愈弄愈複雜」。

後來當然是由專案經理出面，「教育」那位自以為是的開發者，要求他必須加強他的程式功能，而非要求別人來配合他的程式。不過，看到那位開發者，在他自以為很有技術權威的外表下，潛藏著其能力的虛有其表，又不願藏拙而想要表現自己什麼都懂，他應該不了解「人外有人，天外有天」的道理吧，這種人還是遠離他一點，就讓他自己去自食惡果吧。