納許維爾專案

最近我花了一些時間與 Thoughtworks 歷年來我最喜歡的專案之一相處。這個專案始於 1998 年，當時採用了當時最新的 J2EE 技術。多年來，它有著一段引人入勝的歷史：從 EJB 開始，將它們移除，外包到班加羅爾，再回到芝加哥。許多人進出過這個專案，而專案的人數也從 6 人到 60 人不等。總體而言，這個專案投入了 300 多個員工年的工作，規模約為 100 KLOC。

這是我的最愛，因為它展現了我偏好的軟體開發觀點中一個重要的特性：由設計良好的程式碼庫支援的業務功能長期支援。他們在十年後仍然能增加有用的業務價值，這是一個很大的肯定。他們能在需要時快速新增新功能，因此沒有陷入傳統應用程式的典型泥沼。

在這次拜訪中，有幾個想法吸引了我。

首先，他們在接受測試的方法上有一個有趣的演進，以及在新增新功能時如何更新這些測試。在他們最初（也是常見的）世界觀中，每次實作一個新的使用者故事時，你會新增一個或多個測試。這會帶你到一個簡單的追蹤結構，其中每個故事都由一個或多個接受測試驗證。但這種方法的問題在於，隨著時間的推移，測試會變得越來越複雜，而且重複性很高。

在他們新的世界觀中，有一組接受測試以範例規格的風格描述應用程式行為。每次他們播放一個新故事時，他們會決定如何更新這組測試以反映新的行為。這打破了簡單的故事到測試的關係，但產生了一組更簡單、更一致的測試。

這個專案的第二個有趣面向是如何持續改善程式碼庫。他們想出了一個描述這一點的良好非正式指標。幾年前，如果他們想找一個新人，他們希望那個人至少承諾一年，這樣他們才能在熟悉程式碼庫後做出有價值的貢獻。現在這個時間縮短到三個月。對於一個有這麼多人參與的十年老應用程式來說，這是一個相當大的成就。

對我來說，良好設計的主要目的是讓你可以繼續快速使用程式碼（DesignStaminaHypothesis）。評估開發人員需要多長時間才能使用程式碼庫是一個了解此設計品質的好方法。最低承諾長度指標是這個相同概念的另一個切入點。這不是我們可以客觀測量的，但團隊可以考慮看看。

我希望我們能讓更多專案人員談談他們的經驗。他們去年確實做了一個 Podcast（前往 thoughtworks Podcast 並尋找「保持灰色程式碼健全」）。