水煮胡蘿蔔

在我成長的過程中，我討厭胡蘿蔔，討厭它的味道和質地。但是在我離家開始自己煮飯後，我開始喜歡它們了。胡蘿蔔本身沒有改變，我的味蕾也沒有徹底改變，差別在於烹飪方式。我母親和其他許多那一代的英國人一樣，並不是一位好廚師，特別是煮蔬菜。她的做法是將胡蘿蔔煮沸二十分鐘以上。後來我才知道，如果你正確地烹飪它們，胡蘿蔔會帶來截然不同的體驗。

這個網站不是關於烹飪，而是關於軟體開發。但我發現，技術或工具通常就像可憐的胡蘿蔔一樣，被指責很糟糕，而實際問題在於技術被錯誤地使用。

讓我們舉幾個例子。我的一些朋友評論說，儲存程序是一場災難，因為它們沒有保存在版本控制中（相反，它們的名稱像是 GetCust01、GetCust02、GetCust02B 等）。這不是儲存程序的問題，而是人們對它們使用不良做法的問題。同樣地，進一步詢問 TDD 導致設計脆弱的批評發現，問題團隊沒有進行任何重構，而重構是 TDD 中的關鍵步驟。

這兩個都是水煮胡蘿蔔，是有用的工具，但被濫用了。我見過團隊同時從儲存程序和 TDD 中獲得價值。如果我們在不考慮其使用情況的情況下放棄它們，我們就會失去工具箱中的有用工具。

並非所有技術失敗都是水煮胡蘿蔔。我得到可靠的消息，沒有辦法烹飪松鼠，讓它們對任何不絕望的人來說都很有食慾（這很可惜，因為它們今年春天對我們的花園做了什麼）。如果我遇到一個在共享資料夾中處理程式碼的團隊，沒有任何版本控制，那就沒有辦法烹飪這種技術，而不會同樣令人震驚。

因此，當我們聽聞技術失敗時，我們需要提出更多問題。

• 是技術本身有問題，還是錯失了其他事項。技術是否對此有影響？（版本控制與儲存程序是不同的，但由於涉及的工具性質，使用版本控制與儲存程序可能較為困難。）
• 是否在不適合的脈絡中使用技術？（當你沒有測試時，請勿使用大規模手動重構。）請記住，軟體開發是非常人性化的活動，通常技術不適合某個脈絡是因為文化和個性。
• 是否遺漏了技術中的重要部分？
• 是否專注於與現實不符的外在徵兆？史提夫·麥康奈稱這種情況為貨運崇拜軟體工程。
• 是否某項技術在某個規模上有效，但卻被用於其適用範圍之外？值得記住帕拉塞爾蘇斯的原則，即藥物與毒藥的區別在於劑量。透過 UI 測試系統在少數情況下很有用，但如果你將其用作主要測試方法，你最終會得到緩慢且脆弱的測試，這些測試會拖慢你的速度或被忽略。

這方面一個有趣的觀點是某些技術是否脆弱；亦即它們是否難以正確應用，因此更容易發生錯誤應用？如果難以正確使用某項技術，這對該技術來說是一個合理的限制，縮小了可以使用該技術的脈絡。有些精緻的食物必須留給主廚。這並不會讓它們成為一種糟糕的技術，但確實會降低它們對技術較熟練團隊的適用性。我認為這是組件延遲整合的基本問題。雖然有些團隊可以開發組件以仔細的規格，這些組件可以在一天結束時整合在一起，但實際上很少有團隊能夠做到這一點，而延遲整合最終會像河豚一樣。

雖然我們需要小心水煮胡蘿蔔，但我們也需要記住我觀察到的情況，即「沒有任何方法論會失敗」。對於任何失敗（假設你可以知道WhatIsFailure），你都可以找到與方法論的某些差異 - 這導致其捍衛者說它沒有被遵循，因此沒有失敗。這裡存在真正的緊張關係，如果不深入了解技術背後更深層的原理，就無法解決這個問題。真正的重點是，這些技術無法嚴格描述，就像義大利麵條碳納拉沒有可以不假思索地遵循的精確食譜一樣。最終真正重要的是菜餚，製作菜餚的技術可以激勵和指導一位好廚師，但不能保證沒有某種程度技能的人成功。

如同任何職業，如果我們能從彼此的經驗中學習，我們可以進步得更快。人們使用技術和工具的報告很重要，這樣我們才能判斷在我們自己的工作中嘗試什麼。然而，一個簡單的標籤通常不足以繼續。我們無法衡量正確使用技術的合規性，就像我們無法衡量它們的成功一樣。重要的是，每當你聽說某項技術失敗時，都要深入探究，看看胡蘿蔔是否在鍋裡放得太久了。否則，我們就有可能錯過一些有價值的東西。