持續更新就是給軟件上醫保

其實軟件很像房子。

想讓你的房子整潔舒適，你必須每周打掃。隨著時間的流逝，有些東西會出問題，你必須修理它或換新的。但大多時候你需要做的只是簡單的給門或窗刷一道漆就行了。

如果房子料理的好，人們就會喜歡住在里面。

但想象一下，你現在要離開這個房子。剛開始，這個房子還會保持不錯的外觀，室內一切正常。可是，一旦不再有人打掃地板或清理垃圾，房子就開始落灰積沉。一段時間后有些東西開始出問題。起初只是一些小的、不重要的東西出問題，但有一天一場暴風襲擊了它，毀壞了很多東西。

如果這些毀壞的東西沒有人來修理，房子就會持續破敗。

一段時間后，房子變得破敗不堪，沒有人再愿意去哪里。人們會告訴你，與其去修好它，不如蓋個新的。

對任何軟件產品來說，道理是一樣的。

假設一個項目由你們7個人的團隊來開發。每周你們會往里面增加新功能或修改bug。隨著項目的變大，你們會做一些重構來保持軟件架構的健康。你們會做一些遷移工作。時不時的升級軟件包來修補bug、安全漏洞和新功能。

之后，開發工作突然停止了。也許是上級的某個人決定不再往這個項目上投入更多的資金。決策者說：“這個軟件運行的很好。我們只需要它保持這樣，我們不會再花錢來添加新功能。”

于是，你們這個團隊被分配了其它任務，這個項目變成了沒人照料的項目。系統目前還是正常運行，每天都在給現實生活中的人們提供著服務。

幾年后，突然里面的支付系統出現異常。發生了什么？多少年都沒有人碰過這些代碼了。它怎么會突然的就不能用了呢？怎么可能？

無人照料，一場風暴來臨了…

你 需要知道，如今的軟件不再是一個自我封閉的世界。基本上所有的軟件都會和外部世界進行交互。軟件要依賴操作系統，硬件，很可能還會有個數據庫或其它后臺服 務。甚至還依賴一些外部API。它們全部是動態的，不停的在變化。所以，你的軟件也需要跟著變化，這樣才能保持正常運行。

在我們的這個例子中，是因為歐盟通過了一個新協議來統一貨幣。這導致老的支付API不再受支持。

這看起來不像是個大問題。我們的上級決策者決定招聘一個Ruby程序員來解決這個問題。這是一個Ruby on Rails + MySQL項目。很普通。Ruby程序員很快就招到了，而且估計出大概一兩天就能解決問題。

然后，Ruby程序員開始查看項目代碼，發現這是一個很老的項目，使用的是Rails 2.x，不是Rails 3.x或4.x。不，比當前的版本低兩個大版本號。他從來沒有用這么老的Rails版本開發過。

而 接著的另一個讓他驚奇的事情是，MySQL是4.0版的，不是5.0或5.5。不，低一個大版本號！項目中的MySQL驅動gem使用的是一個本地 (native)擴展，無法在他的開發機上編譯，因為他的gcc太新了。他必須降級gcc編譯器版本，才能安裝老的數據庫驅動。

我只打算講到這里。估計你已經知道我想表達的是什么了。

因 為這個項目多年無人維護，導致現在即使一個很小的改動也變得異常痛苦。一個根本用不了一天的小bug修改，現在用去了一周時間。而且這個Ruby程序員非 常不喜歡他現在干的活兒。其他程序員都可以使用Rails4.x里像“Turbolinks”這樣有趣的功能，而他還在跟這些老破爛打交道。他寧愿建議扔 掉這個項目，利用現在的最新技術重新開發一個。

教訓是清楚的。如果你離開你的房子幾年之久，你應該請一位家政每周清掃一次，而在軟件開發世界里，這意味著你每周都應該花一點時間檢查系統并更新相關依賴。

很多時候都是沒有更新可用，外部世界沒有任何變化。這種情況下，5分鐘你就能維護完。

很多時候你會發現軟件包出現了一個新的補丁或小版本升級。這時，你必須進行升級，看看測試是否仍然能通過，系統是否能正常運行。這種事情通常會花20分鐘，完全值得投入，因為這些升級會修補bug，彌補安全漏洞，帶來新功能特征。有些還會帶來內存和速度的優化。

一 般每過幾個月，你依賴的數據庫或API等軟件包都會有一個大版本號的升級。替換他們可能會花數小時，甚至數天。但這是值得的，因為這些升級會讓你的軟件保 持最新技術，這是用來吸引有天才的程序員最好的途徑，他們都是喜歡最新的技術，而不是一堆老代碼。有時候這些更新是必須的，如果不更新，你的應用就無法運 行。

持續更新是為了讓軟件常年保持生命力，健康和新鮮血液。這能保證即使有業務邏輯上重大修改也能在合理的預算內、可以接受的時間里完成。持續更新就是你的軟件項目的醫療保險。

來自: 外刊IT評論 http://www.vaikan.com/