《軟體架構師應該知道的97件事》摘…
阿新 • • 發佈：2019-01-22
- 關注根本複雜性，消除偶發複雜性，抽絲剝繭制定解決方案，才是真正的挑戰。
- 人才是專案成敗與否的基礎，對話是最古老但很完善的技術幫助你解決問題。學會尊重他人，給予團隊成員充分的信任，是聰明的架構師獲得成功必須掌握的核心技能。對話技巧——不要把對話當成對抗；不要帶著情緒與人溝通；嘗試通過溝通設定共同的目標。
- 架構是決定應用效能的根本因素。
- 分析客戶提出的需求，定位真正的問題。
- 起立發言無形中增添了一種權威和自信，自然就控制了場面。聽眾不會輕易打斷你的發言。這些都會讓你的發言效果大為改觀。
- 只有認識到故障始終會發生的這一事實，才能針對特定的故障設計對策。
- 專案投資人在和你討論專案及各類資源需求時，他明白他在和你談判，會絞盡腦汁佔得先機，故決不能在該決斷下來的要求上妥協讓步。
- 所有需求必須量化，不允許出現“靈活”、“易擴充套件”等詞，這導致驗收時缺乏依據。
- 不存在放之四海皆準的解決方案，也不可能做出一個十全十美的設計，需要在效能、可用性、安全等問題上做好平衡。
- 提前關注效能，即在專案開始不久，就需要對專案週期性地進行效能測試，這樣做可以在前期確定架構是否有問題，另外，也提供了一個起始基準，為今後診斷和解決效能問題提供重要依據。
- 建設好團隊的工作氛圍和良好的工作習慣，不允許草率提交開發任務。儘量給開發人員提供一些方便的建構和測試手段，減輕開發人員的負擔。
- 業務目標至上，必須在業務、技術方面做好平衡。
- 解決方案先簡單可用，再考慮通用性和複用性。
- 不要目空一切高高在上，認為什麼都懂什麼都對；不要炫耀技術才華，甚至是刁難開發團隊，而且應該親力親為，並將技能傳授給開發人員。
- 要頂住壓力，輕易不要縮短進度或調整進度。
- 重視不確定性。這時要設法利用分離或封裝將決策和最終依賴於決策的程式碼隔離開。
- 不要輕易放過不起眼的問題，多和客戶、團隊成員溝通。
- 讓大家學會複用——讓大家知道它們存在；讓大家知道如何使用它們；讓大家認識到利用已有資源好過自己動手。
- 先嚐試後決策。對於複雜或者不確定的問題時，先做個小專案嘗試驗證後再對其做出決策。
- 應該掌握並精通業務領域知識，才能成為一個好的架構師。
- 專案不易過大，可以把一個大專案分成幾個小專案分階段來完成，這樣失敗的可能性也會大大降低。
- 不管是開發新專案還是替換已有的系統，都應該分段式部署。