原文鏈接：*-Driven* do not change anything

　　你曾聽說過一名專業軟件開發人員應該掌握一種驅動方法嗎？這些驅動方法可能是：領域驅動設計（Domain-Driven Design）、測試驅動開發（Test-Driven Development）、行為驅動開發（Behavior-Driven Development）、數據驅動設計（Data-Driven Design）、數據驅動開發（Data-Driven Development）、用例驅動設計（Use Case-Driven Design）、用例驅動開發（Use Case-Driven Development）、架構驅動設計（Architecture-Driven Design）、架構驅動開發（Architecture-Driven Development）、模型驅動開發（Model-Driven Development）、敏捷模型驅動開發（Agile Model-Driven Development）等等。我確實聽說過這樣的要求。

　　我們期待這些驅動方法（或者我稱之為心理框架， mental framework）具有某種魔力，是因為我們喜歡框架。我們常常忘了對于我們的技能，它們只是扮演支撐角色，而不是軟件專業的唯一目標。但是這種對框架的熱愛，使我們產生了一些認知上的偏差，讓我們進行深入分析。

　　心理框架是如何產生的？

　　這些所謂的驅動方法是一類被稱為心理框架工具的例子。心理框架，正如軟件框架，是一種構造（一些想法或者過程），能夠用于開發活動，例如以有序的方式進行建模、設計、編程或者測試。我們將分析三種心理框架：領域驅動設計、測試驅動開發和行為驅動開發。它們是社區中非常流行的驅動方法。

　　這些框架的創建者的假設是它們能夠通過以下途徑促進開發工作：

• 讓通用的想法（例如對象建模和測試）更具體；
• 引入有序的工作方法；
• 以可重復的步驟形式展現復雜的活動。

　　這一切都歸結為一個承諾和吸引人的文化基因

　　當作者提出一個心理框架，這意味著一個承諾，從現在起所有事情都將變得更好、更有效率、更快、成本更低，一切都將很好。通常，承諾與開發人員在運用某個特定概念的過程中遇到的問題有關系，而且它武斷地假定，當使用了這個建議的框架后，這些問題都將得到解決。測試驅動開發就是一個很好的例子。它的承諾包括：“你將不再需要調試器”，“你將有簡單和高質量的代碼”，“你的代碼在產品階段的bug會更少”。我并不是說這些是空頭承諾。我的意思是這些承諾并沒有在早年TDD中得到明確的、可驗證的數據支持。先有對TDD的熱情追捧，然后才有一些度量來驗證它的承諾。

　　是什么讓這些心理框架的承諾如此“吸引人”？毫無疑問，其中一個因素是我們希望解決所有問題。因此，當問題越大，我們就越可能采用它。另一個因素是有感染力的文化基因(contagious meme)。就像基因是遺傳信息的單位，字節是數字信息的單位一樣，文化基因是文化的基本單位。這個詞是由英國進化生物學家和作家Richard Dawkins創造，他將其視為一種復制器（replicator）。

　　每種框架都定義了自己的文化基因，有感染力的的口號，這讓開發人員將它與特定框架及其承諾聯系在一些。通常，這個文化基因描述了框架所促進的一個主要概念。TDD文化基因就是一個很好的例子，即紅-綠-重構（Red-Green-Refactor），它與計劃-執行-檢查-處理循環（Plan-Do-Check-Act cycle，縮寫為PCDA或稱為戴明循環）沒有什么不同。PDCA循環是持續改善產品和服務的一種迭代和適應性過程。紅-綠-重構，這個簡短的口號有以下特點：

• 它用三個詞表達了TDD基本技術；
• 它很容易記住；
• 它描述了可視化工具來支持TDD。

　　這三個詞使你用簡單的文字描述了TDD。你不需要提出精心設計的概念、詳細的定義和區分特定的案例或復雜的步驟。它很簡單，就是紅-綠-重構。

　　在表1中，我列出了心理框架的例子，它們的承諾以及它們的吸引人的文化基因。

　　表1　　

　　誰創建了它？

