Jim Bird是一位經驗豐富的軟件開發經理、項目經理與CTO，專注於軟件開發與維護、軟件質量與安全等領域中疑難問題的解決。在過去的15年間，Jim曾管理過團隊建設並主導過高性能的財務系統的建設。他的主要興趣在於如何提升小團隊的效率以構建真正的軟件：高質量、安全、可靠、高性能及適應性強。近日，Jim撰寫了一篇博文，談到了軟件開發中變更所帶來的影響以及真正的代價，同時還談到了如何降低變更的代價。
當軟件已經設計、編碼、測試與實現完畢後，如果要對其進行修改或是修復，那麼代價是怎樣的呢？關於這個問題存在兩種截然相反的觀點。一種觀點認爲越晚修改成本就越高，修改的代價會達到指數級；另一種觀點則認爲應該儘可能晚地做修改，因爲修改軟件的代價本質上是水平變化的。那麼究竟哪種觀點纔是正確的呢？我們該如何做呢？
指數級的變更代價
回到上個世紀80年代初，Barry Boehm發佈了一些統計數字（Software Engineering Economics, 1981），表明修改或修復軟件的代價會隨着時間的流逝呈現出指數級的變化，可以在這裏查看變化曲線。
Boehm的這個結論是根據70年代在TRW與IBM採用瀑布模型的項目數據而得出的，他發現當從需求分析轉到架構、設計、編碼、測試與部署階段時，修改軟件的成本會逐步增加。當尚處在需求定義階段時，如果發現了需求上的錯誤而進行修改時，其代價幾乎可以忽略不計。不過，如果等到完成了設計、編碼和測試並將軟件交付給客戶後，那修改的代價可以達到之前的100倍以上。
這裏要補充幾點。首先，大型項目的代價曲線會更高一些（在小型項目中，代價曲線差不多是1：4而不是1：100）。修改成本能達到100倍的項目並不常見，Boehm稱之爲架構崩潰，這指的是項目基礎的架構就是完全錯誤的（可伸縮性、性能以及可靠性等），而且是在客戶已經開始使用系統並遇到嚴重的操作問題時才發現的。這些分析基於的是30年前的少量數據採樣，那時編寫代碼的成本非常高，也很消耗時間，同時缺乏高效的工具。
從那之後還有不少人做了相關的研究，結果也都與Boehm的發現很類似，至少基本的觀點是一致的，那就是發現問題的時間越晚，修復問題的代價就越高。這些研究成果被很多書籍所引用，比如說Steve McConnell的代碼大全等，用於證明儘早執行審查和測試的重要性：
總而言之，原則就是發現錯誤的時間越早，修改的成本就越低。Bug在軟件生態鏈中存活的時間越長，它對整個軟件造成破壞性就越大。由於需求是最先確定的，因此需求上的缺陷就可能駐留系統更長的時間，修改的代價也更高。
水平的變更代價
規則隨着開發逐步轉向迭代式和增量式而發生了變化。
Boehm認爲如果我們能夠提前考慮清楚風險並以增量的方式設計和構建軟件（使用他稱之爲的螺旋模型而不是順序化的瀑布式模型），那麼我們就能儘早發現錯誤了。
更加現代化、輕量級的敏捷開發方式背後也是同樣的想法。在Extreme Programming Explained（第1版）中，Kent Beck認爲最小化修改的代價是極限編程的一個目標，水平化的修改代價曲線是“XP的技術前提”：
- 在某些情況下，隨着時間的流逝而導致的指數級的修改代價可以水平化。如果我們能將代價曲線水平化，那麼關於開發軟件的最佳方式的舊假設就站不住腳了。
- 你可以在過程的後期做出重大的決策，推遲決策的代價，從而儘可能確保決策的正確性。你只需要實現需要實現的東西，你可以引入能夠簡化現有代碼並使得後續編碼變得更簡單的設計元素。
重要的是你要知道Beck並沒有說XP會將代價曲線水平化，他的意思是如果團隊向着這個方向努力，那麼是可以將修改代價曲線變成水平的。
反饋的重要性
Scott Amber認爲在敏捷開發中代價曲線是可以水平化的，不過這並非因爲簡單設計，而是因爲對於迭代式、增量開發很重要的反饋循環。敏捷方法優化了團隊中的反饋，開發者與客戶坐在一起進行持續的面對面溝通。諸如測試先行的開發、結對編程與持續集成等技術實踐使得這些反饋變得更加緊密。
不過，真正重要的是從使用系統的用戶當中獲得反饋信息，只有這樣你才能確定自己是否是正確的，是否遺漏了某些東西。設計、構建以及從真正的用戶獲得反饋的時間越久，將軟件交付給用戶所需的時間和工作量就會越多，變更的成本也會越高。
變更的真正代價
變更的代價真的是指數級麼，還是水平化的。答案其實是介於二者之間的一個狀態。
時至今日，軟件變更的代價肯定不如30年前那麼高了。我們現在可以做得更好，使用更好的工具、更好的開發方式。降低變更成本的關鍵因素有下面幾點：
- 儘快將軟件交付給客戶使用。我不相信有哪個組織每天會對軟件做10次、50次，甚至是100次變更，不過你肯定也不想等待幾個月，甚至是幾年才收到用戶的反饋吧。少量交付，頻繁交付。
- 我們知道即便事先做了周密的規劃和設計也無法確保一切都是正確無誤的。請在理解需求和設計上花上足夠的時間，這樣可以確保我們是基本正確的，能夠在後面幫助我們節省大量的時間。
- 無論是採用迭代、增量的開發模式還是順序開發模式，不管是通過測試先行的開發與結對，還是需求講座和代碼審查，只要有可能就提早找出錯誤，這樣會降低後期的修改成本。