軟體維護的噩夢

我們很多時候可能不是那麼幸運的被叫來做軟體開發工作，而是做現有軟體的維護。比如前人跳槽了，或是安排做其他工作去了，剩下的已交付的軟體就需要人來繼續維護。這可是一個苦差事，首先要看得懂前輩的代碼，然後就是軟體支援、改bug、改功能、加新功能，等等。反正就是做痛苦的修修補補的工作。

比起軟體開發來，軟體維護簡直就是無聊透了，首先不能出成績，雖說維護龐大的代碼不比開發來的容易，先前軟體架構不好，維護性差，那你工作量就大了，可你做好了也就是個維護工作，沒有創新，沒功勞，如果有功勞，那也是前人栽樹後人乘涼啊，前輩們系統設計的好。其次是工作內容很枯燥，誰願意費盡心機去看懂別人的代碼呢？更何況有的代碼是沒有文檔，沒有注釋，沒有良好的命名規則的三無代碼。即使有文檔，文檔基本很久沒有更新了，和代碼對不上號。看這種代碼，改這種代碼，簡直就是對自己的耐心的一種折磨和考驗。

更加可怕是，儘管設計說明書上描述的架構設計的如何精巧靈活，結果事實往往不是這樣，在新的功能需求面前不堪一擊。很多時候改了一個小地方，結果會觸動其他的隱藏的很多神經，任何修改你都要小心翼翼。除了原來的程式員，沒有人確切的知道某某功能點需要修改幾個地方，哪兒和哪兒是相互關聯的，這個功能會影響那個功能。有的時候甚至連需求功能點列表都沒有留下。這簡直就是軟體維護的噩夢。

最後的結果就是：“錢基本花光，人基本跳光，甲乙雙方感情基本破裂。”

其實從軟體生命週期來講，任何一個軟體總有一天，它的架構會越來越不能滿足新的需求，會走到盡頭的時候。但不到萬不得已，客戶不會拋棄原來系統而花大價錢去開發一個新系統的。所以討論如何進行軟體維護還是有一定意義的。

 

難道就沒有維護性好的系統？

我見到的一些老系統運行了幾十年很穩定，維護的也很好，(可能剛上系統的一兩年會比較痛苦吧，但從幾十年來看很穩定) 比如銀行和電力的老系統，最後直到前幾年銀行大集中的時候才上了新系統。難道他們的系統那麼強悍嗎？難道他們沒有新需求出現嗎？錯了，其秘密在於銀行核心的業務基本沒變，所以軟體的核心價值和功能沒有變，變的只是些小的邊緣的需求，銀行會不斷在上一些非核心的業務和系統，但前提是不修改不影響核心業務系統的運行。我想這一點對做軟體開發和維護的人來說有點啟示。如何把不經常變的東西挖掘出來？起初設計系統的時候，就應該集中在核心業務需求上，因為那才是這個軟體的最大價值和核心。核心價值不能變。對這個核心業務價值的設計應該具有良好的擴充性、維護性、和穩定性。當然，全面細緻的文檔，及時更新，都是非常重要的，能抵禦人員流失的風險。

 

從維護重新認識軟體生命週期

• 軟體維護通常佔到軟體總成本的40%-80%，維護可能是整個軟體生命週期中最重要的階段。
• 功能增強(Enhancements)可能佔到60%的軟體維護工作。
• 軟體維護是一個解決方案(Solution)，而不是一個問題(Problem)。
• 理解現有的軟體是軟體維護中最困難的工作。
• 複雜的邏輯、功能和配置都降低了軟體的維護性。

 

軟體維護中的創新：重構

被分配到做軟體維護，其實也能夠學到很多東西，也可以在維護中間思考如何進行重構。因為任何一個成功的軟體都是不斷進行重構才真正成功的，從1.0，到2.0，重構到3.0，甚至到8.0，任何時候都不要以為軟體已經完美，任何時候都可以進行重構。當軟體千瘡百孔，不堪重負，對新增需求舉步維艱的時候，就是重構的時候了。但重構要注意兩點：

首先是重構要保持系統的核心價值不變。例如，老的軟體的最大賣點是體積小，啟動快；這個對使用者的核心價值在以後的重構中不能丟，否則就會失去使用者。

其次是重構必須要注意風險。重構的前提是要對老系統非常瞭解，功能點、架構、實現細節、依賴關係、強項與弱項、相關文檔、商務邏輯等，都要非常瞭解。另外一個重構的前提是有品質保證，單元測試、功能測試、迴歸測試，否則任何試圖重構和解耦系統、試圖提高代碼結構、效能和維護性的努力都會帶來極大的風險。