　　在建立他們的突破性概念時，Ken Beck、Dan North、Eric Evans、Steve Freeman、Ivar Jacobson和其它心理框架的作者們已經在各類項目、不同人群、領域和技術上積累了多年的經驗。那些生搬硬套使用這些框架（認為它將改變他們的生活）的人有哪些經驗呢？本文后面將再回到這個問題。

　　如果讓我改述一個關于建房子的流行說法，我會說我們的第一個系統是給敵人建的，第二個系統是給朋友建的，只有第三個系統才是給我們自己的。想想你的職業生涯，最初的編碼留下了多少坑。接下來你的代碼使用了很多潤滑和工程相關的東西，以至于你自己都不理解。再經過一段時間，你終于做到了中庸之道（有趣的是你無法平分成黃金比例）和實用主義。

　　根據Singley和Anderson的著作The Transfer of Cognitive Skills以及Woltz、 Gardner和Bell的文章Negative transfer errors in sequential cognitive skills，當你在一個項目上工作，又開始另一個項目的工作，你通常會體驗到知識遷移，意思是迄今為止你所掌握的技能能夠用于另一個項目，并且能讓你更有效地開發新的、有用的技能。這種遷移被稱為正遷移，是我們最需要的。然而，負遷移也是有可能的，因為掌握了一種技能可能使另一種技能更難掌握。

　　所有這些心理框架的作者已經轉戰于各種項目并有豐富的經驗。因此，他們體驗了學習的正遷移并獲得特定的知識、技能和專業技術。在某個時刻，他們經歷了我所說的“啟迪”（或者更常用的說法，靈光一閃、啊哈！效果或模式轉變）。這常常是偶然發生的，有時候是在夢里，觸發了思維過程的整個鏈條，啟迪了這些作者。基于經驗、思考和總結，他得出了一種思想，例如紅-綠-重構。這種思想把有序帶入現有知識中，并給它灌輸更深入和更普遍的意義。從技術上講，這是歸納概括（如圖1）。基于他的專業知識并通過歸納推理的方法，作者建立了一個概括其個人經驗的理論。然后他開始向世人介紹這個新的心理框架。他或她開始寫書。

圖1 心理框架是如何建立的？

　　歸納的結果

　　歸納有一個問題：它不能保證結論是正確的。這不是大問題，因為框架沒有必要邏輯“正確”，它只需要“在給定的上下文環境中是有用的”。現在我們來到了這個點，即上下文環境是個關鍵，它就是概括出新想法的那些經驗。當作者想分享他的探索，并開始寫書，新的未曾預料的問題出現了。如何在他不熟悉的其它上下文環境中使用框架？如何將框架應用于他不了解的項目、架構和技術中？他接下來該怎么做呢？他使用推論（如圖2）。

圖2 如何在別的上下文環境中使用框架？

　　基于他自己的經驗和想出來的這個框架，他進行推理和論證并得出結論，在這個新的上下文環境中，應該以特定的方式使用框架。在這個階段，不同類型的論證是必要的。歸納推理使框架能夠基于實際經驗。通過邏輯思維演繹推理該框架，避免其與現實沖突。當然，沖突是有可能的，但它可能要數年時間，并且競爭從未停止。

　　演繹推理在有些情況下能夠得出正確的結論。而另一些情況下，結果可能有所不同。有時候只需要重溫和回顧就能得出結論。Eric Evans的書《領域驅動設計:軟件核心復雜性應對之道》就是個例子，特別是戰略設計這部分。當我們觀察Evans先生的活動，我們將發現當他使用DDD時，他的結論是書中的部分觀點應該更準確或者應該換種方式突顯出來。我們發現了一些更新：介紹了Domain Language Model Exploration Whirlpool過程，特別強調有邊界上下文（Bounded Context）角色、領域事件（Domain Event）的更準確定義以及它與有邊界上下文更準確的關系。

　　誰能使用它？

