有感於目前公司的乙個專案產品中遇到的一些問題，結合著自己的設計與開發經歷，總結一下系統設計與規劃的必要性和知識點，作為將來設計的參考，也與大家一同**系統設計中要注意的各方面。
產品簡介：該產品是乙個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.部署設計
上圖所列內容完全**於個人經驗，定有許多不足之處，還望補充和指正。
系統設計與規劃 一點總結
有感於目前公司的乙個專案產品中遇到的一些問題，結合著自己的設計與開發經歷，總結一下系統設計與規劃的必要性和知識點，作為將來設計的參考，也與大家一同 系統設計中要注意的各方面。產品簡介 該產品是乙個webgis系統，歷經2 3年的開發與實施，目前準備從專案公升級為產品，但是在專案實施中暴露出大量問題，...
規劃一點心得 學會放棄
最近，在做公司明年整體的研發規劃和產品規劃。但無論如何規劃，總覺得需要更多人力來參與 而今年11月中旬開規劃的專項會議時，已明確提出明年的人才招聘控制在較小的規模，公司通過提高管理和改進流程來提高內功，不進行較大規模產品線和團隊的擴張。開始時我認為，是不是產品線規劃的過於豐富了，但仔細審查發現這些工...
一點感想總結
這兩天總有個習慣，早早的起來讀散文，深深的感覺到那散文上文字的美，不知不覺就在那優美的語句中感受那種超然的意境了。只是，很多時候，感覺是乙個人在走著自己的路，靜靜地體驗著那蕭索的美。一段時間以來，都沒有好好的讀書學習了，心裡感覺很內疚，很矛盾 一方面，想著要好好的振作起來，不能就這樣 浪費自己的時間...