學長提到他和同事在工作上觀念的不同而引起爭執；他希望同事能夠思考流程如何改善，讓工作更有效率與品質。但同事則認為本來工作就是這樣做的，她並沒辦法改變什麼。結果兩人因為觀念不同而發生了言語衝突。文章的最後學長提到：

工作中充滿無奈與挑戰，或許是我的口才不好，下次要來學學勁哥跟畢姐，才能說服同事，多思考一起改善流程。不要整天都在救火，不僅沒效率、又沒效益，老闆也認為你在瞎忙。

看了學長的文章和後面的討論，同人覺得學長與同事的糾紛，真正的問題應該不在工作上的爭執，而是彼此語言差異產生的溝通障礙。雖然表面上雙方是因為在工作上的觀念不同而爭執，但存在雙方溝通的根本問題卻是因為顯著的語言差異。雙方使用不同的言語表達了彼此對工作重點的認知不一樣，但卻沒有討論彼此共同要解決問題的目標是什麼，只是各自表述對解決問題的理解，但這些理解只是手段而非目標，雙方自然會因為彼此想法歧異太大而無法溝通。

學長認為他的觀念沒有錯，領公司的一份薪水，應該多思考來發揮創造力，想想看如何改進工作效率與效益。他說下次要壓抑住快要抓狂的情緒，想辦法改善他的口才來說服同事。但同人認為在這種狀況下，口才根本派不上用場，而是要把心擺在正確的地方，才能弄清楚問題到底是什麼，以及它是否必須要被解決。

學長的技術背景讓他喜歡幫人解決問題，但他的同事依賴經驗卻不認為有什麼問題需要解決，依我看這才是造成雙方爭執最大的原因。學長認為同事面對工作流程的效率不夠好，應該積極思考問題的關鍵，而不是得過且過，用「本來就這樣」的藉口來搪塞。他以為公司是一個團隊，團隊中的成員不應該只懂埋頭苦幹，而是要多加思考來創造更高的價值。

然而或許學長的同事認為流程不需要改善，或是認為不值得在這上面花費時間和心力，或許是認為他有其它更重要的工作要做。其實團隊不可能只有存在一種特質的人，而且必須具備必要的多樣性才能發揮團隊的綜效，解決複雜的問題。

換句話說，團隊不可以只有會思考的人，也不可以只有會埋頭苦幹的人，而是必須同時具備思考和埋頭苦幹特質的人，缺一不可。因此，學長強調自己「正確」的觀念來導引同事思考，想要教他的同事解決不是問題的問題，彼此之間，是因為彼此用的語言不一樣而產生溝通障礙。

學長和他同事的語言如何不同？學長認為工作應該要重視思考和創意，要用更好的方式來完成工作，他說的是「求真」和「求美」的語言；而他的同事則認為在工作上，流程的改變對她而言沒有什麼意義，她說的是「求善」的語言。兩個人說的語言不同，並沒有誰對誰錯，只是訴求的方向不一樣，但執意要以一方的觀念來評論另外一方，只會變成各說各話而陷入「鷄同鴨講」的困境。

面對語言差異產生的溝通障礙，同人認為應該先處理關係，再解決問題。一般而言，溝通過程的緊張關係是因為彼此之間缺乏尊重與信任，當然也就不能相互理解彼此的差異。當溝通出現彼此意見分歧的時候，我們通常會強調自己觀點的正確性，藉以突顯他人觀點的錯誤。但如果以客觀的立場來看待雙方的觀點，每個人的觀點都有正確的訴求，但另一方面，很可能部分觀點會有不正確的地方。

其實不同觀念的歧見是為了發展更為一致性的觀點，而不是讓我們堅持己見而要求別人改變想法。所以不同觀點之間需要進行對話，以共同分享彼此的意義。我們應該尊重和我們抱持不同的觀點的人，並相信雙方可以盡最大的努力以達到「求同存異」，甚至是「聚同化異」，而不是運用口才來批評對方的錯誤。

對話除了尊重以外，暫緩確定性的想法也是很重要的一件事。這樣我們才能意識個體差異的存在，進而停止爭辯而進行反思，以尋求改進觀念的可能性。暫緩並非放棄自己價值判斷的主張，而是嘗試以思考的可能性取代堅持的確定性；先不要預設對錯，想一想對方可能也有值得參考的觀點，而自己疏漏了什麼。

對話的目的是為了與他人建立互相信賴的關係，希望從知己解彼開始，與他人共創雙贏，然後再進一步的達到統合綜效。因此，要化解語言差異的溝通障礙，同人首推對話這個有效的省思工具。

