寫在改造已有項目架構之前

標籤：style   blog   http   tar   com   get   

作為一個Web應用系統的架構師，之前也做過兩個比較成熟的架構，基本上都是從無到有，個人總結的主要流程有：

    1. 業務需求分析：分析整個公司對架構的需求，分析領導的信心如何，時間是否充裕，要實現那些目標。

    2. 制定詳細的架構目標：在此階段一定要明確架構的目標，作為日後架構是否成功的判定標準，否則很難跟領導交代你做的架構是否成功了。

    3. 架構設計：對整個架構進行層次設計，功能模組設計，理清設計思路，整理架構設計文檔。

    4. 技術路線選擇和可行性分析：根據設計目標選擇不同的技術路線，比如：是選擇開源的技術組建還是自己開發?

    5. 詳細設計：設計完整細緻的開發流程

        1) 資料庫互動流程：設計如何跟資料庫互動，實用實體還是sql？

        2) 業務請求處理流程：設計前後台應用如何互動，ajax，post，webservice等等

        3) 跟美工一起設計前台頁面樣式風格

            a) 整體系統布局風格。

            b) 單獨控制項功能設計和屬性設計。

    6. 代碼架構初始化：初始化目錄結構，設定初始規則，搭建架構原型。

    7. 典型模組開發：在原型中，使用常用布局，常用控制項，常用的請求流程開發開發常用功能。

    8. 進階功能的設計與開發：開發一些計劃中的進階模組。

    9. 整理架構使用文檔，架構使用標準等。

    10. 尋找簡單業務系統，進行測試，對系統開發過程中遇到的問題，進行進一步的維護和升級。

進入新公司之後，發現公司之前對架構不重視，造成現在公司內的系統架構幾乎每個系統一套，無法公用。

領導最近發現此問題，希望儘快整理公司整個架構體系，考慮到現有業務系統，因此最近一段時間會對現有業務系統進行架構改造。

個人對這種老系統的改造，總有一種推翻重來的衝動，個人覺得最有效辦法就是重構，尤其是出現以下情況：

    1. 代碼經過幾個人維護之後，代碼越來越難讀。

    2. 新增一個功能不一定會碰見什麼”地雷“。

    3. 遍地的if/else語句。

    4. 大量的無用代碼和重複代碼，甚至很多重複的第三方引用，僅僅版本一樣。

但是實際情況是，領導在考慮人力成本，時間成本時，不可能讓你把現有的系統改造，因此想辦法在現有的基礎上如何改造。初步思路如下：

    1. 先找出系統中現有的明顯問題，在不影響架構的基礎上，將能改的改掉。

    2. 在現有技術路線的基礎上，制定相應的標準（在不影響整體架構的基礎上可以適當的新技術）。

    3. 按照相應的標準，逐步將原有的重複代碼去掉。

    4. 對新增功能嚴格按照標準開發。

    5. 在未來的一段時間內，實現所有代碼都符合標準，變成一個有標準架構的系統。

    6. 在適合的時間，系統推翻重構，新重構的代碼嚴格按照新的標準執行。

      PS：

            這麼做的原因是，從舊架構改造成為新架構有成功的可能，如果是一個代碼隨意的系統想改造難度太大。

 

 

希望能在未來的一段時間內能有一些成果。

sdjnzqr
出處：http://www.cnblogs.com/sdjnzqr/
著作權：本文著作權歸作者和部落格園共有
轉載：歡迎轉載，但未經作者同意，必須保留此段聲明；必須在文章中給出原文串連；否則必究法律責任