系統維護工作的準確定義到底是什么我并不是很清楚，但是做過了半年的所謂的系統維護工作之后，對業務系統有了新的認識，有一些新的體會和想法。

我所做的系統維護工作的主要內容就是對一個正在運行的保險公司的業務系統按照用戶的要求進行功能的添加，而這種要求是不斷的，一個接著一個，修改和添加涉及到該系統的各個子系統。總的來說瑣碎而又復雜，說它瑣碎是因為大大小小什么樣的工作都有，頁面表示文字的修改，服務器增加安全補丁后的系統能否正常工作的確認，在既有業務的基礎上增加新的需求等等，說它復雜是因為要理解現有系統的各個方面，從頁面到數據的 batch 處理部分，而且現有的系統也是一步一步由最初的系統不斷增加新的功能而來得，需要循其歷史，究其根本。比起開發新項目，少了一些挑戰和刺激，少了一些學習新技術的機會，還少了很多加班（這點我倒很樂意）。但是任何工作，只要用心去體會，總會有收獲的，這段時間的工作，也給了我很多新的東西，值得在以后的工作思考和借鑒。

1．??? 系統維護與瀑布模型

這段時間的維護，采用的是瀑布模型。具體執行起來是這樣的，用戶如果有新的要求，就需要我們和用戶進行交流并整理出需求文檔，然后和用戶一起 Review, 合格之后進行設計文檔的編寫，因為是在既有系統上的功能修改或者添加，所以設計文檔要寫出現有的式樣以及新的式樣，涉及的模塊和文件，修改的方法。完成之后進行設計的 Review, 如果合格就編碼，然后進行代碼 Review, 然后進入測試階段，根據設計來整理出測試用例，并設計測試數據，再次進行 Review, 合格之后，執行測試，提交測試報告，最后一步要整理出發布文檔，該新功能發布時候使用。一開始我覺得很繁瑣，但是一段時間后發現，這種模型是比較適合該現場的。由于參與 Review 的都是相關領域的專家，每一次 Review 都保證了該階段工作的正確性，從需求到設計再到測試，一步一步踏踏實實走過來，很利于管理。而保險業務本身對系統的質量要求很高，現場的這種開發方式也有利于保證質量。在實際運用中，我稍微加入了點原型法，設計的同時作出一個原型， Review 的時候一起 Review, 增加了用戶對設計的理解，我也能夠確認對需求的理解是否有所偏差。給我的啟示是，要在合適的場合選擇合適的開發模型，有時候不妨在合適的地方大膽的進行一些增改。

2．??? 代碼質量對系統維護的影響

??????? 由于是要在現有的系統之上添加功能，現有代碼的質量對工作的效果有很大的影響。一個邏輯清晰，功能劃分合理的代碼，修改和添加起來很舒服，如果遇到一個代碼邏輯比較混亂，功能劃分不合理的話，不光需要大量的時間去讀懂代碼，更重要的是你添加的代碼也不得不屈從現有代碼的設計，變得很垃圾。有時候我想重寫以前的代碼，但是又不敢冒這個險，不管怎么說人家現在工作的好好的，一旦修改不好的話，那就是大事故。所以，這里給我的啟示就是，一開始就要保證好代碼的質量，否則就會發生垃圾代碼繼續招引垃圾代碼的現象。

3．??? 系統架構

??????? 或許是一直開發中小型系統，對系統架構的理解就是程序，服務器和數據庫。像保險業務這樣的重要復雜的業務系統，還需要考慮如何保證業務間數據的傳輸，采用什么樣的傳輸機制，數據的備份，故障時的恢復等等?？偟膩碚f，考慮的問題更多，視角更廣。給我的啟示就是，系統的架構一定要服務于業務，考慮一切問題的出發點只有一個，就是要保證系統正常穩定的運行。

4．??? 團隊的管理

??????? 給我的感覺該現場的 PL 很主動的跟團隊里面的每個人溝通，適機的和每個人交流，答應過的事情一定做到。團隊里的每個人也都很樂意提出自己的問題，想法和意見，整個團隊的氣氛很融洽，工作的心情很愉快。我想該 PL 功不可沒。給我的啟示是一個好的領導者應該懂得傾聽下屬的心聲，確立權威的最好手段不是屈人，而是律己。