　　當作者遇到新的、未知的環境，他的框架不起作用時，他會怎么辦？他將依賴自己的經驗，做一些小的嘗試，跟蹤其效果，然后對其想法做一些小修正。絕大多數情況下，心理框架的作者擁有豐富的經驗和相當專業的知識，知道如何面對新情況。換言之，作者明白如果框架的教條越多，則其價值將越少。基于他利用的是自己的經驗（這總是很方便）這個事實，如果他認為它是沒有意義的，他可能會立即停止使用他的框架。他會根據自己的經驗選擇別的解決方案，或者修改框架。

　　現在讓我們想像一下這樣一個場景。一個缺乏經驗的開發人員使用某種驅動方法，結果會怎么樣呢？當他按書中和網上的教程開始編程，一切看起來好像很順利。但事實上，我們幾乎不會去開發一個教程那樣的系統，很快問題就會出現。開發人員馬上就要面對下面的問題：如何在新的、未知的環境中使用這種驅動方法？我們的這名開發人員經驗很少，正在不斷犯錯誤，也在不斷取得成功。他沒有足夠的專業知識，他孤立無援。面對時間壓力，他可能會做以下事情：

• 尋求有經驗人士的幫助（這是最好的選項）；
• 開始努力嘗試并最終得出正確的方法（成本有點高，但可接受）；
• 在互聯網上尋找解決方案（不一定正確）；
• 以教條的方式使用心理框架，即使它沒有任何意義，也排除萬難完成任務；
• 停止使用框架，回到他的老習慣。

　　以上5種情形中，有3種情形的結果是令人沮喪的，框架相關的承諾并未實現。也許你認為這并不意味著該驅動方法沒有效果。開發人員只是沒有相關的經驗來正確地使用驅動方法。心理框架的典型特征是他們是非常通用的。很難寫一個適用于任何場景的詳細過程。我甚至認為這是不可能的。心理框架需要解釋。當你開始使用它們，并期望只收獲好處，你就需要在給定的上下文環境中解釋它們。而這種解釋依據的就是你自己的項目經驗。

　　當然，有些開發者已經具備了某個心理框架所需的經驗。他們會采用什么樣的方法呢？他們通常有自己的思考和屬于自己的框架。當他們有些人看到一個新的“革命性的”驅動方法時，會發現它的有趣面并意識到他們已經在使用它的一些元素。他們會從新框架中汲取他們想要的長處，或者完整地使用它，畢竟它有一個簡潔又好記的名字。框架將會豐富他們的資源，使他們的工作更加有序。

　　根據我的粗略觀察，我發現剛才提到的這些開發者有以下特征：

• 他們具有超過10年的經驗；
• 他們具有各種各樣的經驗：不同的公司、不同的項目、不同的技術和不同的人群；
• 他們具有從獨立的、看似無關的經驗中概括一些模式，創造出廣義概念的能力；
• 他們具有很好的工作方法，能夠準確區分接口與實現，因此他們更多地關注要實現的目標，而不是實現目標的具體手段；
• 他們回顧性地評估自己的資源；
• 他們花時間拓展自己的知識面、提升自己的技能；
• 許多情況下，他們從自身行為中尋找失敗的原因，而不是歸因于外部環境；
• 他們有能力控制任務的規模。

　　最后兩個特征通常是最大的挑戰。要掌握它們，你需要不同尋常的巧遇，或者通常是多年廣泛領域的強化訓練。在我們看來，這些特征是每個開發者夯實他的心理框架的關鍵因素，對于推出他自己的驅動方法來說則更加重要。沒有這兩個特征，他也能獲得大量關鍵知識和技能，足以輕松工作。這樣的人很少關心心理框架，因為他通常更加了解。

　　所以，現在你知道為什么所謂的驅動方法沒有改變任何事情了？因為當開發者沒有所需的經驗時，框架沒有什么幫助，它在產生干擾。他認為自己在做專業的開發，但實際上他得到了更多的知識和更少的技能。因為他無法在特定的上下文中創新性地解釋框架，因此他以不同的方式使用框架。如果開發者有所需的經驗，他已經設計了自己的框架或者對它不感興趣，因為他認為它不適合于自己的場景。

　　有什么替代的選擇？

　　誠然，開發者的各類驅動認證似乎是有吸引力的團隊開發策略。對此我不下結論。這是一個策略選擇的問題，如果它帶來預期的結果，也沒什么好說的。接下來我將介紹一些也許你會認為有價值的替代選擇。

