說明: 前端
這篇隨筆,是我在閱讀《代碼大全》這本書的【前期準備】這一章節的時候,所做的筆記。java
由於翻譯著做一般比較冗長,所以我將這一部分簡單概括了一下。程序員
其中,我略去了在如今的軟件開發中通常不會遇到的問題,斜體部分是我結合我的工做經歷的一些理解(我主要從事的是java-web系統開發)。web
原文見於《代碼大全》P45。算法
在進行架構設計以前,咱們首先應該明白架構應當由哪些部分組成,這樣在每一次自行設計架構,或運用別人設計好的架構的時候,都可以迅速地找到最重要的組成部分。數據庫
一、程序組織。後端
- 以歸納的形式對整個系統做一個綜述,描述組織結構。
- 系統由哪些構造塊(子系統)組成。好比用戶界面、命令解釋、封裝業務規則、訪問數據。在Java web中,他們分別爲前端、MVC框架、服務器接口,以及mybatis或jdbc等數據庫操做工具。
- 應該明確每個構造塊的責任和負責的區域,不一樣的構造塊之間應該儘可能獨立。好比咱們常見的先後端分離式開發,controller、service、dao三層設計(若是用jsp等技術作界面展現,則爲四層)等。
- 應該明確不一樣構造塊之間的通訊規則,對於每一個構造塊,架構應該指出它能使用哪些構造塊,或者不能使用哪些構造塊。好比規定controller和service層傳參必須使用POJO類,controller能使用service層,但不容許直接調用dao層等。
二、數據設計緩存
- 數據庫設計時採用何種規範?爲什麼如此設計?好比是使用自增 id仍是由代碼生成 id等。
- 數據一般只應由一個或一組類來訪問。
三、業務規則安全
- 架構是否依賴特定的規則,以及架構須要做哪些特別設計來適應這種規則?好比同步問題
四、安全性服務器
- 應該描述實現設計層面和代碼層面的安全性的方法。好比如何處理緩存,如何處理非受信數據,如何加密等等。
五、性能
- 應該詳細定義性能指標。
- 應該詳細定義不一樣性能之間的優先順序。(如響應速度、內存、併發數等等)
- 詳細描述:
- 在當前設計下,爲何能達到性能要求?
- 系統所能承受的最大負荷?
- 當業務量增大時,哪些部分可能會最早達不到性能指標,風險最大?
- 爲了知足性能指標,須要在哪些地方進行特殊的算法/結構設計,對開發成本和週期有何影響?
六、可伸縮性
- 架構應該描述系統如何應對諸如用戶數量增加、訪問量增加、數據庫記錄數增加等業務不斷增加的狀況。
- 若是預計業務不會增加(或增加不會超出預期),則架構應當明確地列出這一假設,好比一些公司內部使用的erp軟件、財務系統等。
七、國際化/本地化
- 將一些提示信息、幫助信息、錯誤信息等等集中管理,而不是分散在代碼各處,以便在不一樣的語言環境中可以輕易替換。
- 儘可能作到讓不懂技術的人也能去維護這些字符串
- 決定是在配置文件中配置這些信息,仍是能夠經過數據庫動態修改?爲何?
- 總之,要儘可能作到在不修改源代碼,或者不重啓服務器(假若有的話)的狀況下,就能作到所有替換。
八、輸入/輸出 Input/Output
- 定義讀取和寫入策略
- 應該描述在那一層檢測I/O錯誤:在字段、記錄、流、或者文件的層次。
九、錯誤處理
- 在什麼層次上處理錯誤?是否規定某一個層次無權處理異常,必須所有將其拋出?
- 指出在進行數據驗證的時候,是每一個類都須要進行數據驗證,仍是規定只須要某一個層次或某一些類須要進行驗證,而且另外的類則能夠直接假設數據是被驗證過的、值得徹底相信的。
- 是使用環境內建的異常機制,仍是本身創建一整套新的機制?好比在java中,自定義一些繼承自Exception類的異常類。
十、容錯性
- 在遇到錯誤的時候,是否能迅速從錯誤中恢復(好比關機、重啓),並清除其不利影響?
十一、可行性
- 架構師多半會關注系統的各類能力,例如是否達到性能目標,可以在有限的資源下運轉,實現環境(運行環境)是否有足夠的支持。
- 架構應該論證系統的技術可行性。若是在任何一個方面不可行都會致使項目沒法實施,那麼架構應該說明這些問題是如何考慮的。
十二、過分工程
- 過分工程師指程序員爲了使系統擁有超過需求中定義的能力而進行的額外工做。
- 「健壯性」是指「系統在發生錯誤以後繼續運行」的能力。
- 架構描述的系統應該比需求描述的系統更健壯。
- 組成系統的各部分不該該只在最低限度上知足健壯性要求。
- 應該將精力均勻地花費在系統各部分的「過分工程」上面,不該該由於我的好惡,出現「某些部分異常健壯,某些部分勉強健壯」。
1三、不要重複造輪子
- 關注行業裏已有的各類組件、技術,看是否能夠知足本身的需求;
- 本身須要的組件、技術是否開源?若是不開源,成本多少?
- 本身從新開發,和直接購買相比,哪個更有優點?