偏好設計技巧

想像一個徵才情境。有兩位候選人，都有幾年的經驗。藍方候選人具備你偏好的設計風格中良好的廣泛設計技巧（對我來說，這會像是 DRY、明智地使用模式、TDD、具溝通性的程式碼等，但實際清單並不重要，只要是你偏好的即可）。然而，她對你正在使用的特定平台技術一無所知。紅方候選人對這些議題知之甚少（或興趣缺缺），但非常了解你的平台，例如語言中的邊界狀況、有哪些可用函式庫、手指在工具上自然移動。假設其他條件都相同（除了像這樣的思想實驗之外，這永遠不可能），而且你的團隊沒有這個候選人可能填補的明顯缺口。你會偏好哪一位？

我的答案很簡單，我會選擇具備廣泛設計技巧的那位。我始終認為一位優秀的程式設計師應該能夠相對快速地學習新平台。學習基本的設計美學既更困難，也更能轉移到新平台。在 Java 中重要的良好設計實務在 .NET 中同樣有價值。不熟悉平台確實會讓你慢下來（我該如何在 C# 中再次取得文字類別名稱？），但產生設計良好的程式碼才是真正有差別的地方。

廣泛的設計技巧並非完全可移植。Java 和 .NET 作為語言大部分是等效的，然而，轉移到 Ruby 會有更多變化。轉移到顯著不同的野獸，例如函數式語言，是一個更大的轉變。無論如何，你不能只是盲目地在新的環境中複製所有設計習慣。但如果你意識到新世界，很多東西確實會被延續。

我們在 Thoughtworks 看過此原則的驗證。在我們使用 Java 的早期，我們發現經驗豐富的開發人員在 Forte 學到的技能，讓我們得以具備使用 Java 的絕佳直覺。我們很早就遠離以 EJB 為主的思考模式，而我想這是其他平台的經驗引導我們的。我們在 .NET 中看到這一點更加明顯。我們一再看到，具備 Java 背景的優秀開發人員比那些缺乏這些技能、但具有較長 .NET 或 Microsoft 背景的人員更快速地發揮效力。這種差異在幾週內就能看出來，而不是幾個月（有時甚至幾天）。

目前我們最明顯地看到這種轉變發生在 Ruby 中。今年我們執行了一些 Ruby 專案，而且我們經常找具有大括號語言豐富經驗的人員來滿足需求。我們再次看到廣泛設計技能帶給我們的價值。

這並不總是確定的事情。我曾看過某些在其他平台上經驗豐富的人員，就是不願意深入了解並學習新的平台。渴望學習是此處必要的組成部分 - 如果單一平台專家想要學習廣泛設計，而廣泛設計師不想要學習新平台，我會選擇單一平台專家。團隊中也必須有人深入了解該平台。

我想說，Thoughtworks 中大多數人偏好設計技能，而非平台知識。許多客戶並不認同此觀點 - 這可能會導致一些困難的務實和倫理選擇。

如果你有想要納入團隊的人員，而他具有強大的設計技能，但沒有平台背景 - 但客戶卻堅持至少要有兩年的平台經驗，會發生什麼事？根據你的專業判斷，廣泛的候選人將比其他可用人員更有生產力。你必須對客戶誠實，但另一方面，他付錢給你，就是為了你的專業判斷。如果客戶已賦予你專案交付的責任，這會改變嗎？

對我們來說，這些問題更具爭議性，因為其中涉及財務利益。如果我們將 ThoughtWorker 加入團隊，我們就會對該人員開立帳單。如果客戶聘用平台專家承包商，我們就拿不到那筆收入。對許多人來說，這是情況中的關鍵事實，但我預期我們的專案經理足夠明智，知道加入錯誤人員的風險，比一個計費收入重要得多。

考慮另一個案例，你對客戶公開，而客戶要求降低廣泛設計人員的費率，因為她缺乏平台知識，她將在職涯中學習。你確定，儘管她缺乏平台知識，但由於這些設計技能，她將比競爭的平台專家更有生產力。你應該接受降低的費率嗎？

在我們的專業領域，以及大多數其他專業領域，都是邊做邊學。如果平台專家要產出可維護的程式碼，他也必須學習廣泛的設計技能。在這裡，重要的是要記住，學習設計通常比學習平台更困難，而且也不確定。如果有一位有動機的廣泛設計師，我相當確定她會及時掌握一個平台。但反過來則沒有保證。有些人擅長學習平台的細節，但永遠無法弄清楚如何撰寫清晰的程式碼。

我在這裡談到了廣泛的設計技能——我確實相信這在技術軸線上會有所不同。但廣泛性還有其他面向。軟體專案中最大的風險在於業務人員和程式設計師之間的溝通，因此一位能與使用者良好溝通的候選人能為團隊帶來很大幫助。

一個類似的問題是對問題領域的了解。客戶通常想要已經了解其業務的人員，但當有人快速獲得足夠的理解以發揮作用時，他們卻感到驚訝。我長期以來一直認為，與他人合作的能力是此處的關鍵。透過與領域專家或平台專家合作，具備廣泛技能的人員可以非常快速地發揮作用。對其他領域的了解通常會為專案帶來令人驚訝的見解，而相似之處也經常出現在令人驚訝的地方。令人驚訝的是，諸如核心會計模式之類的事物經常出現在表面上看起來不像會計的地方。最終，與他人合作的能力，加上快速學習的能力，才是關鍵技能。

我並不是在這裡否定深入的平台知識。在理想的世界中，每個團隊成員都應該是優秀的廣泛程式設計師，擁有數年的平台經驗，對問題領域有很好的熟悉度，並且至少撰寫過兩次類似的系統。但我們都知道我們的現實世界與這個理想有多遠。你需要團隊中具備一些平台知識，如果這是個缺口，我會找平台專家來填補它。但這並不會改變我預設的立場，即在大部分時間裡更偏好廣泛的設計技能。