但那場衝突卻讓我體驗到內在心靈面對外在事物的挑釁，使得自我意識按捺不住內心的情緒起伏而起而對抗，或許這是潛意識要意識正視自我內在的衝突，以經驗意識與潛意識的整合。剛好我和同事發生爭論的主題是食物的營養價值，或許這個事件是要我體驗爭論的心理價值。

肉鬆的營養價值

說起來，與同事的爭論源起於微不足道的小事，但發生如此針鋒相對的衝突，卻是令人匪夷所思。在上週四吃午餐的時候，同事甲說他不喜歡三明治夾肉鬆，這時同事乙提到肉鬆是很美味的食物。同人則站在健康的角度說肉鬆並不是營養價值很高的食物，因為豬肉經過高溫及攪碎，它的蛋白質很容易被破壞而不利於健康。

沒想到同事乙對這個一般人都能理解的健康常識有意見，他聲稱蛋白質只要成分在食物裡面，並沒有什麼是不好的蛋白質。他指出肉鬆當中具備所有 20 種「必須胺基酸」，並且強調很多媒體所宣傳的健康觀念都是不正確而受到扭曲。面對這個意見分歧，同人並不想扯出太深奧的理論來爭論，只是舉出實例；同樣是吃蛋白質，吃一包肉鬆和一顆煎蛋其營養價值就是顯然不同的。

同事乙反問同人兩者是同樣重量的嗎？不同重量的食物如何拿來相比？我說那並不成問題，不好的蛋白質是愈吃對身體愈有不好的影響，而好的蛋白質則是有益於身體的健康。一個扣分另一個加分這是很明顯的。然後，奇怪的問題出現了，同事乙要我定義營養價值。這是繼〈金瓶梅與金蘋果〉之後，進行簡單的生活閒聊還需要嚴肅地定義名詞才能討論，這是不是生活白癡症候群的病徵呢？

同事乙的反應，讓同人發現他顯然不是要分享經驗，只是想為他所喜歡的事物辯護，甚至為了贏得辯論的勝利，運用概念偷換的技巧來扭曲他人觀點也再所不惜。就像把生活化的營養價值，扭曲成蛋白質的胺基酸成分，可惜他在無意之中，不小心在言談中透露他對「必須胺基酸」的無知，因為「必須胺基酸」不是 20 種，而是 8 種。他應該是把基本胺基酸誤解成必須胺基酸，只有基本胺基酸才是 20 種。

因此，對於同事乙的強辯，我根本不想浪費時間與之辯駁，只告訴他，如果他認為肉鬆的蛋白質不錯的話，那就請他餵食他將要出世的寶寶吃肉鬆而不要喝母奶。但他說母乳不只含有蛋白質，還有水，那麼他可以餵他的小孩吃肉鬆配開水嗎？同人很好奇他是不是敢這樣做來證明肉鬆的蛋白質和母乳一樣，而不是沒事找事來跟我做這種無謂的辯論！

在場有一位女同事丙，對同人與同事乙展開的激辯很不能理解。為什麼我們可以為小小的肉鬆，吵得不可開交呢？在爭吵後的短暫靜默後，我看同事乙沒辦法面對自己的無知，我也不想教導他正確的觀念。但本著知識分享的熱誠，我告訴同事丙要如何分辨吃肉鬆對人身體健康的影響。其實只要觀察自己的糞便顏色及形狀，就可知道你吃下食物是營養還是垃圾，而非如同同事乙說法的無知，以為看不到就無法分辨食物營養成分的好壞。

如果我們吃下去的食物，其中的蛋白質可以被人體完全吸收，而沒有殘存其它的廢物甚至是毒素時，那麼糞便的顏色就是黃色或金黃色，並且呈水滴狀讓人可以一通到底。否則就會出現深褐色甚至趨向於黑色，代表食物的蛋白質不容易消化，而且含有許多的廢物及會對身體產生危害的毒素。這些毒素必須由肝臟分泌膽汁進行酸鹼中和以排出體外，結果就會產生顏色很深及黏性很高的糞便。

衝突後的省思

這場爭論其實只是彼此閒聊的一次擦槍走火，同人相信沒有人想要刻意的製造糾紛。然而讓人疑惑的是，和上次「金蘋果與金瓶梅」的爭執一樣，似乎我看事情的觀點很容易與他人有格格不入的現象。那麼這是我的問題嗎？同人在噗浪以私噗敍述了這事件及我的心情，噗友 NANA 曾經是我過去同事提出了她的看法。

