工藝與裂縫

丹尼爾·特霍斯特-諾斯最近在部落格發表的關於軟體工藝的文章引發了許多部落格討論（如果您有興趣，我將在下方總結）。文章內容豐富，但其中一個主題特別引起我的共鳴，因此有了這篇文章。

不過，在我探討這個主題之前，我想先把一個元素推到一旁。我一直認為關於軟體開發的隱喻的辯論很無聊。雖然隱喻提問有其地位，但我從根本上對軟體開發是工藝、藝術、貿易或甜點配料不感興趣。

對我來說，重要的是工藝隱喻，而不是在過去幾年似乎興起的運動特徵。從我的局外人角度來看，激勵軟體工藝社群的主要力量是對敏捷運動變化的反應。在敏捷病毒的早期，主要的變種是極端程式設計，它對技術實務有很多話要說。現在主要的敏捷變種是 Scrum 和精實，它們不太關心程式設計——因此那些主要以程式設計師自居的人覺得他們的生命很大一部分在敏捷世界中不再重要。

因此，軟體工藝世界是一個程式設計可以再次成為焦點的地方。人們可以討論測試、如何學習和使用函數式語言、良好設計的原則等。然後可以將管理和分析問題留給虛弱的敏捷社群。我對此深表同情。我接受DesignStaminaHypothesis，它表明如果你想有效地開發軟體，你需要注意良好的技術實務。因此，重視這些問題的運動很重要。但其中也潛藏著一個危險，那就是工藝運動過於專注於技術問題，將會低估客戶溝通同樣至關重要的作用。

我非常喜歡 Kent 的工作的一點是，在與客戶的關係和執行我們一半的交易所需的技能之間取得了真正的平衡。我記得他在AgileManifestoMeeting上說，他對極端程式設計的主要目標是彌合軟體開發人員與其客戶之間的鴻溝。丹和我將這種鴻溝稱為「毀滅的巨大裂縫」，這是軟體開發中最重要的一個問題。

造成裂縫的很大一部分原因在於組織習慣，這些習慣建立在程式設計人員和客戶是如此不同的生物，以至於他們無法溝通（也不應該嘗試）的概念上。但許多程式設計人員似乎很樂意擴大裂縫。幾年前，艾瑞克·埃文斯的觀察讓我印象深刻，那就是隨著開發人員變得越來越資深，他們往往會更專注於技術問題，而不會傾向於去了解他們正在從事的領域。領域驅動設計在很大程度上是關於嘗試改變這種情況——儘管它似乎經常陷入對主題的討論中，例如如何在你的儲存庫上使用依賴注入。（我自己的職業生涯也因此而受苦。隨著我作為一名通用軟體開發專家而發展，我已經不再能夠從事領域建模——儘管這一直是我軟體開發中最喜歡的部分。）

因此，就像 Scrum 和精實通過忽視技術技能而加劇了這個問題一樣，我擔心工藝反過來可能會通過忽視關係技能而使裂縫變得更糟。我理想中的程式設計人員不僅精通程式設計工藝，而且還通過與領域專家溝通來了解領域，從而獲得動力，以便她可以參與尋找讓軟體幫助客戶在他們所做的事情上取得成功的最佳方法。用丹的話來說，軟體不應該是程式設計人員世界中的中心，相反，程式設計人員應該專注於軟體應該提供的利益。

部落格聊天

（包括回應此條目所發布的項目。）

• Daniel Terhorst-North 的 原始文章
• Liz Keogh 說明她對軟體工藝宣言感到不自在。
• Gil Zilberfeld 比較了軟體工藝和 alt.net。
• Jason Gorman 希望我們不要過於執著於標籤
• Michael Feathers 在我們的作品中尋求更深思熟慮的實踐。
• George Dinwiddie 提供了一個實例，說明為什麼品質工作對客戶很重要，以及認證和許可如何無濟於事。
• Daniel Terhorst-North 擴充並釐清他一些早期的觀點。
• Bob Martin 表示軟體工藝只是關於程式設計師厭倦寫垃圾。
• Bob Martin 認為我的恐懼是沒有根據的（我希望他是對的）。