XP:抄近路的詭計
--------------------------------------------------------------------------------
Doug Rosenberg及Kendall Scott對于XP的質疑
原文(jyemii于2002/01/08 13:08粘貼)繁體中文
--------------------------------------------------------------------------------
介紹
終極制程(Extreme Programming (XP))提供一些有用的概念。我們相信強調測試及他們的指引原理是有重大的價值；這些原理在軟件開發程序的發展上非常有用。但是不管如何；曖昧的主張(dubious claims)、明顯的缺乏可達成性(scalability)、動聽但是問題重重的口號及極端的(Xtremist)姿態幾乎掩蓋了良好的本質。
Doug曾經在OTUG(Object Technology User Group)中有過廣泛的討論。其中有些是相當有用的，有些則是愚蠢的，有些仍有問題亟待回答。Kendall花了相當長的時間詳讀Wiki網站上的文章。下面大多數的探討XP的結構及程序(ritual)是依據這些交談及研究。
--------------------------------------------------------------------------------
曖昧的主張
Kent Beck及其主要的追隨者曾經定位XP是一種『輕量級(lightweight)』程序；這個開發程序可以產出較高品質；以及在一個更及時性的基礎上；然后由更細節的程序所組成。（XP人(XPers )偏向歸因這些所使用的術語如大設計(Big Design)<譯注1>，我們在這整篇文章中也使用這個術語。）然而在這個『程序』的核心有一個相當大的漏洞：分析基本上以被拋出(tossed)。
讓我們看看一些主張；XP追隨者把跳過大設計的分析中『笨重(cumbersome)』的成分做了合理化。
--------------------------------------------------------------------------------
每周改變的需求
依據XP人的說法，處理那些變動的需求在需求的前置(upfront)分析至少有兩個主要的缺點：
大設計尋求控制改變的機制，經由早期獲得及一般性的一次解決所有的需求及架構。實際上多數的大設計方法有詳細的結構承擔必然發生的外部變動，但這些機制往往似乎是或多或少在程序中屬于次要的。
大設計視任何不確定情況是一種危機。如果有一些事情是我們不知道的，我們無法推理它們。
這些由Doug所接收到記錄的言詞，經與OTUG聯系，其答復是：「你說前置(up-front)『 擷取需求(capture requirements)』，但坦白的說真的嚇到我了，因為我從幾哩外聞到『瀑布式』�！�
甚至，XP陣營的感覺是客戶對于其在項目中相要的只有一點點的概念。有一個信徒甚至宣稱「一開始客戶不可能了解他們真正所想要的�！股踔廉斂蛻舢敵踔赋鏊麄兊男枨�，他們在幾周之后堅持改變這些需求，而有時是每天的改變。因此，在跳入程序撰寫之前嘗試凍結需求是沒有意義的。
我們同意需求分析及擷取是充滿困難及不確定性。但Doug曾經在許多業態中做過多個項目，其中他的客戶或多或少控制避免如此的優柔寡斷。不，在你開始構建你的系統之前你無需擷取所有個別的需求，但我們堅持某層次的前置分析可以解省你一路上許多時間。
有時在開始撰寫程序代碼之前要求客戶精煉(refine)他們所了解的并指出他們想要的是有用的，客戶希望從開發團對中獲得一些訓練(discipline)：而同時要求客戶提出一些訓練也是全然合理的。如果客戶真的對他們所想要的沒有任何概念；當他們看到一些可執行的東西；雛形（以實際的程序代碼建立的）是一個很好的技術可以幫助客戶獲得清晰的了解他們所想要的。那是與客戶合作的一種良好分析的工作同時可以幫助客戶精煉他們所了解的。
確實有這種情況；當開始撰寫程序之后客戶的需求改變了。我們假涉有任何的可能性，這些改變在下一構建循環中獲得控制。若那是不可能的時候，你應當盡你最大的能力去做。許多XP技術在「盡你最大的能力去做」大概是相當的有價值的。
有人問Daug「如果你后來發現客戶的需求已被曲解而修正需要從設計的基礎改變你會怎么辦？」真正的問題是，這種情況發生的頻率有多高，而我們需要多辛苦事先避免產生這種情況？而這正是嘲笑『分析』程序為其本身付出太多時間。我們作分析以避免這種情況的產生。
--------------------------------------------------------------------------------
使用案例(use case)太復雜
XP建議你以『使用者故事』擷取需求。這是相對使用案例；XP人一般的感覺是使用案例只能在詳盡的細節架構使用者的需求，在長長的格式中有太繁重的東西要去填入。引用Wiki網頁誠實的傳達XP群體對于使用案例感覺：「我的目標是維持介于企業(business)與開發之間策略權力(political power)的平衡。我曾看過的使用案例的應用太過復雜且正式(formal)以致于商業一方不想去接觸使用案例。這導致開發一方詢問所有的問題并寫下來所有的回答并且承擔所有結果的責任。商業一方簡化成只坐在桌子的另一邊并指指點點的�！�
這是我們看這件事的方式。
一個使用案例是一系列的活動；其中一個活動者(actor)在一個系統中執行以達成特定的目標。關于其定義并沒有特別的復雜，或太過正式。
使用案例是最有效說明使用者的觀點；其中是以動詞詞組表達活動。這表示使用者需要有一個清晰的了解這一系列的活動是他期望依循的，那確實意味著客戶是主動的參與使用案例的細節。如果所了解的不是這些，那么使用案例是太復雜需要精煉--你知道，就像程序代碼迫切需要重整(refactoring)。
在我們的經驗中，『分析癱瘓(paralysis)』在關連到使用案例塑模(modeling)至少可能有三種發生的理由：
團隊花費幾周的時間構建精心制作精致的使用案例模式而無法據以設計。
團隊空轉于憂心是否使用任何或所有的UML構詞(constructs)『include』、『extends』及/或『uses』。
團隊浪費時間在長及復雜的使用案例樣版（有趣的是，我們似乎或多或少同意XP人這方面的觀點。）。
XP信徒顯然指熟悉導致分析癱瘓的一類使用案例。我們說如果你以使用案例連接(in conjunction with)頻繁的雛形法推導(derive)，并且/或從舊有(legacy)文件（特別的，使用者手冊）挖掘使用案例，而你仍高度全時間聚焦于你的客戶，你非常有機會在你開始做之前指出你所需要做的，同時結果將是顯著的一路安全的走下去。
--------------------------------------------------------------------------------
修復的成本曲線是平緩的
Kent Beck曾經宣稱改變程序代碼中的臭蟲的成本與改變設計臭蟲的成本一樣的，因為程序代碼是設計。我們在后面會說明這個理論的基礎上的愚蠢，但同時我想要指出由于Xtremists從圖形吹噓其分析，那是 導因為果(circular reasoning)。
其推論如下。如果我們在撰寫程序之前并未作分析及設計，那么沒人可以斷言在我們開始撰寫程序設計之前修復錯誤是比較便宜的--因為沒有「在我們開始撰寫程序之前」這件事情。迅速的，修復的成本曲線從對數變(logarithmic)成線性(linear)。
讓我們稍微重新敘述：
我們可以是軟件開發為一持續系列的撰寫程序、測試程序代碼、拆解(ripping)程序代碼、重新測試程序代碼、重新撰寫程序代碼、重新測試程序代碼如此不斷的循環。 這些都是相同的動作，加上一些分析及設計交雜持續進行。因此，程序代碼變動的成本是線性的與你何時發現需要改變沒有關系。這類的導因為果的聲音對我們而言就像...嗯，就像有人在推銷一些東西。
直接的比較這些循環論法(circular arguments)是我們的經驗；我們的經驗中有許多錯誤癱瘓項目的方式是「我認為那是紅色的（或可能是津貼），而你認為是藍的（或可能是扣項）�！勾朔N不明確說明的假設進入程序代碼并且被證明其本身是潛伏的臭蟲。當這些不明確的假設進入架構本身，我們主要看到的是詛咒并且重寫（及重測試）的動作。
我們并不相信任何宣稱任何事可以使得這項工作免費的。拆解并重寫絕不可能是免費的。如果拆解并重寫是『常態』的，也不可能是免費或便宜的�？赡苁沟们�異乎尋常的平坦，但仍然不視線性的。我仍未看到任何證明Barry Boehm所做的研究是虛假的，他的研究顯示當你從分析移動到發行產品之間修正一個錯誤的成本是以指數遞增。重復宣稱成本曲線是不可思議的平緩并不能成為事實。
--------------------------------------------------------------------------------
明顯缺乏可達成性(Scalability)
讓我們看看為什么XP相關一個項目時似乎不像可以達成并且成功；其中這些條件似乎尚未出現。
--------------------------------------------------------------------------------
Pair Programming
在理想的XP項目當中，開發者是成對的工作，而且也不是靜態的成對：依據哪些事要做而誰知到怎么做，人們可能變換伙伴一天好幾次。這個想法；當然；是立基于格言「兩個頭腦比一個好(two heads are better than one)」。就其本身而論，嘗試去遵守這個原理是非�？植赖�。
但當你無法在一段有意義的時間內讓你所有的開發者同在一個地方；在一個『牛欄』內（假設有一個可用的地方）；會發生甚么事？事實上世上有許多開發者并不是真正喜歡這類的堅強的溝通及社交技能；而這些在XP架構下是很明確需要的；面對這個事實你要怎么辦？當每一個人為每一件事情爭功時，你如何掌控任何人的應負的責任？
如我們在這本書所描述的，最好的方式包含在高階及初階人員之間實作一組檢驗及平衡，例如；我們建議比較沒有經驗的人審查系列的圖形；這些開發者使用重要的OO專家產品。雙人組程序設計顯示出這個想法到一定程度，但雙人組程序設計同時假設一對一配對總是可行的；而這個簡單的說在許多背景中并不是實際可行的。
嗯--可能如果那是稱為雙人組分析、設計及程序設計，我們將會比較滿意...。
關于雙人組程序設計并沒有任何事是天生邪惡的--還是可能獲得一些利益--但雙人組程序設計對我們而言看起來是意圖補償分析的缺口；因此強迫兩個人檢視他們所撰寫的每一行程序代碼。這類似強迫幼兒園小朋友走向餐廳時兩兩牽手因為你無法信任他們不會毫無目的的隨意漫游。
以另一個方式來看：我們兩個一對下棋天生的每一盤棋都一定輸給Garry Kasparov，既不是伙伴系統也不是『詳盡的測試』可以補償前置規劃的缺口。畢竟，Garry非常小心的規劃他的策略。
--------------------------------------------------------------------------------
索引卡
XP一族倡議使用類別-責任-合作卡(Class-Responsibility-Collaboration (CRC))。目前；這些卡被重視并廣泛的使用--但只限于相當小的規模。CRC卡的設計確實不是用來擷取特別的細節，而像我們做研究論文在我們發掘內在的知識之前使用都是不錯的，它們是保持記錄的佼佼者。而你如何期望在有一段距離在開發者之間傳遞索引卡？
我們客戶中之一有位主任建筑師花了許多時間與其它的程序設計師工作。事實上，他花了太多的時間以致于他沒有足夠的時間給他的新材料他需要做的，這使得他相當愿意參與獲得一些他的設計文件。很不幸的，這家公司的開發者位于兩岸，因此整個「每一個人在一個大房間中共享索引卡」的想法是有點距離的。使用E-mail傳遞 模塊對他們而言將是較好的方式。同時，我們相信客戶在下一版本的產品中使用塑模做更好的工作會是相當成功的， 同時透過提供更可視化于架構及設計他們將能夠明顯的降低他們的延遲次數。
我們看過非常少的開發成果而沒有一些頗為嚴肅的議題需要除里。尤其是快速成長的公司；其中新項目的大小較之剛開始時更是快速的成長。我們建議使用一個好的可視化塑模工具把開發的工作放在顯著強壯的基石上而不是做一串蘇散四處漂浮的索引卡。
--------------------------------------------------------------------------------
缺乏責任性
XP擁戶者堅持大設計趨于只是讓人們；理論上；有特別的知識及技巧以執行確定的任務（你知道；這個團隊必須包括類別庫及一個架構設計師及一個技術撰寫者等等）。于此，XP說「每一個人做每一件事，」以直接響應對于『大設計占便宜的事實是有些個別的人比別人較有資格做某些設計決策』的認知。但現在我們會相信開發者將都會立即變的熱衷于必須真的以讓新人可以獨立了解的方式寫下東西嗎？（同時；不管如何；有好的設計者執行設計有甚么錯嗎？）
事實上，如我們將在在本文后面探討的，XP擁護者宣稱適當的重整(refactoring)程序代碼是或多或少自我文件化(self-documenting)，而所有其它的文件形式太不可信賴而值得存在。這是他們對于『口頭的傳統(oral tradition)』太過于聚焦的部分合理化，同時他們認為保持東西是如此重度的依賴讓所有的關鍵信息被維護在同一個地方。畢竟；程序代碼外部及所有這些索引卡；并沒有變成任何文件上的東西，對不對？但那只是沒有務實的思考這是將為任何項目工作；而有更多的開發者聚在一個房間之內。不錯；溝通管道的數量在人們加入項目時以指數方式增加，同時；我們在本書中倡議一個相當簡易(minimalist)的方式，但XP的方式只是太過簡易而無法在所有的項目中可用。
--------------------------------------------------------------------------------
一個XP替代方案：『聰明制程(Smart Programmers(SP))』
一般而言，多數我們的客戶對于這種沒有大小限制(scale)的解決方式沒有太多的興趣。不管如何；如果小規模(small-scale)解決方式是你所想要的，這里有一個Doug曾經經歷過的；這是本文中的一個目的我們稱之為『SP』。
如果你是靠自己的力量經營一家沒有太多可冒險的資本的公司SP是非常有用的。它的基礎理論是所有程序設計師中5％（或更少）做95％（或更多）的工作，而且只有只有這些（5％）程序設計師值得聘請。
SP的本質如下：
只需聘請前面5％執行的人是你個別認識的，或你信任的前5％的人員。
讓一個主任架構師(chief architect)非常小心的規劃軟件工作單元架構；如此單元（即UML包裹）之間有極小的耦合性(coupling)。
讓主任架構師比對SP成員的特殊專長及經驗。
讓所有的SP程序設計師在家工作，在家中他們不會受干擾，除非他們明確的要求在一個共通的工廠中工作。
限制狀況報告為半頁，并透過E-mail每周傳送一次。
讓你的SP成員當他們認為他們已完成時導入漸進式建立測試。
限制(restrict)SP開發者在需要的時候只能透過E-mail或電話溝通。絕不要把所有的程序設計師同時帶進一個房間內；除了在整合測試時，以及只有在他們的程序代碼是完全的含入。
現在，你可以以這種方式建立非常大量的程序而只使用非常小的團隊。Doug的經驗指出生產力水準更高過于XP所舉出的克賴斯勒薪資專案。
此外；生產力將比XP所產生的更高。不管如何，嘗試讓主任架構師跳過分析及前置規劃，或做了一個壞的聘請的決定，你會在你手中產生一個災難。我們絕不會麻煩的使之形式化或甚至命名，SP技術因為其沒有大小限制及沒有錯誤的限度。就我們來看像XP可能也如此裝腔作勢。
<譯注2>
--------------------------------------------------------------------------------
響亮但問題重重的口號
如果你想要的是一個立即讓你難忘強而有力的口號，XP正是指引你一條路。畢竟，就如XP的訓練現在已經很清楚，「軟件也是...很難花費時間在沒有意義的事情上，」這類的主題很容易變成一種口號。讓我們看看一些XP人呼喊整體重新整合相關的關鍵慣用語(phrase)。
--------------------------------------------------------------------------------
只有四件關于軟件重要的事情
這是最大的一個，XP存在的理由。這四件事是甚么？撰寫程序、測試、傾聽及設計（從前的重整(refactoring)）。
喔，同時別忘掉：「這里所有的都是關于軟件，任何人告訴你的與此不同都只是在推銷東西�！�
就如我們之前指出的，『分析』并沒有使得時間縮減。（這可能是Beck在OTUG有些事情與某件事情：「我以真正的名稱稱呼分析：說謊�！梗└匾�，既使，博學多聞的人知道關于軟件恰巧有七件重要的事。（我們不想在此分享，但在我們的書中可以找到，如果先前你不是很有知識）
盡管；嚴肅的如此熱烈的宣稱軟件開發只有四種元素是有意義的；是極端的超越現實，甚至還有些事情稱之為XP。
--------------------------------------------------------------------------------
原始程序代碼就是設計
我們承認從這個得到相當大的刺激(kick)，這不是最不重要的因為我們曾寫個一個笑話「使用案例(use case)不是需求」；而在我們的書中有類似的。在Wiki的首頁上中的評論像「當你重整，你是在進行細節的設計」，這就像我們將在另一本書中做的那至少有一個章節說明針對駁斥這類的廢話。
重整是一種極為迷人的主題，我們希望在Martin Fowler的書中證實。我們確認那將提供我們許多有用的技術以改善我們的程序代碼。但設計是設計，而撰寫程序是撰寫程序，把他們視為相同的一件事是愚蠢的。UML之神（好吧，三個其中之二，不管如何）基本上忽略初步的設計是很不好的，現在我們必須處理Xtremist狂熱的扭曲細節設計的概念而超越所有的認知。
每次我們看到爭論我們喜歡總結如「改變程序代碼是那么的便宜；不管我們是否從設計做起�！刮覀兌紩械轿竿�。這正是我們要嘗試指出是甚么導致的種感覺及去嘮叨這件事。
在XP，『甚么(what)』描述是從使用者故事擷取。我們關心的是項目團隊如何處理跨越『甚么』及『如何(how)』之間的差距�？梢姷睦碛芍皇窃赬P中漸進式發展(increments)是如此的微小，對每一個漸進式發展階段，介于『甚么』及『如何』之間的差距不僅必須跨越設計層次；那是很難滿足的；同時包括程序代碼層次。這表示設計錯誤及程序代碼錯誤將被混雜(intermixed)。
不可避免的時間將花費在修復程序代碼錯誤以便讓程序可以執行及測試，而測試將暴露設計錯誤。設計一經改變，所有花費在修復程序代碼錯誤及測試程序修復部分的精神及時間都將浪費，因為程序代碼現在要被詛咒(ripped out)并取代。在新的程序代碼當中也將有新的程序代碼錯誤，而前面的步驟還會再重復。這看起來還是OK，因為程序設計師在程序設計中『獲得樂趣』。
使用哪種方式并不是說無法達成--但對我們而言，哪似乎要完成工作需要浪費許多精力及時間。
如果我們沒有嘗試盡我們的可能做最好的事，所有的時間（而這應包括我們撰寫程序代碼之前），我們都是馬馬虎虎。如果我們認為馬馬虎虎的工作是OK，只要我們快速的工作（「喔，沒關系，我們隨后可以修改」），我們得到的是一堆垃圾。軟件不是與其它的努力(endeavors)在這個觀點上有不可思議的差異，不管你有多好的重整瀏覽器。
在你開始撰寫程序代碼之前只要證實設計是正確的，你對于項目審查會有最佳的概念，最好的是在初步層次(preliminary level)（以便確保沒有人朝向錯誤的方向快速前進）及細節層次。然后你才開始撰寫程序并曾測試獲得回饋。
--------------------------------------------------------------------------------
做可能達成的最簡單的事情
這個口號說你應該簡化、簡化、簡化。 避免傾向與把你不真正需要的材料構筑入你的程序總是一件好事。但是，我們關心的是那很可能是盡力鼓勵開發者把Scotch影帶、泡泡糖、橡皮筋雜七雜八的東西隨意放置在程序代碼中；這種程序是由為充分小心的花時間定義一個堅固的架構所逐漸形成的。
我們最近有一個經驗；其中我們經由反轉工程(reverse engineering)的工具吸收一些『已完成(as-built)』的Java程序代碼并且發現有些方法其名稱向bugFix37。很不幸的，任何創造這個方法的人是做可以達成的最簡單的事，那只是相當字面上的意義。（我們只能從它的搭擋程序設計師聽到回響，歡興鼓舞的說「嘿，我們正期待做可以達成的最簡單的事，不是嗎？」）按照紀錄，這個有問題的項目不是以XP所建立的，但那是以沒有正式的分析及設計所構筑的。
XP其它的指導原理并沒有幫助如：如果你認為你可能并不需要的，你并不需要。這類事情有助于鼓勵這類與世隔絕(insular)的相法；這種想法導致軟件并沒有解決任何位于外界人認為值得解決的問題。我們引用Ron Jeffries的話來加強這個概念：「一個開發者真正需要開始認真工作是直到她已開發她自己的內在品質的意識(sense)，我不期望我的符合你的；我真正希望我們與他們有足夠的接觸；我們可以與他們討論并使用我們不同的意識選擇一個解決今日滿足我們兩者內在的尺寸的問題�！贡У�，在XP除了程序代碼每件事都是可視的，我們剩余的期望只是品質保證。
我們還認為一個系統的品質最好是經由耦合性（愈疏松愈好）、內聚力（愈緊密愈好）及完整性的衡量來反應，加上思考像每一類別加權(weighted)方法及子類別投入的數量作為好的衡量。參閱我們的書第5及8章關于至方面的作法(metrics)的更進一步信息。
--------------------------------------------------------------------------------
Xtremist 故做姿態
從另一方面而言，XP人喜歡廣泛的爭辯關于是否『勇氣(courage)』或『進取心(aggressiveness)』是比較正確的說明就處理這些麻煩(pesky)的付錢的人而言他們所處的位置。
從另一方面而言，XP人傾向迷失在新鮮的空氣及說一些事如：「XP大師(Master)了解的如此深刻以致于他們無法被了解」
XP的花言巧語讓我們覺得那是結合相當高程度的傲慢并且試圖模糊使得變得很奇怪。
--------------------------------------------------------------------------------
準備、射擊、瞄準
就如統一開發程序(Unified Process)描述的四個階段（反復(iteration)、精細制作(elaboration)、建構(construction)及轉換(transition)）；這些在在項目的每一個反復中執行，XP說的是「故事(stories)、測試(testing)、撰寫程序代碼(coding)及設計(design)」。強烈的與大設計比較；統一開發程序符號表示法(symbolizes)，XP方法論提供『微量漸進式發展(nanoincrement)』，它的基礎是不超過一周的漸進式開發，甚至是短到一天。更快、更快、更快！
我們不反對找到軟件開發程序更快速的方法--只要這種方式產生的結果不是「準備、射擊、瞄準」。<譯注3>
由于拒絕花任何一些有意義的時間指出在開始『生產』之前應做甚么，并且堅持在一個進行中的基礎下『以小的方式(in the small)』做大的工作(great work)；從某種角度當煙幕消散時將神奇的產生整個系統被矯正，XP人似乎認為他們已找到銀色子彈(silver bullet)<譯注4>以反擊大設計的假設：偏向于在細節部分陷入泥沼。
這是一個很明顯的短視(short-sighted)方式。我們可以以分析及設計到一個非�？山邮艿膶哟谓档褪〉娘L險而無須把身體連同洗澡水拋棄。早期進入程序代碼撰寫并不代表沒有風險；這個風險只是不同的本質（在某些情況可能更難以捉摸）。我們應該嘗試最小化項目整體的風險層次，而不是部分的風險。
當Doug七年前開始教授OOAD，最通常的失敗點是在 訓練研討會(training workshop)；總是發生在從需求層次（使用案例）系統行為觀點移動到一個細節設計層次（循序圖/合作圖）行為觀點所做的努力。 嘗試跳過這個階段--在這本書中我們稱之為跳過『甚么-如何(what-how)』的差距--從一個純需求(pure requirements)觀點到一個細節設計觀點是異常的困難。人們總是發現的是經由增加動態模式（堅實的分析(robustness analysis)）的『初始設計(preliminary design)』觀點，他們持續能夠讓團隊通過這個轉換點。
我們仍然能夠平衡漸進式開發的利益（可能使用一些較大的漸進式程序），嚴格的測試及其它可能被證明有用的技術，如雙人組程序設計。以這種方式，我們保證我們不止將會總是擁有一個執行的方案(functioning program)，同時我們可以讓最好的開始是『一開始就朝正確的方向』，同時減少對以這種勞力密集(labor-intensive)方式重做及重測試的需要。
--------------------------------------------------------------------------------
文件是無用的
一個真正的Xtremist相信程序代碼不只是設計同時是文件�！簾o情的重整(Merciless refactoring)』（另一個XP用語）將一直一直一直產生完全干凈的程序代碼；既使是最沒有經驗的開發者也能夠達成。一個信徒杜撰了一個名詞『極端的清澈(Extreme Clarity)』，其中他定義為「一個程序的屬性就像程序代碼展示每一個人需要知道的系統所有東西；立即上手；一目了然；非常的準確(accurate to six places)」
我們沒有強辯這不是一個我們想要的結果。而就非程序代碼(non-code)文件而言，維持與想象中的快速撰寫程序代碼機制同步的可能性不是真的嗎？而口頭的溝通比在多數項目中寫下來的作用好不是真的嗎？總而言之，「所有的文件要被懷疑是過期及主觀的偏見」這些聲音對我們而言就像一個無理的對文件的恐懼。
事實上，在一個開發成果的背景，夠格的技術撰寫者知道一些相關程序代碼的東西將通常能夠趕上開發者及分析者并且維持到目前為止。同時，有效的口頭溝通是關鍵性的重點，但不能免除把數據寫下來--為外部的人、為新人、為未來的參考者、為某些目前可能不是很明顯的原因。就主觀的偏見而言，嗯，所有的寫下的都有某種的偏見，但軟件文件設想是傳達是甚么(what is)，而不是可能是甚么(what could be)，同時如果那不如此做，不是媒體的錯誤。
除了口頭溝通任何事物的缺乏表示撰寫程序代碼的人必須回答問題。
依據歷史觀點，在近半世紀被無數次用作為『工作保障(job security)』的機制。在太多的案例中，這些人把文件放在他們的腦袋中（或者是團對把文件放在他們集體的腦袋中）在維護程序設計師出現時已是過去式了。
這里有一個Doug的故事
「我有一個程序設計師為我工作，負責我們的數據流圖編輯。他的進度常常延遲。我們開會討論這種情況。他說--我引用他的話而我記得非常清楚：『你不能讓我更快，你不能讓別人來幫助我，你不可以解雇我』他很有信心的說，因為所有的設計文件都在它的腦袋中。我非常震驚于他的說法，第二天我解雇了他。這是我做的決定中最好的一個。我以一個人取代他，這個人所寫的程序代碼非常好，而且隨時把他所做的記入文件中�！�
不管如何，為后人記錄圖表并不是十分重要的事。檢視(reviewing)圖表--并據以設計--在撰寫程序代碼之前是十分重要的事。如果你能讓團隊中的高級程序設計師檢視（并修正）系列的圖表中將要撰寫程序代碼的情節(scenarios)，同時你在撰寫程序代碼之前已查核(verify)架構（靜態模式）可以支持所有的情節，你將有一個比較輕松的撰寫程序及測試的時光，同時你將使得后續要做的拆開程序代碼、重新撰寫程序代碼及重新測試的工作降至最低。
而這里有從Beck所說的：「多數的人表達他們的恐懼；就是把CRC卡轉換成數據庫（Notes或Access）、Excel，或某些該死的項目管理程序�！挂虼宋覀儸F在看到XP人把客戶視為不確定（考慮他們的需求時）并且恐懼（就持續追蹤將要發生的事）。我們期待XP信徒(XPites)證實他們的『懷疑』如此XP可以假設擁有傳說中的FUD(恐懼(Fear),不確定(Uncertainty),懷疑(Doubt))三位一體，如以往對微軟的觀感一般。
--------------------------------------------------------------------------------
詢問程序代碼
我們很高興的承認程序設計還是有某一程度的『藝術』的成分加上『科學』的元素這個觀點；這個觀點是我們更想要聚焦的。但有些Xtremists的說法傾向于讓像我們這類非信仰的人覺得XP或多或少有個人崇拜的現象。舉例來說：
「重組系統結構(Restructure the system)的基礎是系統告訴你的系統想要被如何結構化�！�
「程序代碼要簡化�！�
「系統駕馭(ridding)我更甚于我駕馭系統�！�
「程序代碼異味(smell)是你程序代碼當中某部分變糟的暗示(hint)。使用這個異味追蹤問題�！�
「詢問程序代碼�！�
這個概念；很顯然；是只要程序代碼實現，便假設有一個神秘的溝通力量，而建立者義不容辭的傾聽；小心的聽；這個聲音...你會非常想睡...啊，抱歉。
這些說法其根本是就Kent Beck而言所有的內容就是程序代碼，整個程序代碼，除了程序代碼以外沒有別的。設計代表『幻想(visions)』，分析代表『幻想的幻想(visions of visions)』，而方法論就是整體代表『幻想的幻想的幻想(visions of visions of visions)』 ，以及「當...幻想成真只會惡化問題』。只要開發者的思考是簡化的--另一種說法--只要他們能夠只寫他們的程序代碼而無須所有愚笨的前置材料--他們將「沒有壓力的工作、沒有恐懼的工作并喜愛他們的任務及他們自己�！�
有人要來一杯Kool-Aid嗎？
--------------------------------------------------------------------------------
結論
XP人喜歡抱怨是如何的沒有其它的事。例如，當Doug在OTUG開始指出前置分析是多么好的事情，他得到不只一封的電子郵件詢問「你寫多少的程序代碼，無論如何？」這意涵他寫的程序不夠多；在Xtremists的眼中不是夠格的『真正程序設計師』； 擁有像水一樣多的概念卻說他不懂得UML的『擴充(extends)』建構式(construct)（我們的書的讀者，忠實的OTUG人，已經到這個胡說八道的故事），但這不是重點。重點是XP的擁護者有一種齷齪的傾向羞辱我們是比較喜歡不終極(less extreme)；但仍然高度的可運轉(workable)；盡量建立有品質的軟件--而那是太差的，因為有一些好的要素(stuff)在其中。
可能有一天我們將看到一個更合理及平衡的開發程序形式。于此之際，我們同意一位在Wiki的仁兄所言「XP最引人注意的特性是它嘗試駕馭(ride)；而不是壓制(quelling)在任何真正的程序設計師內心中深沈的要求，那就是要求開辟一條大道(urge to hack)。
于此之際，我想要以一個問題結束這篇文章。
假如你決定在你的項目中使用XP，而在六個月之后，你覺得這種方式并未符合你的期望。而沒有寫下任何東西--沒有架構或設計文件及在開發者腦袋中沒有項目的任何知識。你會怎么辦？
Doug Rosenburg：dougr@iconixsw.com
Kendall Scott：onSoftDocWiz?@aol.com
--------------------------------------------------------------------------------
<譯注1>大設計亦即前置設計(upfont)，相對于XP的其它開發程序；這些其它的開發程序在開始撰寫程序代碼之前將所有項目架構做完整的設計被XP追隨者稱之為大設計或前置設計。
<譯注2>SP應是作者故意創造用以反諷XP的一個名詞。
<譯注3>對于這點Kent Beck及Martin Fowler在『Planning eXtreme Programming』一書中第三章有所說明。
<譯注4>銀色子彈亦即中文的萬靈丹。
http://www.dotspace.idv.tw
文章來源于領測軟件測試網 http://www.kjueaiud.com/