因為我只認識你，所以只能檢討你。或許，某些狀況下，你會不自覺的高調。所以建築了一些想挑戰你的人。

老同事說得沒錯，爭論的確有可能是因為挑戰的氣氛所引起的。同人還記得在這兩次的爭論過程，我似乎感受到對方對我說的事物好像並不怎麼了解，只是在價值觀上不能接受而加以反駁。但有趣的是他們又不願意明說，批判他們所反駁的對象卻又不願意承認他們的反抗是出自於主觀的道德偏見。

我想這包括不管是抽象的文化意涵、或是具體的食物營養價值都一樣。好像是接受了自我意識不願意承認的事物，就會讓人感到一種難以控制的威脅，是以他們必須盡全力地反抗這種可能性，好讓生活可以回歸常規的穩定與確定性。不過說實在的，這種生活態度實在是太過偏頗而狹隘，沒辦法體會到完整的生命。同人相信生命的目的不是為了批判對錯，而是體驗自我的獨特性。因此生命中存在過多的道德批判，其實對生命成長沒有太大的好處，卻多了許多負擔。

或許同人對他們的反應太認真了，畢竟抱持任何生命態度都是當事者自己的選擇，我們也沒必要對某種道德批判加入其它的道德批判。但一旦潛意識激起了內在情緒的本能反應，意識就不該對此等閒視之，因為那代表無意識對意識傳達關於自我表達與實現的重大真相。

顯然我的抗爭是對那些智識平庸，卻想表現出自己無所不知的傢伙。他們以為掌握了真理的真諦，但只在我冷眼旁觀的觀察中，表現出他們的愚昧與心虛。目空一切的他們表面上不去信奉任何信仰，但實際上是把自我投射成扭曲的真理，在不然就是迷信科學來創造他們自己的宗教信仰。同人想起來有一次同事乙說：「凡是科學不能證實的事物都不能相信」為了這句話讓我幾乎和他發生爭吵，所以這次與他辯論而發生衝突，我想可說是其來有致吧。

或許很多事我們不應該輕易地向人們提起，以免為自己帶來不必要的麻煩。如同《榮格自傳－回憶，夢，省思》提到的經驗：

同學威脅要像從前那樣孤立我。我絞盡腦汁想弄清楚自己到底做了什麼事，經過仔細的打聽，我才發現，他們之所以討厭我，是因為我經常對自己可能也不懂的事情加以評論或暗示，比如康德或叔本華，甚至是學校未開設的古生物學；這些令人震驚的發現讓我知道，實際上，所有受到熱烈爭論的問題都與日常生活毫無關係，它們如同我最隱晦的秘密，只屬於「上帝的世界」，因此你最好隻字不提。（《榮格自傳－回憶，夢，省思》，p.107-108。）

榮格在這本自傳批評尼釆在《查拉圖特拉如是說》這本書表現對二號人格病態的誤解。說他毫不擔心、毫不懷疑一個人在對這種事情一無所知，且不理解的世界讓二號人格出來亂跑。他被一種幼稚的希望所驅動，想找到能夠分享他的狂喜、能把握他「重新評價一切價值觀念」的思想的人們，然而他只找到有教養的市儈們，而他自己竟是其中一份子。榮格說在他冒冒失失一頭撞進不可言喻的神秘裡，並想向愚昧的人們讚美時，卻對自己一無所知，他妄想出賣靈魂以換取人們的注意。

我了解，一個人除非跟人們談些他們知道的事，否則只是對牛彈琴。幼稚的人並不會意識到，與友人談論他們不懂的事物是一種污辱。只有當討論者是個作家、記者或詩人時，他們才會原諒這種不客氣的行為。我逐漸明白，一種新思想或是舊思想中一個異乎常人的觀點，都得依靠事實才能與別人溝通。唯有事實站得住腳，不會被掃到一邊去；遲早會有人遇到它們，明白自己發現了什麼。（《榮格自傳－回憶，夢，省思》，p.148。）

於是同人看到了世界上愚昧平庸的人總是佔了多數，他們多半不承認自己的平庸，卻自認懂得很多事。想要跟這些人打交道，你必須要學會不要表現出知道很多他們不知道的事情，以免讓他們覺得難堪。同時這樣做也太幼稚了；只有深入自己的心靈世界中，才不會因為對自己一無所知，而在自我遭到內外衝撞夾擊時，顯出讓自己無所適從的拙態呀！

假如上面的話是成立的，那麼代表只要徹底重構系統就不會造成「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」嗎？如果是這樣，那 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 呀。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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