收藏!架构师需要掌握的99条铁律
經(jīng)常有人問(wèn)我：我是多少年某某行業(yè)工作經(jīng)驗(yàn)，我現(xiàn)在是去創(chuàng)業(yè)公司做技術(shù)總監(jiān)還是去大公司做架構(gòu)師？我發(fā)現(xiàn)我都無(wú)法回答這個(gè)問(wèn)題。因?yàn)槎嗌倌昴衬承袠I(yè)工作經(jīng)驗(yàn)，并不能解析為具有怎樣的知識(shí)結(jié)構(gòu)和掌握的能力數(shù)量和深度，很難與相應(yīng)的職位需求進(jìn)行匹配對(duì)應(yīng)。
比如，架構(gòu)師，幾乎所有公司的架構(gòu)師需求都不完全一樣。為什么呢？軟件架構(gòu)師是 IT 行業(yè)里獨(dú)一無(wú)二的職業(yè)，既要精通軟件開(kāi)發(fā)技術(shù)，又要掌握業(yè)務(wù)知識(shí)，還要周旋于公司不同部門之間，協(xié)調(diào)各種矛盾。
以下是有志于成為架構(gòu)師或已經(jīng)是軟件架構(gòu)師的應(yīng)該知道的 99 件事，如果都精通吃透，應(yīng)用在日常工作中，百萬(wàn)年薪工作不是夢(mèng)。
1．??多去參加大會(huì)沙龍，跟成功的架構(gòu)師探討案例、思維模式和前沿技術(shù)。
自己摸索和嘗試耗費(fèi)很多時(shí)間，有時(shí)候需要廣交朋友，跟成功的架構(gòu)師們一起討論、一起成長(zhǎng)。捷徑是找到成功的架構(gòu)師，一起探討，走成功者走過(guò)的路。
2．??簡(jiǎn)化根本復(fù)雜性?，消除偶發(fā)復(fù)雜性
根本復(fù)雜性指的是問(wèn)題與生俱來(lái)的、無(wú)法避免的困難。偶發(fā)復(fù)雜性是人們解決根本復(fù)雜性的過(guò)程中衍生的。分析問(wèn)題好比撥云見(jiàn)月、水落石出。架構(gòu)師的責(zé)任在于解決問(wèn)題的根本復(fù)雜性，同時(shí)避免引入偶發(fā)復(fù)雜性。
3．??關(guān)鍵問(wèn)題可能不是出在技術(shù)上
大多數(shù)項(xiàng)目是由人完成的，人才是項(xiàng)目成敗與否的基礎(chǔ)。學(xué)會(huì)尊重他人，給予團(tuán)隊(duì)成員充分的信任，是聰明的架構(gòu)師獲得成功必須掌握的核心技能。團(tuán)隊(duì)同心，其利斷金。
4．??以溝通為中心，堅(jiān)持簡(jiǎn)明清晰的表達(dá)方式和開(kāi)明的領(lǐng)導(dǎo)風(fēng)格
溝通應(yīng)當(dāng)言簡(jiǎn)意賅、詳略得當(dāng)，別拖泥?帶水。
5．??架構(gòu)決定性能
種瓜得瓜，種豆得豆，架構(gòu)設(shè)計(jì)也是一樣道理。它是影響應(yīng)用性能和可伸縮性的決定因素，性能參數(shù)是無(wú)法簡(jiǎn)單地通過(guò)更換軟件，或者“調(diào)優(yōu)”底層軟件架構(gòu)來(lái)改善，必須遵循分布式計(jì)算和物理學(xué)的基本原理，必須在架構(gòu)的設(shè)計(jì)（或重新設(shè)計(jì)）上投入更多精力。
6．??分析客戶需求背后的意義
抽絲剝繭，洞見(jiàn)癥結(jié)。不要被表面需求迷惑。
7．??起立發(fā)言
讓溝通事半功倍，起立發(fā)言是最簡(jiǎn)單、有效的方法。
8．??故障終究會(huì)發(fā)生
系統(tǒng)必然存在不同形式的故障隱患，無(wú)論如何都無(wú)法徹底消滅，應(yīng)該提前設(shè)計(jì)預(yù)防措施，限制故障。
9．??我們常常忽略了自己在談判?
工程師應(yīng)該適時(shí)轉(zhuǎn)換角色，學(xué)習(xí)談判的技巧。絕不能在與對(duì)方談判的第一個(gè)要求上就妥協(xié)讓步。
10．?量化需求
沒(méi)有規(guī)矩，不成方圓。在記錄需求的過(guò)程中，對(duì)一些模糊的描述比如“靈活”，“可維護(hù)性”，“性能”等通過(guò)簡(jiǎn)單的問(wèn)題來(lái)量化需求，比如“數(shù)量多少”，“有多頻繁”，“不能超過(guò)多長(zhǎng)時(shí)間”等。如果缺乏客觀的標(biāo)準(zhǔn)，就只能任憑挑剔的用戶擺布。
11．?一行代碼比五百行架構(gòu)說(shuō)明更有價(jià)值
可工作的代碼才是目標(biāo)，設(shè)計(jì)只是達(dá)成目標(biāo)手段。摩天大樓的建筑師如果一味追求美觀而無(wú)視物理定律，遲早會(huì)自食其果。
12．?不存在放之四海皆準(zhǔn)的解決方案
軟件世界沒(méi)有放之四海皆準(zhǔn)的解決方案。架構(gòu)師必須培養(yǎng)和訓(xùn)練情境意識(shí)，才能更好地設(shè)計(jì)架構(gòu)和解決問(wèn)題。
13．?提前關(guān)注性能問(wèn)題
盡早展開(kāi)性能測(cè)試。尤其是對(duì)性能要求苛刻的系統(tǒng)，可以驗(yàn)證架構(gòu)和設(shè)計(jì)是否符合實(shí)際性能要求。
14．?架構(gòu)設(shè)計(jì)要平衡兼顧多方需求
平衡兼顧項(xiàng)目的技術(shù)需求和相關(guān)各方的業(yè)務(wù)需求。
15．?草率提交任務(wù)是不負(fù)責(zé)任的行為???（?Niclas?Nilsson?）
要設(shè)法杜絕開(kāi)發(fā)人員草率提交任務(wù)的念頭。
16．?不要在一棵樹(shù)上吊死???（?Keith?Braithwaite?）
為客戶提供多樣化的解決方案。
17．?業(yè)務(wù)目標(biāo)至上?（?Dave?Muirhead?）
技術(shù)決策不能脫離業(yè)務(wù)目標(biāo)和現(xiàn)實(shí)條件的約束。
18．?先確保解決方案簡(jiǎn)單可用，再考慮通用性和復(fù)用性?
如果存在多個(gè)可實(shí)施方案難以取舍，“先簡(jiǎn)單后通用”原則可以成為最終的評(píng)判標(biāo)準(zhǔn)。通過(guò)經(jīng)驗(yàn)提練的簡(jiǎn)單方案，遠(yuǎn)勝過(guò)不切實(shí)際的通用性。
19．?架構(gòu)師應(yīng)該親歷親為?（?John?Davies?）
身先士卒才能贏得同事的信任。
20．?持續(xù)集成?（?David?Bartlett?）
持續(xù)集成確保當(dāng)前的開(kāi)發(fā)不會(huì)出現(xiàn)意外，借助它可以取得更穩(wěn)定、更符合要求的開(kāi)發(fā)成果。
21．?避免進(jìn)度調(diào)整失誤?（?Norman?Carnovale?）
不惜一切代價(jià)拒絕調(diào)整項(xiàng)目進(jìn)度的要求。為提高交付速度而改變計(jì)劃會(huì)帶來(lái)一系列的問(wèn)題。
22．?取舍的藝術(shù)?（?Mark?Richards?）
架構(gòu)不可能滿足所有需求。魚(yú)和熊掌不可兼得，應(yīng)牢記瑞典和波蘭戰(zhàn)爭(zhēng)中瑞典瓦薩號(hào)（Vasa）戰(zhàn)艦的故事。
23．?打造數(shù)據(jù)庫(kù)堡壘?（?Dan?Chak?）
一開(kāi)始就要定義好數(shù)據(jù)模型。數(shù)據(jù)模型的設(shè)計(jì)必須做到能夠拒絕無(wú)效數(shù)據(jù)，阻止無(wú)意義的關(guān)系。
24．?重視不確定性?（?Kevlin?Henney?）
推遲決策，建設(shè)性地利用不確定性。推遲決定不是故意拖延，而是強(qiáng)調(diào)作出的決定應(yīng)該基于足夠的事實(shí)，不能僅憑假定和猜測(cè)。
25．?不要輕易放過(guò)不起眼的問(wèn)題?（?Dave?Quick?）
別忘了溫水煮青蛙的故事。
26．?讓大家學(xué)會(huì)復(fù)用?（?Jeremy?Meyer?）
重復(fù)利用已有資源，首先要改變大家的觀念。
27．?架構(gòu)里沒(méi)有大寫的“I?”?（?Dave?Quick?）
不要讓自己變成自大狂。辯解容易，難的是學(xué)會(huì)停止辯解，恃才傲物容易，難的是擁有自知之明。
28．?使用“?一千英尺高”?的視圖?（?Erik?Doernenburg?）
選擇合適的架構(gòu)視圖。不能太抽象，也不能細(xì)節(jié)太多，看清整個(gè)架構(gòu)。
29．?先嘗試后決策?（?Erik?Doernenburg?）
越晚做出決策，可利用的信息就越多。可先通過(guò)嘗試，對(duì)問(wèn)題的最佳解決方案有了共識(shí)，再組織協(xié)調(diào)制定決策。
30．?掌握業(yè)務(wù)領(lǐng)域知識(shí)?（?Mark?Richards?）
掌握業(yè)務(wù)領(lǐng)域知識(shí)有助于架構(gòu)師選擇合適的架構(gòu)模式，更好地制定針對(duì)未來(lái)的擴(kuò)展計(jì)劃，適應(yīng)不斷變化的產(chǎn)業(yè)趨勢(shì)。
31．?程序設(shè)計(jì)是一種設(shè)計(jì)?（?Einar?Landre?）
軟件開(kāi)發(fā)也分成設(shè)計(jì)和生產(chǎn)兩個(gè)階段。程序設(shè)計(jì)屬于設(shè)計(jì)范疇，而不是生產(chǎn)范疇，軟件的生產(chǎn)則是自動(dòng)化的，由編譯器、構(gòu)建工具和測(cè)試代碼共同完成。
32．?讓開(kāi)發(fā)人員自己做主?（?Philip?Nelson?）
架構(gòu)師的工作重點(diǎn)是仔細(xì)觀察整個(gè)系統(tǒng)是怎樣組合在一起的，確保系統(tǒng)良好地協(xié)調(diào)運(yùn)作，應(yīng)該給予團(tuán)隊(duì)成員足夠的自主權(quán)，讓他們發(fā)揮自己的創(chuàng)意和能力。
33．?時(shí)間改變一切?（?Philip?Nelson?）
選擇值得投入精力的工作，漂亮的解決方案搭配正確的任務(wù)，才能經(jīng)受時(shí)間的考驗(yàn)。別跟以前的工作過(guò)不去。回顧過(guò)去的工作，永遠(yuǎn)會(huì)覺(jué)得以前的設(shè)計(jì)和自己的期望有差距，把這些問(wèn)題當(dāng)作今后的工作標(biāo)準(zhǔn)，克制自己回過(guò)頭去修改的沖動(dòng)。
34．?設(shè)立軟件架構(gòu)專業(yè)為時(shí)尚早?（?Barry?Hawkins?）
這個(gè)自己分析吧！
35．?控制項(xiàng)目規(guī)模?（?Dave?Quick?）
分而治之，將大項(xiàng)目分解成獨(dú)立的小項(xiàng)目，設(shè)置優(yōu)先級(jí)，盡快交付，實(shí)現(xiàn)最重要的需求，盡快獲得客戶的反饋，越快越好。
36．?架構(gòu)師不是演員，是管家?（?Barry?Hawkins?）
架構(gòu)師的職責(zé)和管家相似，承擔(dān)著管理他人資產(chǎn)的責(zé)任，架構(gòu)師應(yīng)該盡可能為客戶利益著想，計(jì)算可用的時(shí)間和人力，綜合考慮成本和復(fù)雜性等因素，設(shè)計(jì)出折中的解決方案，不能存有私心，賣弄時(shí)髦的軟件框架和流行的技術(shù)詞匯，只會(huì)把系統(tǒng)變得更復(fù)雜，給公司造成損失。
37．?軟件架構(gòu)的道德責(zé)任?（?Michael?Nygard?）
架構(gòu)師的決定會(huì)影響許多人，務(wù)必慎重。雖然設(shè)計(jì)必填項(xiàng)從表面上看并無(wú)不妥之處，但實(shí)際上是架構(gòu)師在強(qiáng)迫用戶接受自己的意圖。必填項(xiàng)迫使用戶準(zhǔn)備更多的信息，這個(gè)過(guò)程常常會(huì)耽擱工作，讓人非常沮喪。
38．?摩天大廈不可伸縮?（?Michael?Nygard?）
但軟件可以。無(wú)論是開(kāi)發(fā)新項(xiàng)目還是替換已有的系統(tǒng)，都應(yīng)該逐個(gè)部署系統(tǒng)組件，一來(lái)可以將風(fēng)險(xiǎn)分散到各個(gè)時(shí)間段，每次砌好“一塊磚”，二來(lái)迫使我們?cè)O(shè)計(jì)清晰的組件間接口。
39．?混合開(kāi)發(fā)的時(shí)代已經(jīng)來(lái)臨?（?Edward?Garson?）
混合編程是指在同一套軟件系統(tǒng)中同時(shí)采用多種核心編程語(yǔ)言。新的技術(shù)變革正逐步瓦解我們以往積累的技術(shù)成果，架構(gòu)師應(yīng)擁抱這種變化，跳出原有的思維模式，充分挖掘軟件的多元化特性。
40．?性能至上?（Craig?Russell?）
性能，減少軟件響應(yīng)時(shí)間，提高人機(jī)交互效率！
41．?留意架構(gòu)圖里的空白區(qū)域?（?Michael?Nygard?）
空白區(qū)域“充滿”了各種軟件和“硬件”。隱藏著一系列復(fù)雜的事件，應(yīng)該考慮各種隱藏的細(xì)節(jié)，才能順利地解決空白區(qū)域里的問(wèn)題。
42．?學(xué)習(xí)軟件專業(yè)的行話?（?Mark?Richards?）
架構(gòu)師必須掌握基本的架構(gòu)模式和設(shè)計(jì)模師，學(xué)會(huì)識(shí)別不同的模式，并借助它們和同行及開(kāi)發(fā)人員進(jìn)行交流。模式可分類四大類：
企業(yè)架構(gòu)模式定義架構(gòu)的全局框架結(jié)構(gòu)。
應(yīng)用架構(gòu)模式指出了全局架構(gòu)下的子系統(tǒng)及局部應(yīng)用的設(shè)計(jì)方法。
集成模式研究怎樣在系統(tǒng)的組件、應(yīng)用和子系統(tǒng)之間傳遞信息，共享功能。
設(shè)計(jì)模式研究架構(gòu)中每個(gè)組件的構(gòu)造方法。
43．?具體情境決定一切?（?Edward?Garson?）
架構(gòu)不存在設(shè)計(jì)理念，具體情境決定一切，根據(jù)具體情境設(shè)計(jì)盡量簡(jiǎn)單的解決方案。
44．?侏儒、精靈、巫師和國(guó)王?（?Evan?Cofsky?）
開(kāi)發(fā)團(tuán)隊(duì)不應(yīng)該同質(zhì)化。軟件架構(gòu)師好比國(guó)王，應(yīng)該熟悉各種人的性格特點(diǎn)，招聘不同性格的人加入自己的團(tuán)隊(duì)，為不同性格的團(tuán)隊(duì)成員安排合適的任務(wù)，輕構(gòu)化解各種難。由一幫性格相同的人設(shè)計(jì)的架構(gòu)只能吸引同樣性格的人加入團(tuán)隊(duì)，只能解決一類問(wèn)題。
45．?向建筑師學(xué)習(xí)?（?Keith?Braithwaite?）
借鑒建筑行業(yè)的經(jīng)驗(yàn)。架構(gòu)師應(yīng)該蘊(yùn)含適當(dāng)?shù)乃囆g(shù)成分。
46．?避免重復(fù)?（?Niclas?Nilsson?）
兩條公認(rèn)的軟件開(kāi)發(fā)的真理：
（1）?復(fù)制是魔鬼。
（2）?重復(fù)性的工作拖累開(kāi)發(fā)進(jìn)度。
消滅重復(fù)的內(nèi)容是架構(gòu)師的責(zé)任，為此應(yīng)該重新研究框架，創(chuàng)造更完善的抽象機(jī)制，或者使用代碼生成器。
47．?歡迎來(lái)到現(xiàn)實(shí)世界?（?Gregor?Hohpe?）
現(xiàn)實(shí)世界比軟件世界復(fù)雜。不要抱怨現(xiàn)實(shí)世界中用戶需求帶來(lái)的麻煩，不妨從中尋找解決問(wèn)題的靈感。
48．?仔細(xì)觀察，別試圖控制一切?（?Gregor?Hohpe?）
選擇合適的抽象層次能提供有效的信息，也方便用基本的驗(yàn)證規(guī)則檢查模型，架構(gòu)師應(yīng)仔細(xì)觀察，提取模型，然后檢查驗(yàn)證，別妄想掌控一切。
49．?架構(gòu)師好比兩面神?（?David?Bartlett?）
架構(gòu)師應(yīng)該像兩面神一樣，眼觀六路、耳聽(tīng)八方。
50．?架構(gòu)師應(yīng)關(guān)注邊界和接口??（?Einar?Landre?）
尋找自然的邊界，分而治之。架構(gòu)師應(yīng)關(guān)注和繪制“有界情境”和“情境地圖”，有界情境是用以唯一定義一個(gè)模型或概念的區(qū)域，通常以一朵云或一個(gè)氣泡來(lái)表示。情境地圖則包含了一系列有界情境及它們之間的接口。
51．?助力開(kāi)發(fā)團(tuán)隊(duì)?（?Timothy?High?）
優(yōu)秀團(tuán)隊(duì)是成功的保障，要盡量助力開(kāi)發(fā)團(tuán)隊(duì)。
52．?記錄決策理由?（?Timothy?High?）
記錄架構(gòu)決策背后的理由，長(zhǎng)期有用，又無(wú)須為之付出過(guò)多精力維護(hù)，具有極高的投資回報(bào)價(jià)值。
53．?挑戰(zhàn)假設(shè)，?尤其是你自己的?（?Timothy?High???）
臆斷是事情搞砸的主要根源。一定要拿出相關(guān)的經(jīng)驗(yàn)證據(jù)，仔細(xì)驗(yàn)證假設(shè)，才能做出最終決策，務(wù)必要確保軟件基石堅(jiān)實(shí)可靠。
54．?分享知識(shí)和經(jīng)驗(yàn)?（?Paul?W.?Homer?）
討論有助于發(fā)現(xiàn)不足，只有能非常容易地做出解釋，才表明你真正理解了。只有不斷解釋和討論，才能把經(jīng)驗(yàn)?zāi)鄢芍R(shí)。幫助周圍的人不斷改善，他們也會(huì)幫助我們發(fā)揮出全部的潛力。
55．?模式病?（?Chad?La?Vigne?）
不要讓一展設(shè)計(jì)模式功力的欲望，遮蔽了務(wù)實(shí)的真知。使用模式解決適用的問(wèn)題才是最重要的。
56．?不要濫用架構(gòu)隱喻?（?David?Ing?）
不要耽溺于系統(tǒng)隱喻之中，只將之用于探索性的溝通，不要反讓它拖了后腿。
57．?關(guān)注應(yīng)用程序的支持和維護(hù)?（?Mncedisi?Kasper?）
應(yīng)用程序的支持和維護(hù)，永遠(yuǎn)都不應(yīng)該是事后才考慮的事情。由于應(yīng)用程序超過(guò) 80% 的生命周期都是在維護(hù)上，在設(shè)計(jì)時(shí)就應(yīng)該多多關(guān)注支持和維護(hù)的問(wèn)題。考慮生產(chǎn)環(huán)境修誤錯(cuò)誤的壓力，生產(chǎn)環(huán)境中的日志記錄級(jí)別要比開(kāi)發(fā)環(huán)境中的低很多，考慮開(kāi)發(fā)人員與支持人員具有不同的技能等。
58．?有舍才有得
珍惜需要權(quán)衡的時(shí)機(jī)，遠(yuǎn)勝毫無(wú)約束和限制。
59．?原則、公理和類比勝于個(gè)人意見(jiàn)和口味?（?Michael?Harmer?）
清楚的架構(gòu)原則，能夠使那些不熟悉某項(xiàng)特別技術(shù)或組件的人，明白其中的緣由，更透徹地理解他們本不熟悉的技術(shù)。
60．?從“?可行走骨架”?開(kāi)始開(kāi)發(fā)應(yīng)用?（?Clint?Shank?）
“可行走骨架”是對(duì)系統(tǒng)的最簡(jiǎn)單實(shí)現(xiàn)，它貫穿頭尾，將所有主要的架構(gòu)組件連接起來(lái)。從“?可行走骨架”?開(kāi)始，增量培育系統(tǒng)成長(zhǎng)?。
61．?數(shù)據(jù)是核心（?Paul?W.?Homer?）
從“數(shù)據(jù)是核心”這個(gè)角度去認(rèn)識(shí)系統(tǒng)，能大大降低理解復(fù)雜度?。
62．?確保簡(jiǎn)單問(wèn)題有簡(jiǎn)單的解?（Chad?La?Vigne?）
試圖猜測(cè)未來(lái)的需求時(shí)，錯(cuò)的概率是 50%，錯(cuò)得很離譜的概率是 49%。今天只需要解決今天的問(wèn)題就好。把應(yīng)用發(fā)布出去，從反饋中生成真實(shí)的需求。
63．?架構(gòu)師首先是開(kāi)發(fā)人員?（Mike?Brown?）
碰到麻煩時(shí)，架構(gòu)師可不能只會(huì)干吹煙圈卻束手無(wú)策。獲得開(kāi)發(fā)人員信任的最快捷方式：你的代碼就是你的資本。作為架構(gòu)師，主要目標(biāo)應(yīng)該是創(chuàng)建可行、可維護(hù)的解決方案，當(dāng)然，也一定要能夠解決當(dāng)前的問(wèn)題。
64．?根據(jù)投資回報(bào)率（ROI?）進(jìn)行決策（?George?Malamidis?）
在判斷每個(gè)決策選項(xiàng)是否務(wù)實(shí)或恰當(dāng)時(shí)，將架構(gòu)決策視為投資，并將相關(guān)的回報(bào)率也一并考慮在內(nèi)。
65．?一切軟件系統(tǒng)都是遺留系統(tǒng)（?Dave?Anderson?）
軟件很快便會(huì)過(guò)時(shí)，修改維護(hù)無(wú)可避免。需考慮以下幾點(diǎn)：
（1）?清晰性：各個(gè)組件和類的角色清晰。
（2）?可測(cè)性：系統(tǒng)易于驗(yàn)證。
（3）?正確性：結(jié)果和設(shè)計(jì)或期望的一致。
（4）?可跟蹤：能迅速診斷出故障并立馬解決問(wèn)題。
66．?起碼要有兩個(gè)可選解決方案（?Timothy?High?）
軟件架構(gòu)是要在所有給定的約束條件下，尋找到解決問(wèn)題的最佳方案。期望第一個(gè)解決方案即滿足全部的需求和約束，幾乎是不可能的。如果對(duì)手頭的問(wèn)題只有一個(gè)解決方案，這意味著將沒(méi)有進(jìn)行折衷權(quán)衡的余地。這個(gè)唯一的解決方案可能無(wú)法令系統(tǒng)投資方滿意。
67．?理解變化的影響?（?Doug?Crawford?）
清楚認(rèn)識(shí)變化類型及其影響。變化有多種不同的表現(xiàn)形式：
（1）?功能需求的變化
（2）?可擴(kuò)展性需求的演進(jìn)
（3）?系統(tǒng)的接口被修改
（4）?團(tuán)隊(duì)人員流動(dòng)等。
管理變化并非架構(gòu)師的職責(zé)，但架構(gòu)師要確保變化是可控的，有許多工具和技術(shù)可以用以減輕變化的影響。
（1）?進(jìn)行小規(guī)模的增量漸變。
（2）?構(gòu)建可重復(fù)運(yùn)行的測(cè)試用例，并經(jīng)常運(yùn)行。
（3）?讓測(cè)試用例更易編寫。
（4）?跟蹤好依賴關(guān)系。
（5）?系統(tǒng)性的行動(dòng)，根據(jù)反饋信息作出進(jìn)一步反應(yīng)。
（6）?自動(dòng)化重復(fù)的任務(wù)。
68．?你不能不了解硬件（?Kamal?Wickramanayake?）
硬件容量規(guī)劃，是和軟件架構(gòu)同等重要的事情。水平伸縮能力是關(guān)鍵，可以在需要時(shí)才添加硬件，而無(wú)須一開(kāi)始就過(guò)量采購(gòu)。
69．?現(xiàn)在走捷徑，將來(lái)需付息（?Scot?Mcphee?）
及時(shí)還清技術(shù)債務(wù)。可能覺(jué)得單元測(cè)試并不直接產(chǎn)生價(jià)值，于是就讓開(kāi)發(fā)人員跳過(guò)這些嚴(yán)格的測(cè)試工作，這將導(dǎo)致所交付的系統(tǒng)在未來(lái)更難修改，而且在修改時(shí)信心不足。?除了避免在開(kāi)發(fā)初期走捷徑，發(fā)現(xiàn)有不當(dāng)?shù)脑O(shè)計(jì)決策時(shí)就要盡快修正，擱置越久，為之付出的利息也將越高。
70．?不要追求“完美”，“足夠好”就行（?Greg?Nyberg?）
避免過(guò)度設(shè)計(jì)。不要屈服于企圖使設(shè)計(jì)或?qū)崿F(xiàn)達(dá)到完美的誘惑。把目的設(shè)定在“足夠好”就行，當(dāng)已經(jīng)達(dá)成目標(biāo)時(shí)，就停下來(lái)。
71．?小心“好主意”?（?Greg?Nyberg?）
“駱駝的鼻子”是?一個(gè)隱喻，指一旦允許一些不期望但很小的情況發(fā)生，后面就會(huì)招致巨大而無(wú)法避免的情況發(fā)生。“好主意”就如“駱駝的鼻子”，它將導(dǎo)致范圍膨脹，復(fù)雜度上升，竭力把和業(yè)務(wù)需求無(wú)關(guān)的東西塞入應(yīng)用中，這純粹是浪費(fèi)精力。
72．?內(nèi)容為王?（?Zubin?Wadia?）
內(nèi)容即網(wǎng)絡(luò)，即界面。在聯(lián)系日益緊密的今日世界，內(nèi)容質(zhì)量很快成為了成敗的關(guān)鍵。優(yōu)秀的內(nèi)容指的是其內(nèi)容之間互相關(guān)聯(lián)，而不是空洞割裂。系統(tǒng)的成功取決于其內(nèi)容，在設(shè)計(jì)過(guò)程中，要對(duì)內(nèi)容價(jià)值的評(píng)估給予足夠重視。
73．?對(duì)商業(yè)方，架構(gòu)師要避免憤世嫉俗（?Chad?La?Vigne?）
過(guò)度自信，會(huì)讓你在業(yè)務(wù)領(lǐng)域頭破血流。不要讓自己成為憤世嫉俗的“天才”，總是以一副自作聰明，居高臨下的語(yǔ)調(diào)，力求證明公司當(dāng)前的運(yùn)營(yíng)是多么的糟糕不堪，以期觸動(dòng)業(yè)務(wù)方。成為優(yōu)秀架構(gòu)師的秘訣之中有一個(gè)關(guān)鍵要素，那就是要對(duì)工作滿懷激情，但不要是那種帶著憤怒和火氣的“激情”。
74．?拉伸關(guān)鍵維度，發(fā)現(xiàn)設(shè)計(jì)中的不足（?Stephen?Jones?）
單獨(dú)拉伸每個(gè)維度，然后綜合起來(lái)看待，便可暴露出那些隱藏于最初設(shè)計(jì)中的潛在限制與不足。架構(gòu)師可以通過(guò)拉伸關(guān)鍵維度，對(duì)解決方案進(jìn)行校核：
（1）?了解基礎(chǔ)設(shè)施的規(guī)劃是否能夠應(yīng)付增長(zhǎng)的需求，圈出限制范圍。
（2）?確認(rèn)在預(yù)期的吞吐量下，系統(tǒng)不但能在當(dāng)天內(nèi)及時(shí)完成全天的任務(wù)處理，同時(shí)具備峰值儲(chǔ)備，才能應(yīng)
對(duì)“特別忙碌的日子”，才能在停電后“加班補(bǔ)上”.
（3）?對(duì)當(dāng)前的數(shù)據(jù)訪問(wèn)方案進(jìn)行校核，確保其在系統(tǒng)伸縮擴(kuò)展時(shí)依然有效。
（4）?確保在系統(tǒng)工作負(fù)載上升時(shí)，（如果需要）能夠以增加硬件和轉(zhuǎn)換處理路徑的方式進(jìn)行系統(tǒng)的伸縮擴(kuò)展。
（5）?數(shù)據(jù)量持續(xù)上升，導(dǎo)致數(shù)據(jù)必須在更多的基礎(chǔ)設(shè)施間進(jìn)行分割時(shí)，要確保應(yīng)用程序仍然可用。
75．?架構(gòu)師要以自己的編程能力為依托（?Mike?Brown?）
為項(xiàng)目設(shè)計(jì)架構(gòu)時(shí)，對(duì)實(shí)現(xiàn)每個(gè)設(shè)計(jì)元素所需的工作量，要做到心中有數(shù);如果以前曾開(kāi)發(fā)過(guò)其中某種設(shè)計(jì)元素，那么估算所需工作量將會(huì)容易得多。
76．?命名要恰如其分（?Sam?Gardiner?）
弄清楚要做的究竟是什么。設(shè)計(jì)就是要去實(shí)現(xiàn)各種意圖，例如，快速、廉價(jià)、靈活、而名字便是用來(lái)承載和傳達(dá)這些意圖的。
77．?穩(wěn)定的問(wèn)題可以獲得高質(zhì)量的解決方案（?Sam?Gardiner?）
架構(gòu)師必須從整體上看待雜亂無(wú)章的數(shù)據(jù)、概念、數(shù)據(jù)和處理邏輯，架構(gòu)師要能夠?qū)⑺鼈冏鳛檎w看待，并將它們分解為更小的片段或塊。這些問(wèn)題塊必須是穩(wěn)定的，只要問(wèn)題是穩(wěn)定的，就可以創(chuàng)建出一個(gè)擁有穩(wěn)定設(shè)計(jì)的系統(tǒng)。穩(wěn)定的設(shè)計(jì)可以讓你集中精力，打造出高質(zhì)量的應(yīng)用程序。
78．?天道酬勤（?Brian?Hart?）
勤奮體現(xiàn)在很多方面，但歸根結(jié)底是指具備堅(jiān)強(qiáng)的毅力，并且對(duì)系統(tǒng)的每項(xiàng)任務(wù)和每個(gè)架構(gòu)目標(biāo)，都能投入足夠的精力。真正做好那些看似簡(jiǎn)單的任務(wù)，堅(jiān)守承諾。很多時(shí)候，不是能力不足導(dǎo)致項(xiàng)目的失敗，而是由于勤奮不夠，緊迫感不強(qiáng)。
79．?對(duì)決策負(fù)責(zé)（?Yi?Zhou?）
有效的架構(gòu)決策包含：
（1）?無(wú)論是以敏捷的形式還是傳統(tǒng)的形式做出架構(gòu)決策，都必須對(duì)決策過(guò)程有充分的認(rèn)識(shí)。
（2）?要定期對(duì)架構(gòu)決策進(jìn)行復(fù)審;對(duì)照檢查決策的實(shí)際效果和預(yù)期效果;
（3）?要貫徹架構(gòu)決策，只有全程跟進(jìn)實(shí)施過(guò)程，才能夠確保最到位地實(shí)現(xiàn)其設(shè)計(jì)意圖。
（4）?并沒(méi)有所謂的全能技術(shù)天才，可以將一些決策委托給相應(yīng)問(wèn)題域的專家。
80．?棄聰明，求質(zhì)樸（?Eben?Hewitt?）
別去理會(huì)什么流行風(fēng)潮，只有真正睿智的架構(gòu)師才懂得如何保持質(zhì)樸。在質(zhì)樸的方案中，每個(gè)組件只做一件事。
81．?精心選擇有效技術(shù)，絕不輕易拋棄（?Chad?La?Vigne?）
架構(gòu)師工作很大的一部分，是要選擇用以攻克難題的合適技術(shù)。精心選擇熟悉的武器，不到萬(wàn)不得已絕不輕易拋棄它們。同時(shí)，以審慎的態(tài)度更新你的技術(shù)武器庫(kù)。
82．?客戶的客戶才是你的客戶！（ Eben Hewitt ）
假設(shè)你正在編寫一個(gè)電子商務(wù)應(yīng)用程序，那么該仔細(xì)考慮的應(yīng)當(dāng)是那些會(huì)在那個(gè)網(wǎng)站上購(gòu)物的人的需求。
83．?事物發(fā)展總會(huì)出人意料?（?Peter?Gillard-Moss?）
設(shè)計(jì)是在不斷變化的世界中持續(xù)進(jìn)行探索試驗(yàn)的過(guò)程。無(wú)論研究得多么深入透徹，無(wú)論設(shè)計(jì)是如何深思熟慮，事情最后總會(huì)變得和你想的不一樣，我們會(huì)發(fā)現(xiàn)通常無(wú)法預(yù)知的新信息。
84．?選擇彼此間能和諧共處的框架?（?Eric?Hawthorne?）
當(dāng)心“無(wú)所不能”型的框架。系統(tǒng)應(yīng)該由多個(gè)相互獨(dú)立的框架組成，其中每個(gè)框架都精專于各自的領(lǐng)域，但同時(shí)又非常簡(jiǎn)潔、包容和靈活。
85．?著重強(qiáng)調(diào)項(xiàng)目的商業(yè)價(jià)值（?Yi?Zhou?）
可通過(guò)下面五步，成功將架構(gòu)提案打造為典型的商業(yè)項(xiàng)目：
（1）?形成價(jià)值陳述，用以說(shuō)明組織的業(yè)務(wù)為何要采用某種特定的軟件架構(gòu)，重點(diǎn)應(yīng)放在說(shuō)明其在提高生產(chǎn)力、改進(jìn)業(yè)務(wù)效率方面的能力。
（2）?建立量化的度量標(biāo)準(zhǔn)，量化得越具體越到位，項(xiàng)目也將越具有說(shuō)服力。
（3）?回過(guò)頭來(lái)關(guān)聯(lián)傳統(tǒng)商業(yè)的衡量方式，如果能將技術(shù)分析轉(zhuǎn)化為財(cái)務(wù)數(shù)據(jù)，則會(huì)更為完美。
（4）?知道該在哪里停止。準(zhǔn)備好一張路線圖，用以捕獲遠(yuǎn)景目標(biāo)，清楚地知道每一個(gè)里程碑將帶來(lái)的商業(yè)價(jià)值。讓利益相關(guān)者自己決定在何處停止。
（5）?尋找恰當(dāng)?shù)臅r(shí)機(jī)，如果時(shí)機(jī)不對(duì)，可能仍然無(wú)法成功推銷你的點(diǎn)子。
86．?不僅僅只控制代碼，也要控制數(shù)據(jù)?（?Chad?La?Vigne?）
數(shù)據(jù)庫(kù)的變化不應(yīng)該影響構(gòu)建活動(dòng)的連續(xù)性。要把數(shù)據(jù)庫(kù)也作為一個(gè)構(gòu)建單元包含在內(nèi)，做到一次性構(gòu)建整個(gè)應(yīng)用程序。
87．?償還技術(shù)債務(wù)?（?Burkhardt?Hufnagel?）
在速度和架構(gòu)間進(jìn)行權(quán)衡，保持平衡。“臟但快速”的路線也許適合將修改快速納入產(chǎn)品中，但由于“臟但快速”的修復(fù)有隱性成本，記得安排開(kāi)發(fā)人員回頭去妥善修復(fù)解決，納入下一個(gè)計(jì)劃發(fā)布的版本中。
88．?不要急于求解（?Eben?Hewitt?）
不要立即著手去解決擺在面前的問(wèn)題，而要看看自己是否可以改變問(wèn)題。
89．?打造上手的系統(tǒng)（?Keith?Braithwaite?）
我們構(gòu)建的系統(tǒng)，用戶體驗(yàn)應(yīng)該是“上手的”，一定要能夠幫助人們做事，這是成功的決定性因素。
90．?找到并留住富有激情的問(wèn)題解決者?（?Chad?La?Vigne?）
以正確的方式有效地經(jīng)營(yíng)開(kāi)發(fā)團(tuán)隊(duì)。應(yīng)確保團(tuán)隊(duì)具有打不垮的首發(fā)陣容，而一旦已經(jīng)擁有“常勝鐵軍”，就要竭力維持。
91．?軟件并非真實(shí)的存在?（?Chad?La?Vigne?）
需求文檔不是藍(lán)圖，軟件并非真實(shí)的存在，虛擬世界中的軟件是柔韌可變的。
92．?學(xué)習(xí)新語(yǔ)言?（?Burkhardt?Hufnagel?）
防止溝通不暢和誤解?。架構(gòu)師要能夠以業(yè)務(wù)人員可理解的術(shù)語(yǔ)向業(yè)務(wù)人員解釋其中的問(wèn)題，以程序員可理解的術(shù)語(yǔ)向程序員轉(zhuǎn)述業(yè)務(wù)上的問(wèn)題。
93．?沒(méi)有永不過(guò)時(shí)的解決方案（?Richard?Monson-Haefel?）
今天做出的選擇，在未來(lái)很大程度上會(huì)是錯(cuò)誤的，只要選擇能滿足當(dāng)前需求的最佳解決方案就行了。
94．?用戶接受度問(wèn)題（?Norman?Carnovale?）
減輕用戶接受度問(wèn)題帶來(lái)的風(fēng)險(xiǎn)。人們并不總是滿心歡喜地接受新系統(tǒng)或系統(tǒng)的重大升級(jí)，架構(gòu)師的目標(biāo)，是要去了解和衡量接受度問(wèn)題帶來(lái)的威脅，并朝能減輕這些威脅的方向開(kāi)展工作。最有效的解決辦法，是運(yùn)用系統(tǒng)設(shè)計(jì)本身來(lái)消解個(gè)中憂慮，包括培訓(xùn)、定期安排系統(tǒng)的演示，并分享用戶從新系統(tǒng)中將會(huì)獲得的知識(shí)。
95．?清湯的重要啟示?（?Eben?Hewitt?）
軟件架構(gòu)設(shè)計(jì)需要不斷的精煉濃縮。反思各種構(gòu)想，直至可以確定系統(tǒng)中每個(gè)需求的本質(zhì)。
96．?對(duì)最終用戶而言，界面就是系統(tǒng)?（?Vinayak?Hegde?）
最終用戶通過(guò)用戶界面訪問(wèn)系統(tǒng)，用戶交互應(yīng)和產(chǎn)品健壯性和性能同等重要，好的用戶界面能夠幫助客戶提高生產(chǎn)力，能夠幫助人們更加高效，也有利于產(chǎn)品自身的業(yè)務(wù)收益。
97．?優(yōu)秀軟件不是構(gòu)建出來(lái)的，而是培育起來(lái)的（?Bill?de?hóra?）
要抵制試圖設(shè)計(jì)出龐大完整的系統(tǒng)來(lái)“滿足甚或超出”已知需求的特性期望的想法，要有宏偉的遠(yuǎn)景，
但不要有龐大的設(shè)計(jì)。設(shè)計(jì)盡可能小的系統(tǒng)，幫助成功交付，并推動(dòng)它向宏偉遠(yuǎn)景目標(biāo)不斷演化。
98. ???客戶需求重于個(gè)人簡(jiǎn)歷
客戶需求至上。為了自己的簡(jiǎn)歷更炫而采用新技術(shù)是沽名釣譽(yù)，往往事與愿違。
99. ???多用書(shū)面方式總結(jié)架構(gòu)師的思維模式，多講述和分享，提高溝通能力和影響力
架構(gòu)師的溝通能力和影響力很重要，要利用大會(huì)和互聯(lián)網(wǎng)，把自己的思維模式和架構(gòu)體系整理出來(lái)，提煉，并多講述。這樣可以不斷提高自己的總結(jié)能力，溝通能力和影響力，提高日常跟團(tuán)隊(duì)的協(xié)作能力。
? ? ? ?本文轉(zhuǎn)自itwriter的“架構(gòu)師大會(huì)：頂級(jí)架構(gòu)師應(yīng)該知道的99件事”，稍有改動(dòng)。本文是針對(duì)中國(guó)架構(gòu)師大會(huì)宣傳而寫，但是文章不乏很多架構(gòu)師箴言和經(jīng)驗(yàn)，值得大家學(xué)習(xí)和研究。
申明：感謝原創(chuàng)作者的辛勤付出。本號(hào)轉(zhuǎn)載的文章均會(huì)在文中注明，若遇到版權(quán)問(wèn)題請(qǐng)聯(lián)系我們處理！
Elasticsearch在線分享直播
﹀
﹀
﹀
劉征，Elastic 中國(guó)技術(shù)布道師
《DevOps Handbook》《The Site Reliability Workbook》譯者；精通DevOps/SRE/ITSM等理論體系和相關(guān)實(shí)踐等落地實(shí)現(xiàn)。致力于通過(guò)社區(qū)推廣開(kāi)源Elastic Stack技術(shù)堆棧的應(yīng)用，包括運(yùn)維大數(shù)據(jù)分析平臺(tái)、云原生服務(wù)治理、APM全鏈路監(jiān)控和AIOps等使用場(chǎng)景。
使用 Elastic Stack 監(jiān)測(cè) COVID-19 疫情爆發(fā)網(wǎng)絡(luò)研討會(huì)2020年4月8日15:00 線上分享
用實(shí)際應(yīng)用場(chǎng)景探索 Kibana 的多種用法 ，構(gòu)建自己的個(gè)性化儀表板，從公共數(shù)據(jù)源跟蹤全球各地的COVID-19疫情狀況。在本演示中，您將了解如何輕松地在Elasticsearch中索引任何類型的數(shù)據(jù)索引，使用采集節(jié)點(diǎn)對(duì)其進(jìn)行數(shù)據(jù)轉(zhuǎn)換，然后使用Kibana 的可視化、儀表板和地圖對(duì)疫情現(xiàn)狀進(jìn)行分析。
亮點(diǎn)：
Elastic在CNCF云原生交互場(chǎng)景中的位置
在Kubernetes上運(yùn)行?Elastic?Stack
演示：如何使用 ECK 部署、防護(hù)和升級(jí) Elasticsearch
Beats?中使用?autodiscover?監(jiān)測(cè)動(dòng)態(tài)工作負(fù)載的入門知識(shí)
在Kubernetes上掌握可觀測(cè)經(jīng)驗(yàn)
報(bào)名方式：識(shí)別圖片二維碼或閱讀原文報(bào)名
想要加入中生代直播群的小伙伴，請(qǐng)?zhí)砑尤褐?strong>大白的微信
申請(qǐng)備注（姓名+公司+技術(shù)方向）
總結(jié)
以上是生活随笔為你收集整理的收藏!架构师需要掌握的99条铁律的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： hdu - 4027 Can you a
- 下一篇： hdu - 2512 一卡通大冒险 （斯