有感于目前公司的一個項目產品中遇到的一些問題，結合著自己的設計與開發經歷，總結一下系統設計與規劃的必要性和知識點，作為將來設計的參考，也與大家一同探討系統設計中要注意的各方面。

　　產品簡介：該產品是一個WebGIS系統，歷經2-3年的開發與實施，目前準備從項目升級為產品，但是在項目實施中暴露出大量問題，使得實施人員和開發人員狼狽不堪，離產品要求還有較大差距，所以領導層意識到問題的嚴重性，要求進行改造，并讓我做一些技術指導和設計上的把關。作為一個未曾參與開發的其它小組成員，以旁觀者的身份進行觀察，發現

　　目前存在的一些問題：

　　1. 系統功能不穩定，很多基本功能都會偶爾冒出問題，搞得實施人員提心吊膽，對產品沒信心。
　　2. 系統中出現一些低級錯誤，比如分頁功能出錯，上傳文件的功能沒有文件類型過濾...諸如此類，有失專業水準。
　　3. 只支持IE瀏覽器，但對IE6和IE8不支持，只能強迫用戶安裝IE7，并且要用兼容模式瀏覽，使用很不方便。
　　4. 因為不同項目的需求不同，客戶的界面風格喜好不一樣，所以為各個項目的修改和定制花費大量精力。
　　5. 在修正客戶所提的bug過程中，時常引入另外的bug，把原本好的功能弄出錯誤。
　　6. 對運行環境的測試不充分，遇到64位操作系統或者英文版操作系統，就會出一些問題。
　　7. 數據庫限定太死，目前只支持ORACLE，且限定在特定的版本，如果使用ORACLE的RAC還會很麻煩。
　　8. 部署太麻煩，手動執行數據庫腳本，配置文件有好幾個，每次換IP或者數據庫發生變動，要手動替換好些字符串，最讓人郁悶的是居然把URL地址記錄在數據庫表里。
　　9. 沒有運行日志記錄，所以很難由客戶提供運行的異常信息，只能自己調試。

　　這樣的問題其實一直都存在，只是以前我不知道罷了，但實施人員多次反映，客戶也一直提出問題，依然得不到徹底的解決，使我更加迷惑。于是通過與開發人員和實施人員的交流，了解到造成困局的一些原因：

　　1. 前期需求不完整，造成后期的變更頻繁，開發人員難以應付。
　　2. 數據庫訪問存在多種方式：JDBC, Hibernate和公司研發的訪問組件。
　　3. 最初的項目是在ORACLE上實施，所以一直以此為目標數據庫，沒有兼顧到其它數據庫，也沒有測試過RAC環境。
　　4. 由于考慮到一些界面效果，使用了IE7上的特性，造成瀏覽器不兼容。
　　5. 各功能模塊之間的耦合度太高，相互依賴，所以牽一發而動全身，不敢輕易改動。
　　6. 由于缺少測試人員，開發人員只能自己測試，但沒有使用單元測試和自動化測試工具，也沒有壓力測試和運行環境的測試。
　　7. 各個項目同時實施，開發人員身兼各個項目的技術支持和維護，版本維護和代碼修改難免出現混亂。

　　出現這樣的局面，其實是多方面的因素：需求分析、過程管理、架構設計、代碼質量等。但個人覺得，最主要的還是沒有做好系統設計，缺乏整體規劃，過早進入編碼階段，使得系統僵化，擴展能力不足，無法靈活應變。所以我才想到了系統設計規劃這樣一個主題，這個主題也沒有什么明確的定義，個人理解是對軟件產品和項目的一個分析和評估，考慮系統所涉及的幾個重要方面，并做好相應的準備，但不涉及解決方案的細節。同時，系統設計規劃也不同于架構設計和詳細設計，個人認為后兩者更偏向于業務邏輯的分層和模塊組織，以及核心類設計，更偏向于業務和代碼實現。根據個人的設計經驗，對系統進行分析和評估應該考慮以下幾個因素：

　　1. 技術選型
　　2. 分層設計
　　3. 數據庫設計
　　4. 技術難點
　　5. 技術標準與行業規范
　　6. 性能設計
　　7. 測試設計
　　8. 調試設計
　　9. 安全設計
　　10. 部署設計

　　在這所列的10個因素中，前5個是經常涉及的，也是考慮的較多的，但后5個可能考慮的不多。這些因素，每個都是一個很大的主題，背后都有很深的理論知識和豐富的實踐素材，沒有人能給出一個統一的解決方案。所以，我這里只是用圖表的形式進行劃分，并列舉出每個主題的相關內容和關注點。每個關注點背后也都涉及到很多知識，在系統設計時，需要結合著自身的開發實際和需求進行取舍，并找到適當的應對策略。總之，我的目的是希望在系統設計之初，做好宏觀的分析和把握，制定出合適的解決方案，使得系統從容應對后期的需求變更和代碼維護。

　　上圖所列內容完全來源于個人經驗，定有許多不足之處，還望補充和指正。