軟體架構師應該知道的97件事 筆記(五)

63.
架構師首先是開發人員
身居要位仍然要繼續跟進各自領域的發展。獲得開發人員的尊重和信任，讓開發人員自願接下任務。
時不時的去處理一些比較複雜的任務，目的：a)讓自己做到寶刀不老 b)有助於向開發人員證明自己不是只會吹牛皮的
主要目標是建立可行、可維護的解決方案。且自己設計的系統自己應該能編程實現。

64.
根據投資報酬率(ROI)進行決策
我們對項目所做的每一個決策--無論是技術、過程、還是與人相關都可以看作是一種投資形式。假設產品上市時間對投資方是至關重要的，那麼快速發布就能帶來更高的投資報酬率，這個時候“完美的架構”就不如架構稍差，但能快速完成的版本。
將架構決策視為投資，並將相關的回報率也一併考慮在內。

65.
一切軟體系統都是遺留系統
系統再先進，對接手它的人而言，都是遺留系統，所以不應該排斥這個標籤。

66.
起碼要有兩個可選的解決方案
對某個問題，如果只考慮了一個解決方案，就有麻煩了。如果沒有對比其它方案之前就想當然地給出瞭解決方案，那就要三思了。

67.
理解變化的影響
架構師在解決方案中給出的抽象，應該能為更高的層次提供堅實基礎，應該能足夠務實地應付未來的變化。瞭解變化，包括人與人，系統與系統的。要清楚認識解決方案中變化的類型和將帶來的影響。

68.
你不能不瞭解硬體
架構師既要負責串連業務需求和軟體解決方案，也要負責串連硬體和軟體。硬體方面的一些知識同軟體架構一樣重要，比如說硬體的容災能力、容量規劃等。如果缺乏硬體規劃能力，最好和基礎設施架構師緊密合作。

69.
現在走捷徑，將來付利息
碰到架構問題或設計缺陷，作為架構師，一定要堅持成本還很低廉時就動手。擱置越久，為之付出的利息也就越高。

70.
不要追求“完美”，“足夠好”就行
“足夠好”指的是，剩餘的不完美之處，對系統的功能、可維護性或效能不會產生任何有深遠意義的影響。

71.
小心“好主意”
“好”主意的邪惡之處：它們是好的，不容易被發現它們的問題，如：某架構有升級版本，我們也應該使用新版本。某技術很強大，我們可以把它用於……

72.
內容為王
很多系統無止境地強調需求、設計、開發、安全等，從未關注系統真正的要點---資料。對基於內容的系統，資料尤其重要。在新系統的設計過程中，必須留出一部分精力專心考評內容庫。比如系統重點關注哪些內容，能否及時更新，內容主要來源等等。
系統的成功取決於其內容。

73.
對商業方，架構師要避免憤世嫉俗
自我感覺過於良好，往往會忘記傾聽，並且會拒絕聽取、分析別人的建議。過度自信，會讓你在業務領域頭破血流。業務是架構師職業存在的原因，為商務服務是我們的生存之本，傾聽和瞭解僱主的業務，是我們必須掌握的最為關鍵的技能。
不能只提批評意見，還需要針對不足提出建設性的意見。

74. 展開關鍵維度，發現設計中的不足
通過某些關鍵維度被展開，可以以此來發現系統設計的限制。(即提前想象某些維度被擴大、展開)
如：瞭解基礎設計的規劃是否能夠應付增長的需求，圈出限制範圍。對輸送量的峰值能否正常處理等等。

75. 架構師要以自己的編程能力為依託
為項目設計架構時，對實現每個設計項目所需的工作量，要做到心中有數：如果以前曾開發過其中某中設計項目，那麼估算所需工作量就會容易得多。
不要在設計裡使用自己沒有親自實現過的模式，不要使用自己沒有用之寫過代碼的架構等等，如果架構依賴於各種你未曾親身使用過的設計項目，那其中就存有許多負面影響，如無法估計實現設計所需的時間，無法容易的避免那些設計項目裡面的陷阱，開發人員遇到問題時無法向你請教等等。
(架構師平時緊跟職業步伐，平常多關注，多自己使用一些架構、模式等，在需要使用這些東西的時候，肯定是有經驗的了)

76. 命名要恰如其分
如果不知道一個東西應該叫什麼，那你肯定不知道它究竟是什麼。
如果無法給出個合適的命名，那也就無法繼續編程。如果發現自己需要多次理性命名，那麼最好停下來，直到弄清楚要做的究竟是什麼。
一定要起個好名字！！！！！！！！

77. 穩定的問題才能產生高品質的解決方案
最好的架構師不是去解決難題，而是圍繞難題開展工作。架構師要能夠將四處瀰漫的軟體問題圈起來，並畫出其中的各邊界，確保對問題有穩定、完整的認識。
如果問題是穩定的，那麼問題解決之後，就永遠不會再來煩你。

78. 天道酬勤
具有創造力雖然是成功架構師的一項重要特質，不過成功架構師同樣還需要具有勤奮的特質。很多時候不是能力不足導致項目失敗，而是由於勤奮不夠，緊迫感不強導致的。

79. 對決策負責
很多失敗的項目，究其根本原因，是因為做出了不當的決策，或無法執行正確的架構決策。
做出有效決策的方法：
a)對決策過程有充分的認識（決策以書面形式記錄下來了，與決策執行人溝通過）
b)定期對架構決策進行複審，檢查決策的實際效果和預期結果。
c)要貫徹架構決策，架構師不僅要參與設計階段，後續仍然要持續跟進。
d)可以將一些決策交給問題域專家。

80. 棄聰明，求質樸
小聰明會誘導我們在軟體開發中使用奇技淫巧。聰明的設計僵硬難改，細節會對全域產生太多的牽扯。質樸的方案中，每個組件只做一件事，組件耗時少，易於建立，以後維護也更容易。