目錄
- 宏觀上的“系統架構”
- 系統架構圖（舉例）
- 微觀上的系統設計
- 生產者-消費者 設計圖（舉例）
- 宏觀架構與微觀設計的區別
- 孰輕孰重？
- 三種執行緒
- 泵的作用
- 程式碼中泵的作用
- 常見泵結構（1）
- 常見泵結構（2）
- 常見泵結構（3）
- 常見泵結構（4）
- 常見泵結構（5）
- 序列處理資料的泵
- 並行處理資料的泵
- 泵對於系統的意義
- 什麼是框架？
- 框架的特點
- 框架的作用（1）
- 框架的作用（2）
- “機場資源排程模擬模擬系統”設計草圖
- 幾個問題
- 問題答案（1）
- 問題答案（2）
- 微觀上看機場系統
- PPT下載
- 系統主要功能（需求分析）
- 確定系統最終使用場合
- 系統劃分模組
- 各模組間怎樣協作
- 每個模組技術模式（C/S(或單機)、B/S、移動app）
- 每個模組採用什麼技術開發
- 出系統架構圖、相關文件
- 系統框架搭建（編碼）、專案組成員培訓（指導）
- 系統執行的持續性（動力）
- 系統處理資料的重複性
- 系統的可擴充套件性（=>框架）
- 系統的容錯性
- 系統的通用性（=>框架）
前者：
- 站得高看得遠，將重點放在整個系統組成上。幾乎不涉及到“編碼”；
- 架構者需要熟悉各種技術，瞭解各種技術優劣以及適用場合；
- 架構者需要豐富的專案經驗。
後者：
- 注重程式碼實現，側重系統內部實現原理；
- 設計者需要豐富的編碼經驗；
- 設計者與if/else/while等打交道。
當你為了解決某個具體問題而設計一個系統時，如果做到了：
- 通用性好。不過分依賴其他模組，不限制處理特定業務；
- 容錯性高。內部包含一套專門異常處理機制；
- 擴充套件性強。方便增加新的功能；
- 提供一套專門類庫。
這時候，就可以把該系統當作一個框架。它可以用來處理某一類問題。
- 動力性
- 持續性
- 通用性強
- 可擴充套件性高
- 容錯性好
理論上，任何一個框架不做任何改變，直接編譯即可執行。
- 整個系統怎樣維持一個“持續運轉“的狀態？
- 服務端怎樣能夠持續處理客戶端的輸入？
- 怎樣維持地圖中各元素的狀態？
- 系統時間怎樣統一？
- 怎樣維護訓練指令碼狀態？
（以上內容為公司第四次交流會內容）