　　打好基礎

　　如果讓我用三個詞總結整個軟件工程，我認為是：職責、封裝和組合。每個詞都能寫成一篇獨立文章甚至一本書。遺憾的是，當我們掙扎于各類驅動方法時，我們忘記了這些詞可能才是我們應該關注的最重要的概念。我們常常問自己，該使用什么模式？選擇什么心理框架？相反，我們應該問：這個方法、類和模塊的職責是什么？職責、封裝和組合是每一種軟件工程技術的基礎。

　　如果你已經很熟練地運用這些概念，模式將會水到渠成。如果你忽略這些概念，你很快將要結束一個糟糕的軟件工程。與此同時，這些概念非常通用，與你的經驗無關，你始終可以在更深的層次上去理解它們。

　　因此，你的第一階段應該是集中精力打好基礎。當你掌握這些概念后，你可以繼續往前到一些更復雜的任務，包括：

• 使用職責、封裝和組合；
• 以接口的視角思考，即“人們如何使用我的組件？”；
• 使用相關技術寫好代碼，包括可讀性、信息性、簡潔、自描述，盡量避免顯式地使用模式；
• 有能力回答特定業務的“本質”；“本質”是一個模型，但不意味著類和方法，它意味著回答問題“這個業務如何真正地工作？”

　　有趣的是，按照這些規則寫的代碼也許不是“最佳”的，但它一定是“易于重構”的。我們能夠以相對容易的方式修改其結構。這與那些難以重構，甚至當發生變化時，有時候要完全重寫的代碼形成了鮮明對比。

　　技能管理

　　在開發過程中，另一種比癡迷于各種驅動方法更有效的策略是團隊中技能的告知管理（Informed management of skills）。很久以前，你要進入雇主-熟練工的關系才能得到一份工作。它最新的名字叫做老師（教練）-學徒。現在，每個開發者在起步階段，都有一堆文檔，簡單、重復的工作要做。有些人數月、數年的時間都投入其中。某些情況下，這減少了他在就業市場中的成功機會。我要大膽地聲明，這份新工作抹殺了他的潛力，對其開發毫無幫助。從技能開發管理的角度來看，如果說每一個專業人士都能夠被一定數量的學生取代，那么也就等同于說每一個CEO都能被一定數量的顧問取代。

　　通過以下行動，組織能夠管理好開發者的技能：

• 教會有經驗的工程師成為老師和教練；
• 為新員工指定一個關心并幫助其提升技能的人；
• 為開發者提供機會，讓他們有可能工作于各種不同的項目、技術、客戶和同事（當然，不是同時）；
• 對員工設定額外的技術設定，不匹配的人不能錄用；
• 一旦錄用了某人，就認為他具有開發的潛力；
• 與開發者構建雙向信任。

　　可替代的人力資源

　　至少一或多種方法是與技能開發管理背道而馳的。也許這是開發者最不歡迎的方法。公司不明說，卻在實際使用的方法。這就是為什么它很重要，我要在這里進行說明的原因。它的主要目標是建立一個架構，讓公司能夠以快速、廉價的方法替換大多數開發者。這樣的組織會做以下事情：

• 雇用一定數量具有豐富經驗的工程師，剩余的開發者則只需要普通技術水平和平均薪酬；
• 一小組開發者構建系統架構，使得后續開發能以重復的模式進行，從而將執行成本降到最低；
• 系統架構的調整由開發專家進行，關鍵變化和創新變革始終由那些具有豐富經驗的專家團隊和高薪工程師完成。

　　總結

　　正如之前所說的，本文并非要批評任何人或任何事。它只是談論優先級并尋求平衡。首先關注于我們的基礎技能，這能夠幫助正確地使用某種驅動方法，特別是在未知的上下文環境中。我真的感謝所有這些心理框架，他們做了非常棒的工作。但我認為如果軟件開發是由某種東西驅動的話，這是股東的需求和我們的簡單認識。被任何其它東西驅動都可能會影響簡單性。