設計架構
Architecture is your design structure, and highlights the most important parts of your application, and the relationships between those parts.
架構是系統的組織結構，包含分解開的各個元件、元件間的關係、互動機制，以及系統設計中使用的原則及決策。
這次英文比中文好懂一點。
就我的理解，architecture 是整個軟體的結構，有點像骨架。其他那些 requirement、class diagram、design pattern、use case 等等東西就像軟體的，呃，肉(?)，有骨架後就能把這些內容填進去。（寫到這裡開始懷疑我到底是怎麼理解這些概念的…）
設計 architecture 的階段會整理出那些 component 是重要的、建立處理順序，以及減少風險。
如何找出重要的事情？
可以問幾個問題：
- 它是系統本質的一部份嗎？
可以用「如果沒有這個功能，這系統還會是它應該是的東西嗎？」來思考。 - 某個功能究竟是什麼意思？
理解功能真正的意思，不懂就問客戶，或者任何要你做這玩意的人。盡量避免你以為你知道那是什麼但其實你不知道的狀況（繞口令時間）。 - 如何實作某個功能？
挑出最困難的部分。不過一項實作困難程度會因人而異。
從誰開始？
找到最重要的幾件事情後，要決定從哪個部分開始。
這裡的重點是「減少風險」。只要能減少風險，從誰開始都可以。所謂風險，諸如 schedule 來不及、做出不是客戶要的東西等等。
在設計架構的階段要做可以減少風險的事，延後不能減少風險的事情。
如何減少風險？
- 用 scenario 找出大部分的重要 requirement
scenario 是穿過 use case 裡的一個路徑，也就是一段系統如何被使用的敘述。 - 延後進入細節的時間，因為在架構階段進入細節無法減少風險。
- 不要在架構階段寫詳細的 use case。
- 延後細節的 coding
可以先有個框，但不要開始寫邏輯細節。
- 有好的 design
- 一開始就把事情做對
- 利用 commonality analysis（共通性分析）設計具有彈性的軟體
- 搞不清楚意思或軟體要幹嘛時去問客戶，以降低做出不是客戶要的東西的風險。
寫好軟體的方式是先做好了解需求、規劃、組織、架構以及減少風險，盡可能延後 coding、避免在前期一頭栽進細節。