|
來源： Mark Collins-Cope訪問Robert C. Martin（ObjectMentor總裁, 物件導師(Object Guru), 『 C++ Report 』的編輯及『 Designing Object-Oriented C++ Applications using the Booch Method』的作者）有關於他目前對於XP的支持。
|
一般問題 |
|
[Mark Collins-Cope] Bob, 你目前對於Kent
Beck's eXtreme Programming對於軟體開發的方法論相當支持。 由於你是使用UML的提倡者或至少你已廣泛的撰寫UML的文章；而您的支持XP似乎令人感到訝異。對於那些對此感到訝異的人你有甚麼意見？
|
|
[Robert Martin]對於這些訝異我也感到很訝異;-). XP與 UML並不完全互斥。我仍然是UML的擁護者，我將持續使用UML並且撰寫有關UML的文章。
XP是一個開發程序(development process). XP對於UML並沒有說些甚麼。有人說使用XP的人(XPers)不使用UML來組合他們的模式概念。無論如何，並不是這樣的。在XP，我們還是要建立模式；同時我們還是要設計我們的軟體。當然我們可以在設計中使用UML。 XP在分析與設計的方式有一點不同。不管如何，UML產生的圖形（或者任何你使用的其他塑模方法）只有很少的例外情形是XP在生產他們的程式碼時所忽略。XP將價值放在程式碼以及使用案例(use cases)，並忽略中間步驟。 P
|
程序及表示法 |
|
[Mark]目前開發程序在軟體開發社群中是一個熱門的重點。我們有RUP, Open, Catalysis, XP 等等，所有者些方法論似乎都對世界提出相對立的觀點。甚麼是軟體開發或管理的平衡可以提供？對於軟體開發是否有甚麼事情是正確或錯誤的方式？
|
|
[Bob]是的，有。正確的方式是在最少慌亂的情況下達成任務。Kent Beck在開發程序有相當敏銳的觀察 。開發程序就是關於管理恐懼。我們把開發程序放在正確的地方是因為我們恐懼。如果我們恐懼是大的我們在適當的地方使用大量(big)的程序，如果我們恐懼是小的我們在適當的地方使用少量的程序甚至沒有使用程序。對於特定團隊程序是否是正確的是視程序平衡他們的恐懼與企圖心。 XP是適用於有企圖心的團隊；他們希望快速的使產品進入市場。XP管理者恐懼使用人的方法(people methods)而不是紙上作業的方法(paper method)。在XP；對於速度的恐懼經由雙人組設計,撰寫大量的測試,（至少每天）與客戶溝通得以減低。
|
|
[Mark]所謂管理恐懼；我假設你的意思是害怕專案失敗,不良的設計等等。有些恐懼的原因--例如過去的失敗。在這種情況，難道沒有好的理由好好的在專案生命週期中定義查驗點(check
points)以便在失敗變得難以收拾之前發現並解決。
|
|
[Bob]查驗點是一個好辦法，當某些事是好的時，XP將旋扭轉到10。（譯註1）這就是為什麼XP之所以『終極(extreme)』的原因。所以在每幾分鐘就有一個查驗點。我們每幾分鐘就執行測試以確保系統仍然是正確的行為。我們每幾分鐘重新考慮我們的設計並在需要的時候重組(refactor)。我們不時重新評估(re-estimate)我們的進度並且重新對計畫重新排列優先順序，因此我們不會在延遲的假設下工作。
|
|
[Mark]你會稱XP是RAD技術嗎？為什麼？
|
|
[Bob]不，RAD技術處理恐懼是依據開發者希望被鼓舞到某一層度愚笨的假設（譯註2）。XP並不是高風險的開發程序。他跑得很快，但也很安全。 XP由測試控制。只要多少行的測試程式碼在XP專案中便有多少行的產品程式碼。只要我們作任何改變那麼測試就隨時要執行。他們告訴我們當我們破壞一些東西 ，在XP檢驗未通過『所有』測試的程式碼是不合規定的。因此，程式碼絕不會有重大的破壞。
|
|
[Mark] UML現在包含8種表示法(notations)。你是否覺得UML有點龐大並且包含他本身的所有優點？XP的出現會有些事情衝擊這點及更重量型(heavyweight)的開發程序定義嗎？
XP是從正式的(formality)程序比較大的擺盪到非正式(informality)程序的一部份嗎？
|
|
[Bob]UML的大小(size)並不是一種傷害。開發者並不會乖乖的使用UML表示法的所有部分。相反的我們只選擇我們需要的並且忽略其餘的。因此我很高興UML是龐大的，因為UML給我們一大堆的工具可供取用。 我認為像XP這樣的輕量型的開發程序是有一部份衝擊龐大正式的開發程序。開發程序在最近多十年來變的愈來愈大愈沈重；同時沒有明顯的增加軟體的品質來支援成長。就如軟體工業所說的「喔；我們的巨大開發程序並沒有帶給我們所需的利益；我想要讓開發程序更大一點 。」 我們之間許多人都已經忘了對抗逐漸肥胖的發展程序多年了。我想XP我們之間充分瞭解發展程序成長的人所發的一種陳述。 從另一方面而言，認為XP是自正式化(formality)或有紀律的(discipline)特性偏離的想法是一種誤解。XP是以程式碼為中心(code-centric)；同時有一些更正式的編輯程式。XP也是有高度紀律的。XP的實務有非常精細的特徵(narrow parameter)，你不能只決定不做他們。（譯註3）
|
|
[Mark]所以程序的欠缺並不能歸咎於採用較大型開發程序而導致軟體失敗的原因 ，你會歸咎於哪一部份？
|
|
[Bob]目前使用的開發程序注重文件而比較不注重人。文件無法思考，文件無法解決問題，文件無法因應改變而調適。我們可以安排我們所要的查核進度，我們可以產出所有我們要的分析及設計文件，我們可以合作並交叉檢驗及規劃我們所喜歡的。但只要人們被考慮為開發程序中第二順位的元素，這種開發程序將會失敗。 Alistair Cockburn說的最好，開發程序是成功結果的第二順位。第一順位是人。XP重視人。XP提供一種框架其中人們可以有效的溝通。就如Kent Beck所言XP是企圖讓他說明真相而達到成功(XP is an attempt at making it OK to tell the truth.)。
|
|
[Mark] 引用Ralph Johnson所言（這是聽說的）XP開發程序是分析....測試....編寫程式碼.....設計....你認為這是真實的描述XP嗎？
|
|
[Bob]不。無論如何，那只是一段差強人意對於XP開發插曲的描述。一個開發的插曲可能延續計幾小時。 一個XP專案充滿上百個小的微反覆(micro iterations)。其中每一個反覆包含分析,測試,編寫程式碼,設計。其順序是重要的。首先要瞭解（即分析）；同時也包含一些設計。然後我們撰寫測試案例(test cases)；它描述我們所瞭解的。撰寫測試表示我們同時必須在我們心中有設計的程式碼，然後我們撰寫可以通過測試的程式碼；同時當然有一個設計的元素包含於我們的撰寫程式碼。最後我們重組程式碼使之盡可能的簡單(simple)及乾淨(clean)。所以在這四個步驟當中都有一個設計的觀點(aspect)。
|
軟體架構 |
|
[Mark] 在系統整體軟體架構(software architecture)（包裹結構(package
structure),架構層次(architecture
layering)等等），您一直是應用程式的好的設計原理的倡議者（非循環相關(acyclic
dependencies),介面隔離(interface
segregation)等等）。系統的架構（這裡所定義的）是XP的風險嗎？系統隱喻(system metaphor
)的概念似乎不是；對我而言至少不是；等同於架構的定義，這一點你的想法是如何？
|
|
[Bob]架構大概是任何軟體專案單一最重要的觀念。每有一個好的架構，一個系統墮入泥土中的顫抖水珠。我開發軟體所使用的任何開發程序將是盡可能以產出最佳的架構為中心。 XP有一個架構的步驟即眾知的系統隱喻。隱喻的概念並不能代表架構完整的面貌。相對的它是架構的結晶結構(crystalline structure)將要成長的種子。 架構無法於儀式(orgy)的前置設計中充分的決定。架構；像其他軟體環境中的所有事物一樣；必須發展。XP提供頻繁的反覆，而架構著重於確保強壯的架構隨著軟體成長逐漸發展成型。 在XP中的規則有部分著重開發者維護及發展架構。簡單化的規則,溝通的規則,程序的規則。如果一個模式不是在他們所知的最乾淨,最簡單化,最彈性的狀態下開發者並不允許登入(check in)一個模式。開發者在任何時候當他發現重複的程式碼必須立即拆除。開發者不得單獨工作，必須成對的工作，因此他們可以彼此要求架構的議題。
|
|
[Mark]我同意你的意見有關於架構是重要的，同時你好像不是把一個架構的所有的概念擺在最前端。但把一個架構系統擺在最前端的觀點並不是壞事，是嗎？
|
|
[Bob]不，一點也不。這就是為什麼我們在XP建立一個系統隱喻。那有為什麼每一個發行都以探索的步驟開始，同時每一個反覆以重新評估目前的設計及架構開始。
|
設計 |
| [Mark]「做可以達成的最簡單的事」是XP的設計格言。如果多一點事先的考量(forethought)及少一點立即性(immediacy)，重組現有程式碼的必要性便可以避免，不是真的嗎？有一個相關的觀點是一個方法論調適得多『完整(holistic)』？完整性(holistic)；我的意思是相對於『一點一點的(piece
by piece)』--以一個比較寬廣的功能需求觀點並嘗試設計一個解決方式可以涵蓋；譬如；5個需求而不是一個。
|
|
[Bob]以『多一點事先的考量』是可能的，我們可以減少一些重組的動作。所以為什麼我們選擇重組而不是運用事先的考量？簡單的說重組是比較便宜而且比較可信賴。 我不是說事先的考量沒有價值--確實如此。但是事先考量是不確定性(speculative)。而且把時間花在不確定的冒險是比把時間花在確定的冒險昂貴的。因此我比較喜歡重組的安全性(surety)而不喜歡長期的事先考量的不確定性。 因此；在每一個任務的前期；我會設計任務，並確認符合目前系統的架構。我會撰寫測試，我會撰寫可通過測是的程式碼，然後我會再次檢視程式碼並且重組，一小步一小步，直到我認為這個設計是好的。沒有長期的不確定性，只有短期的安全性。 這會導致革命嗎？當然是！當重組的方法在一個局部最小值(local minimum)（譯註4）得以理解便將是時候了。此時會有一個比較好的方法應用於整個系統，但需要局部最小值更多的努力及更進一步達到總體最小 值(global minimum)（譯註4）。只要這類需求被界定，使用XP的人便勇於重組到新的總體最小化。他們不會害怕的原因是：
經由一些事先的考量避免錯誤可以變成更好的設計（總體最小化）嗎？或許吧。要有多少的事先考量才能確保你都已找到可能的變數？事先考量你要付出多少？哪為什麼要事先付出？XP的哲學是：當你需要時為你所需的付出，而且不要在你需要之前。
|
|
[Mark]但如果你正需要一個特定的設計結構來涵蓋下兩個你要做的需求，難道你不會事先投入一些額外的工作來涵蓋它嗎？而且重組是否真的比設計來的便宜嗎？
|
|
[Bob]你的結構設計是否正確？如果你尚未實作其中之一的功能你如何保證結構設計是正確的？你可以確認實作你認為設計應有的樣子會比較便宜嗎？或者當你需要它而且立即需要時才實作設計會比較便宜？XP選擇後者；其假設是事先付出在推測平均而言是較即時的付出於你當時正需要的更為昂貴的。XP證明這點其認為重組於豐富的單元測試及雙人組程式設計是非常便宜的。
|
|
[Mark]我們都知道設計是困難的。思考設計是困難的，而且確實比撰寫程式獲得更少的立即回報。我個人的經驗雖然是軟體設計得到基本的正確要付出很多（這裡我的意思是經過2到3個月的時間），而XP沒有『做到設計(design
deliverables)』本身，設計不夠充分不是更危險？
|
|
[Bob]否。一點也沒有危險。事實上，設計在XP環境中是非常旺盛的。XP可以說就是設計。我們持續驅動程式碼到我們所知的盡可能好的設計。我們絕不會說「我們要後退並隨後修復。」 設計是如何我們必須達成協議。一個程式的設計是其程式碼的樣子(shape)。切割(partition)程式碼成為方法,類別,包裹等等，及存在於這些元素之間的關係。我們可能以圖形展示這些東西，但圖形不是設計。他們只是設計的代表物(proxies)而已。真實的設計是在程式碼？XP不重視設計的代表物。XP重視的是以程式碼直接表達設計。同時XP重視程式碼的可能最佳設計。 XP將最高的價值放在這裡，因而強迫我們撰寫測試以讓我們可以無畏的重組，也因此我們可以自由的移動程式碼朝向我們所認知的最好的設計。
|
|
[Mark]確實，我們工作的目標是我們程式碼的樣子是容易維護,擴充等等。同時確實，我們似乎有時需要調整(restructure)--重組(refactor)--我們的程式碼。我想基本上我擔心的是沒有明確的『設計』階段，你只是延遲在某一點你必須做的決定，既使我可以看到重視重組表示最終你可以到達。
|
|
[Bob]再強調一次，XP認為
為你未來所需就在現在付出是比為你所知目前立即需要的付出要昂貴的多。這種方式的風險是可能比事先考量的方式有更多的修正(rework)，也就是說其成本超過了事先考量設計的成本，而這個成本在整個軟體專案生命週期帶來了所有額外的無用設計。XP認為修正在有單元測試及雙人組程式設計的情況下不是昂貴的，而那是事先考量設計的成本；事先考量中錯誤的猜測及在軟體中帶著所有的事先考量設計的元素是昂貴的。
|
|
[Mark]有些在UML中的事物（類別及包裹圖）在較高的層次的抽象中貢獻檢視你的軟體的能力：把焦聚放在高層次的設計等等。在XP中缺乏設計焦點（至少以可做到的而言(deliverable
terms)）可能代表新一代的程式設計師並沒有看到高層次的思考的利益難道不是一種危險嗎？你是否提倡使用XP的人接受；例如；OOA/D及UML的訓練？
|
|
[Bob]對於後面一個問題答案是『是的，是的。』使用XP的人確實應該知道OOD的原理，同時應該能夠使用像UML的設計表示法。那是OOD原理的適當應用程式可以保持程式碼結構充足的彈性以便重組。尤其在C++中特別需要。沒有強烈的使用這些原理，C++程式碼將變得惡性的糾纏以致全然無法重組。 我是否遺漏關心關於高層次思考的？一點也不。在XP中有許多高層次的思考。在專案一開始便有，在每一個發行的開始，在每一個反覆的開始，及在每一個任務的開始。更甚者，軟體的高層次結構是由程式碼『暴露(exposed)』。在一個良好設計的OO程式，你可以從程式劈開(rip)低層次的明細而無須改變；或者甚至重新編譯；高層次的模組。OOD最重要的原理之一簡單的說：高層次模組應該獨立於低層次模組（相依反轉原理(The Dependency Inversion Principle)）。
|
|
[Mark]在甚麼方式下程式碼變的難以重組(resistant to refactoring)？
|
|
[Bob]如果你在一個模組做了一個單獨的改變，而迫使你重新編譯一個小時，這個模組便是難以重組。為了要容易重組你必須能夠快速的迴轉(turnarounds)（譯註5）。是甚麼原因導致長時間的重新編譯？不當的管理相依性。 使用XP，工程師總是對迴轉的時間非常敏感。如果一個改變而增加迴轉，他們必須重組直到迴轉變的很快速。
|
使用者介面 |
| [Mark]在何處使用者介面設計可以適合XP？XP對於一個系統可能有的介面品質有哪些影響？是正面還是負面的？你是否鼓勵一個使用者介面專家包含於此？
|
| [Bob]XP是一個軟體開發程序。使用者介面全然是一個不同的主題。我不會讓軟體工程師設計使用者介面的外觀(look)及感覺(feel)除非這各界面將要被另一個軟體工程師所使用。（而且可能既使是如此我也不會讓工程師設計這各界面。） |
|
|
|
譯註1：當某些事是值得採用時，XP便充分運用。
譯註2：RAD是讓愚笨的人也可以使用。
譯註3：XP的規則設計彼此之間有相當大的關連性，缺乏某一項實務特性可能導致失敗。所以不可隨意選擇要做哪些或不做哪些。 譯註4：局部最小值(local minimum)表示位於直角座標軸上的曲線之某點其前後的點皆大於該點，但該點不一定是曲線的最小值。總體最小值(global minimum)則代表曲線中所有局部最小值中的最小值也就是曲線的最小值。 譯註5：迴轉(turnarounds)表示回到原來為改變的狀態，亦即產出的結果是一致的。 |
翻譯： Areca Chen |
|
本文獲授權同意翻譯函： Areca, |
