關於公司系統支撐工作的建議

關於公司系統支撐工作的建議

成曉旭

剛來部門不久，對部門的整體工作情況瞭解不多，對公司的資訊系統建設情況更是不敢枉自品評。

對於像我們這樣規模的公司，自己建設、實施和維護滿足公司自身管理要求的管理資訊系統，是目前部門公司對於企業ERP系統的建設方式。比如：XXXX、XXXX、XXXX、XXXX等等知名企業。其實：這種ERP系統建設方式，我本人並不看好和推薦。如果公司也採用這種方式建設我們自己的綜合資訊管理系統，本著把事情做好，儘量讓部門能更省心、更有效的為公司綜合資訊管理系統提供支撐，從我個人的視角出發、提出幾點淺見：

1、   加強相似業務流程、管理模式的抽象與提煉，通過系統分析與設計、並編碼實現成我們自己的基礎架構原始碼庫。下面是用簡單的原始碼統計工具，針對新、舊兩個版本的XX系統，進行的最簡單的程式碼行數統計分析情況：

         僅通過最簡單的減少系統程式碼量，相信就能較大的降低系統後期的測試、除錯、維護、升級的複雜度和工作量。

2、   注重新建子系統、功能模組、業務構件、甚至是最簡單的一個新單元、新類的重新分析、設計和實現。針對目前整個系統的在新執行情況和日常的維護工作量，我們不大可能有充足的人力和時間，來整體重新構建各個線上的子系統。但新業務需求的實現時有發生。既然是新增功能、新寫程式碼，我們更有理由摒棄原來不太好的開發方式和思路，採用一些更專業、更成熟軟體開發模式與架構，至少讓新增的功能塊一開始，就有較好的穩定性、較高的可複用度、較強的可擴充套件性。堅持這樣，才能逐漸、逐漸地提升整個軟體系統的內部質量特性、才能逐漸、逐漸地減少系統的維護工作量；否則，隨著軟體程式碼量的日益增加、系統功能的日益複雜、業務需求的頻繁變化，已建系統對新需求變動的滿足難度勢必越來越大：“雪球效應”很可能發生在系統支撐小組，導致系統支撐小組最終很難再繼續有效地支撐下去。

3、   為支撐小組的軟體開發、維護工作選擇適合的軟體開發方法論，並結合具體工作實踐進行裁剪或增補。切合團隊實際工作情況的軟體開發方法，將極大改善開發團隊的工作效率、提升互動軟體產品的內外品質：已是不容質疑的事實。傳統的軟體開發方法、資訊化軟體開發方法、統一軟體開發方法，都不太適合我們公司系統這種“應用需求變動頻繁、支撐資源配置緊張”的現狀。建議採用敏捷軟體開發方法的原則與模式：準確把握客戶的當前需求、適度設計並保持設計的靈活性、簡單開發以滿足當前需求、頻繁重構與迭代保持系統當初的設計原則、測試驅動開發和加強單元測試從最底層開始確保系統的健壯性。

4、   在公司系統的開發、維護、支撐過程中，建議一定要堅持系統建設初期的分析、設計、編碼原則，至少最起碼的基線原則必須堅持。進公司幾個月來，聽到、看到太多的、很好的原則在現實面前妥協的情況。表面上看，我們的妥協當時是縮短了開發時間、提高了客戶需求的響應時間；其實，事後我們往往為違背這些原則付出了更大的代價。眾所周知，任何專案系統的建設，在人力、時間、質量等方面都是受限制並且相互制約的。軟體系統的經典的設計模式與原則也是人所共知的，最終軟體產品的質量在很大程度上，就取決於開發團隊在軟體構建過程中，對原則的堅持力度與執行力度上。

5、   個人對公司系統構建過程的建議：準確把握客戶的當前需求但不求全責備；採用經典、成熟的設計原則與模式但不過渡設計；儘量用簡單的編碼來實現當前功能；通過頻繁的重構來堅持期初的設計和實現原則；在維護和新增功能前儘可能先重構再重用、杜絕通過“程式碼複製”實現相似的系統功能；加強單元測試來保證系統構件的可靠性與健壯性、將軟體BUG的大部分解決在單元開發期間。我個人經驗是：“用精巧、優雅的設計來應對需求的瞬息萬變；用重構與迭代來維持良好的系統體系架構；注重單元測試保障系統內部、外部品質”。

6、   再次建議加強系統測試、尤其是開發初期的單元測試。在我的維護工作中，很多次發現這樣的現象：執行很久的程式功能突然發生一個異常，通過跟蹤程式碼，錯誤居然被定位很基本的指標保護或邏輯錯誤上，而這些錯誤極易在單元測試中被覆蓋、發現和解決，相反，在系統後期的元件測試、整合測試、迴歸測試、系統測試階段較難再現。這類問題還反應了我們原來的測試用例的程式碼覆蓋率不高。

7、   其實，還有很多，覺得太過於注重細節，就不寫在這裡了，在日常的工作中，慢慢的改進吧。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1666912