架構需要詳細的分析，分解業務再做決策
先接觸專案在進行架構選型，這個時候你得盡可能多的收集業務相關的資訊。
你也可以推遲架構決策，盡可能多的收集專案相關的資訊，因為確定架構後再去調整它的代價是最大的。
對架構師來說，技術知識基礎，快速的學習和完善你的業務領域知識，才能讓你做出盡可能好的決策。
熟練的業務知識，有助於溝通，增加客戶的信心，同時對難題，有爭議的問題，業務目標，以及資料和流程，能提供更加好的解決方案
程式設計是一種發現和學習的過程。而不是生產的過程。
我們可以從其他行業裡面去學習。
97條架構建議 架構平衡 負責 多方案
軟體架構常考慮的 系統建模，定義介面，劃分功能模組 套用模式，優化效能 安全性，易用性，產品支援，發布管理，部署方式等問題除了上面的技術架構外，軟體架構師還必須考慮各方的要求和利益。只有充分考慮了各方面的要求，才能確保需求說明書的完整性。架構師實現的一組最終目標可以通過逐步分析相關各方的需求得到。這...
97條架構建議 空白 行話 情境
軟體系統由相互依賴的程式組成，我們裝備這些程式和方法見的關聯叫做架構 我們一般會通過簡單的圖形表示系統，這是種抽象和概括。其實系統遠比這複雜，還有許多空白需要填補。包括硬體的問題。在確定主幹後，我們應該考慮更多，考慮越多我們最後遇到的問題就越少。每個行業都有它自己的行話，軟體行業也不例外。架構和設計...
資料處理專案Beta階段軟體架構建議
string serverip string serverpassword string sqlaccount string sqlpassword bool dataupdate int id,string key,string content 用來更新資料，id用來定位更新的位置 key是要更新...