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

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

成曉旭

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

對於像我們這樣規模的公司，自己建設、實施和維護滿足公司自身管理要求的管理資訊系統，是目前部門公司對於企業

erp系統的建設方式。比如：

***x

、***x

等等知名企業。其實：這種

erp系統建設方式，我本人並不看好和推薦。如果公司也採用這種方式建設我們自己的綜合資訊管理系統，本著把事情做好，盡量讓部門能更省心、更有效的為公司綜合資訊管理系統提供支撐，從我個人的視角出發、提出幾點淺見：

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

xx系統，進行的最簡單的**行數統計分析情況：

總**量

業務**量

架構**量

2/8原則(80%bug

分布於20%

**中)

2/8原則

(20%bug

分布於80%

**中)

舊xx135704

135704

未統計

27140

108564

新xx36891

31025

5866

7378

29513

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

2、注重新建子系統、功能模組、業務構件、甚至是最簡單的乙個新單元、新類的重新分析、設計和實現。

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

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

5、個人對公司系統構建過程的建議：準確把握客戶的當前需求但不求全責備；採用經典、成熟的設計原則與模式但不過渡設計；盡量用簡單的編碼來實現當前功能；通過頻繁的重構來堅持期初的設計和實現原則；在維護和新增功能前盡可能先重構再重用、杜絕通過「**複製」實現相似的系統功能；加強單元測試來保證系統構件的可靠性與健壯性、將軟體

bug的大部分解決在單元開發期間。我個人經驗是：「用精巧、優雅的設計來應對需求的瞬息萬變；用重構與迭代來維持良好的系統體系架構；注重單元測試保障系統內部、外部品質」。

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

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

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

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

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

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

相關推薦