- 推薦序一:架構師真正要學會的事情
- 2. 要學會去聽,然後忘掉
- 3. 要學會去做,然後忘掉
- 4. 要學會超越
- 推薦序二
- 譯者序2.0
- 初識軟件架構
- 怎麼會翻譯這本書
- 架構離我們並不遙遠
- 周愛民老師的序
- 謝謝你們
- 序
- 軟件架構的壞名聲
- 敏捷願景
- 那麼你覺得自己是架構師嗎
- 失意的架構師
- 關於本書
- 本書寫作初衷
- 軟件開發的新方法
- 關於軟件架構,每個開發者都應該知道的五件事
- 在微博上分享這本書
- 軟件架構培訓
- Part Ⅰ 什麼是軟件架構
- 第1章 什麼是架構
- 作為名詞
- 作為動詞
- 第2章 架構的種類
- 它們的共同點是什麼
- 第3章 軟件架構是什麼
- 應用程序架構
- 系統架構
- 軟件架構
- 企業架構:戰略而非代碼
- 第4章 敏捷軟件架構是什麼
- 理解「敏捷」
- 好的架構帶來敏捷
- 你需要有多敏捷
- 第5章 架構對上設計
- 找出區別
- 理解意義
- 第6章 軟件架構重要嗎
- 缺乏軟件架構將引發問題
- 軟件架構的好處
- 所有軟件項目都需要軟件架構嗎
- 第7章 問題
- Part Ⅱ 軟件架構的角色
- 第8章 軟件架構的角色
- 1. 架構驅動力
- 2. 設計軟件
- 3. 技術風險
- 4. 架構演化
- 5. 編寫代碼
- 6. 質量保證
- 合作或失敗
- 技術領導是一個角色而非級別
- 提出你自己對這個角色的定義
- 第9章 軟件架構師應該編碼嗎
- 編寫代碼
- 構建原型、框架和基礎
- 進行代碼評審
- 實驗並與時俱進
- 軟件架構師和僱主之間的矛盾
- 你不必放棄編碼
- 不要把全部時間都用於編碼
- 第10章 軟件架構師應該是建造大師
- 聯盟的狀態
- 回顧過去
- 建造大師真的會建造嗎
- 象牙塔
- 建造大師角色的差異
- 實現角色
- 架構師要和團隊一起工作
- 第11章 從開發者到架構師
- 經驗是一個好的評價標準,但你需要看得更深
- 模糊的界線
- 跨越界線是我們的責任
- 第12章 拓展T
- 進一步的技術能力
- 知識面寬
- 軟件架構師是通才型專家
- 軟件架構是技術活
- 第13章 軟技能
- 保持積極
- 第14章 軟件架構不是接力運動
- 解決方案架構師
- 要有人負責大局
- 第15章 軟件架構要引入控制嗎
- 提供指導,追求一致性
- 控制的程度
- 控制因文化而不同
- 操縱桿,而非按鈕
- 第16章 小心鴻溝
- 開發者關注底層細節
- 閉門造車的獨裁架構師
- 拉近距離
- 軟件架構的合作方式
- 第17章 未來的軟件架構師在哪裡
- 指導、輔導和師徒關係
- 我們正在失去技術導師
- 軟件團隊需要休息
- 第18章 每個人都是架構師,除非他們有其他身份
- 每個人都是架構師
- 除非他們有其他身份
- 敏捷需要架構嗎
- 第19章 軟件架構咨詢師
- 領域知識
- 權威
- 第20章 問題
- Part Ⅲ 設計軟件
- 第21章 架構驅動力
- 功能需求
- 質量屬性
- 約束
- 原則
- 理解影響
- 第22章 質量屬性(非功能需求)
- 哪些對你重要
- 第23章 處理非功能需求
- 捕捉
- 提煉
- 挑戰
- 第24章 約束
- 時間和預算的約束
- 技術約束
- 人員約束
- 組織約束
- 約束都是不好的嗎
- 約束可以劃分優先級
- 傾聽約束
- 第25章 原則
- 開發原則
- 架構原則
- 謹防最佳實踐
- 第26章 技術不是實現細節
- 你有複雜的非功能需求嗎
- 你有約束嗎
- 你有一致性嗎
- 推遲與解耦
- 每個決策都是權衡
- 第27章 更多分層等於更高複雜度
- 非功能需求
- 時間和預算:沒有什麼是免費的
- 第28章 協同設計是一把雙刃劍
- 經驗影響軟件設計
- 第29章 軟件架構是對話的平台
- 軟件開發不只是交付特性
- 第30章 SharePoint項目也需要軟件架構
- 很多SharePoint實現都不只是SharePoint
- 非功能性需求仍然適用於SharePoint解決方案
- SharePoint項目很複雜,也需要技術領導力
- SharePoint解決方案仍然需要編寫文檔
- 強大的領導力和紀律不只是針對軟件開發項目
- 第31章 問題
- Part Ⅳ 可視化軟件
- 第32章 溝通障礙
- 拋棄UML
- 敏捷需要良好的溝通
- 第33章 對草圖的需要
- 測試驅動開發與圖表
- 為什麼人們應該學習如何畫草圖
- 畫草圖不是藝術
- 畫草圖不是綜合模型
- 畫草圖可以是協作活動
- 第34章 無效的草圖
- 採購清單
- 只有框沒有線
- 「功能視圖」
- 航線圖
- 一般正確
- 推遲技術
- 部署和執行上下文
- 太多假設
- 無家可歸的C#對像(HOCO)
- 選擇你自己的冒險
- 應該用白板
- 創建有效的草圖
- 第35章 C4:語境、容器、組件和類
- 通用的抽像集合
- 總結軟件的靜態視圖
- 通用標記法的通用抽像
- 圖應該簡單且腳踏實地
- 第36章 語境圖
- 意圖
- 結構
- 用戶、演員、角色、人物等
- IT系統
- 交互
- 動機
- 受眾
- 示例
- 第37章 容器圖
- 意圖
- 結構
- 容器
- 交互
- 系統邊界
- 動機
- 受眾
- 示例
- 第38章 組件圖
- 意圖
- 結構
- 組件
- 交互
- 動機
- 受眾
- 示例
- 第39章 是否包含技術選擇
- 在設計過程中繪圖
- 回顧性繪圖
- 架構圖應該概念化
- 明確技術選擇
- 第40章 你會那樣編碼嗎
- 共享組件
- 分層策略
- 圖應該反映現實
- 第41章 軟件架構和編碼
- 職責驅動設計和組件分解
- 我們談論組件但編寫類
- 用層封裝代碼
- 用特性封裝
- 用組件封裝
- 對齊軟件架構和代碼
- 第42章 你不需要UML工具
- 有很多類型的UML工具
- 既有效又簡單
- UML的用途
- 沒有銀彈
- 第43章 有效的草圖
- 標題
- 標籤
- 形狀
- 職責
- 線條
- 顏色
- 邊框
- 佈局
- 方向
- 要點
- 圖表的評審清單
- 傾聽問題
- 第44章 C4的常見問題
- 語境圖上的系統名稱
- 混合的抽像層次
- 共享組件
- 工具組件
- 從IT的角度勾畫企業語境
- 第45章 問題
- Part Ⅴ 為軟件生成文檔
- 第46章 代碼不會講述完整的故事
- 代碼未描繪的設計意圖
- 輔助信息
- 第47章 軟件文檔即指南
- 1. 地圖
- 2. 景色
- 3. 歷史和文化
- 4. 實用信息
- 保持短小簡潔
- 注意「視圖」
- 產品與項目文檔
- 第48章 語境
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第49章 功能性概覽
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第50章 質量屬性
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第51章 約束
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第52章 原則
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第53章 軟件架構
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第54章 外部接口
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第55章 代碼
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第56章 數據
- 意圖
- 結構
- 56.3 動機
- 受眾
- 是否必須
- 第57章 基礎設施架構
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第58章 部署
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第59章 運營和支持
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第60章 決策日誌
- 意圖
- 結構
- 動機
- 受眾
- 是否必須
- 第61章 問題
- Part Ⅵ 開發生命週期中的軟件架構
- 第62章 敏捷和架構的衝突:神話還是現實
- 衝突1:團隊結構
- 衝突2:流程和產出
- 軟件架構提供了TDD、BDD、DDD、RDD和代碼整潔的分界線
- 從象牙塔和大型預先設計中分離出架構
- 第63章 量化風險
- 概率與影響
- 設定風險的優先級
- 第64章 風險風暴
- 步驟1:畫一些架構圖
- 步驟2:分別識別風險
- 步驟3:匯總圖中的風險
- 步驟4:對風險設定優先級
- 緩解策略
- 何時使用風險風暴
- 集體所有制
- 第65章 恰如其分的預先設計
- 回到方法學
- 要做到「恰如其分」
- 多少預先設計是太少
- 多少預先設計是太多
- 多少是「恰如其分」
- 把恰如其分的預先設計置於適當的語境
- 第66章 初識軟件架構
- 軟件架構應該容易理解
- 一些實用的建議
- 推動變革發生
- 軟件架構的本質
- 第67章 問題
- Part Ⅶ 金融風險系統
- 第68章 金融風險系統
- 功能需求
- 非功能需求
- Part Ⅷ 附錄:「技術部落」的軟件指南
- 介紹
- 語境
- 功能性概覽
- 質量屬性
- 約束
- 原則
- 軟件架構
- 基礎設施架構
- 部署
- 運營和支持
- 看完了
程序員必讀之軟件架構
內容簡介:通常,人們對軟件架構師持兩種錯誤的看法。有人認為軟件架構師是一種高高在上的職位;有人認為軟件架構師完全不懂開發,只是會畫條條框框的指揮家。本書將打破這些傳統的認知,模糊軟件開發和架構在流程中的界限,進而為軟件架構正名。本書是一本強調實踐、注重實效、輕量級、面向開發者的軟件架構指南。……