軟體架構是在軟體需求出來之後，軟體構建開始之前的工作
架構師應該確定的事情有：
1 程式組織
架構應該定義程式中的主要構造塊。
根據程式規模不同，各個構造塊可能是單個類，也可能是由多個類組成的系統。每個構造塊實現乙個高層功能。並且每個需求都至少有乙個構造塊覆蓋它。
定義各個構造塊之間的通訊規則和依賴規則
2 主要的類
架構應該詳細定義或寫出所用的主要的類。並指出該類如何與其他類互動。
架構不需要對所有類進行說明，使用82法則：對構成系統80%功能的20%類進行說明
3 資料設計
架構應該說明清楚用到的資料表的設計，並且描述為何做出這樣的選擇
4 業務規則
對特定的業務規則（比如:客戶資訊的更新時間不能超過30秒）要有架構方面的描述（比如30秒內對客戶端進行資訊同步）
5 使用者介面設計
架構應該有詳細的使用者介面，好的使用者介面直接關係到功能的實現和軟體的最終效果
6 資源管理
架構應該對稀缺資源有管理計畫。比如資料庫連線，執行緒，控制代碼等的使用。有可能需要設計乙個「資源管理器」的模組
7 安全性
架構應該描述使用者據輸入資料，cookie，配置檔案等的安全性說明
8效能應該根據需求文件中對效能的描述來提供估計的效能資料，並且說明為什麼架構師相信能達到效能目的。或者為什麼有的效能指標無法達到
9 可伸縮性
架構應該說明系統如何應對以後使用者數量，伺服器數量，網路節點數量，資料庫記錄數，資料庫記錄長度，交易量等增長的需求。
10 互用性
如果系統與其他軟體或硬體有共享資源，架構應該說明如何完成這項功能
11 國際化/本地化
系統式是否支援國際化，如何在與使用者互動的模組中實現國際化
12 輸入輸出
架構應該詳細定義讀取策略
13 錯誤處理
有人估計程式中高達90%的**是用來處理異常和錯誤的，意味只有10%的**是用來處理常規情況的。
需要考慮的問題包括：
錯誤處理是進行糾正還是只進行檢測
錯誤檢測是主動還是被動
程式如何傳播錯誤，是立刻丟棄還是通知乙個地方
錯誤處理有什麼約定
如何處理異常，什麼時候能丟擲異常，什麼地方log，什麼地方捕獲
在什麼地方處理錯誤，是傳遞到專門處理錯誤的地方還是沿著函式鏈往上傳遞錯誤
每個類的輸入資料額有效性方面如何負責
是希望用執行環境內建的錯誤處理機制還是自定義一套機制
14 容錯性
容錯是增強系統可靠性的技術，如果出現了錯誤是轉入「部分運轉」還是「功能退化」?
15 架構的可行性
架構師應該論證自己這個系統設計的可行性
16過度工程
即健壯性。架構應該指出哪些類哪些模組需要進行過度工程（健壯性測試），哪些類或模組只需要做出最簡單的工作效能
17 關於買還是造
一些軟體，開源**，處理程式，是使用現貨採購還是自己定製開發
18 關於復用
如果使用業界已經存在的軟體，開源**等資源，應該說明清楚如何對這些東西進行加工。
19 變更策略
架構應該清楚描述處理變更的策略。架構應該列出已經考慮過的可能會有變更的需求或者可能增強的功能。
並提供處理情況，比如使用版本號進行控制，或者將**設計成可動態新增新資料
20 架構的總體質量
架構應該清楚描述其做的所有主要決策的動機
明確指出有風險的地方
軟體架構應該做些什麼
大全 第三章讀書筆記 軟體架構是在軟體需求出來之後，軟體構建開始之前的工作 架構師應該確定的事情有 1 程式組織 架構應該定義程式中的主要構造塊。根據程式規模不同，各個構造塊可能是單個類，也可能是由多個類組成的系統。每個構造塊實現乙個高層功能。並且每個需求都至少有乙個構造塊覆蓋它。定義各個構造塊之間...
軟體架構應該做些什麼
大全 第三章讀書筆記 軟體架構是在軟體需求出來之後，軟體構建開始之前的工作 架構師應該確定的事情有 1 程式組織 架構應該定義程式中的主要構造塊。根據程式規模不同，各個構造塊可能是單個類，也可能是由多個類組成的系統。每個構造塊實現乙個高層功能。並且每個需求都至少有乙個構造塊覆蓋它。定義各個構造塊之間...
我們應該做些什麼！
我們應該做些什麼？什麼是有意義的？每個人對價值標準的不同而所表達的也就不一樣了。你愛思考嗎？一 誠實守信，核心價值觀 二 不貪小便宜，勿以惡小而為之 三 溝通表達的重要，非語言表達方式，開放式並互相尊重交流 四 對乙個國家，乙個集體，乙個公司合作是非常重要的。通過參加團體活動增強合作的意識。五 作乙...