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

　　其實軟體很像房子。

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

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

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

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

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

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

　　假設一個專案由你們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等軟體包都會有一個大版本號的升級。替換他們可能會花數小時，甚至數天。但這是值得的，因為這些升級會讓你的軟體保持最新技術，這是用來吸引有天才的程式設計師最好的途徑，他們都是喜歡最新的技術，而不是一堆老程式碼。有時候這些更新是必須的，如果不更新，你的應用就無法執行。

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

　　英文原文：Why your software project will slowly die without continuous updating