《轉(zhuǎn)架構(gòu)設(shè)計(jì)準(zhǔn)則》word版

1、.【轉(zhuǎn)】架構(gòu)設(shè)計(jì)準(zhǔn)則最近看了一本書軟件架構(gòu)師應(yīng)該知道的97件事，本來并沒對(duì)它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什么實(shí)際收獲，但看的過程中被里面中肯實(shí)在的建議給吸引，對(duì)于我這種在走向架構(gòu)師這條路上常常迷失方向的人，實(shí)在是雪中送炭。讀完后，決定選擇其中對(duì)我有觸動(dòng)的條目，加上實(shí)際工作中的感悟，形成一套自認(rèn)為正確的架構(gòu)師行為準(zhǔn)則，以此來矯正自己的行為?？蛻粜枨蟾哂谝磺胁灰獮榱俗约旱捻?xiàng)目經(jīng)歷上添加光彩而去一味追求時(shí)髦而光鮮的方案，而是應(yīng)該扎根客戶需求，腳踏實(shí)地地為客戶著想，這樣才能更體現(xiàn)技術(shù)的價(jià)值，不至于迷失方向。架構(gòu)師首先不要把自己當(dāng)做技術(shù)人員，而是業(yè)務(wù)人員，把實(shí)現(xiàn)業(yè)務(wù)需求作為至上的目

2、標(biāo)，學(xué)會(huì)拒絕成本高，性價(jià)比不高的技術(shù)。簡(jiǎn)化根本復(fù)雜性常常為了解決某一局部復(fù)雜性引入了更為復(fù)雜的框架或產(chǎn)品，使得復(fù)雜性不減反增。往往正確的方式是做減法而不是加法，把最根本的復(fù)雜源找到，把根鏟除。關(guān)鍵問題可能不是出在技術(shù)上總結(jié)失敗的項(xiàng)目常常會(huì)糾結(jié)于選擇了錯(cuò)誤的技術(shù)。其實(shí)技術(shù)并沒有錯(cuò)，而是在使用技術(shù)上或是在執(zhí)行過程中人為的偏差導(dǎo)致。而架構(gòu)師解決這種人為的問題比較好的方式是溝通，通過有效地溝通把技術(shù)貫徹下去以溝通為中心，堅(jiān)持簡(jiǎn)明清晰和開明的風(fēng)格架構(gòu)師不要坐在象牙塔里，命令開發(fā)人員實(shí)施你的設(shè)計(jì)和決策，而是應(yīng)該盡量簡(jiǎn)化你的設(shè)計(jì)，透徹地與他們溝通，并且關(guān)鍵在于開明地接受他們的建議并勇于推翻自己的決策架構(gòu)決定

3、性能最好提升性能的方法不是痛苦地做一次次對(duì)即將上線的產(chǎn)品做性能測(cè)試和提升，而是在架構(gòu)設(shè)計(jì)的時(shí)候就把性能作為重要因素，從架構(gòu)底層考慮分布式、緩存、系統(tǒng)交互劃分等影響性能的重點(diǎn)。提前關(guān)注性能，是解決性能問題代價(jià)最小的方式分析客戶要求背后的真實(shí)需求合同上或UC上只是客戶的要求，而并非100%是客戶真實(shí)的需求，架構(gòu)師的重要責(zé)任就是挖掘隱藏在要求背后的真實(shí)需求，這個(gè)不但可以最大化滿足客戶，也往往可以幫助我們避開技術(shù)壁壘，當(dāng)真正抓住客戶需求的時(shí)候，我們也許能用更為簡(jiǎn)單的替代方案滿足客戶溝通是架構(gòu)師達(dá)成目標(biāo)的核心技能常用的溝通技能和準(zhǔn)則有以下幾點(diǎn)：不要把溝通當(dāng)做對(duì)抗不要帶有情緒與人溝通表達(dá)自己方案之前傾聽他

4、人觀點(diǎn)站立發(fā)言是擴(kuò)大溝通影響力的一種好方式學(xué)習(xí)業(yè)務(wù)或技術(shù)領(lǐng)域中的行話，降低溝通成本不要為預(yù)防故障引入更多的故障架構(gòu)師常常會(huì)為識(shí)別出的可能故障點(diǎn)加入監(jiān)控措施，但往往會(huì)忽略做些監(jiān)控措施也是會(huì)有故障的，不要試圖讓你的系統(tǒng)天衣無縫，這往往是使系統(tǒng)更為復(fù)雜和脆弱的來源。先承認(rèn)是系統(tǒng)總會(huì)有缺陷的，只是把這些缺陷設(shè)定為容易察覺和維護(hù)的點(diǎn)量化非功能性需求往往功能性需求容易量化，因?yàn)檫@些是看得見和摸得著的，但像性能好、可擴(kuò)展性好、高可用性等這些非功能性需求卻不好量化，但作為架構(gòu)師要有意識(shí)地去定義和量化這些需求，只有這樣才能更好地和其他部門更好溝通，謀求更多資源，也便于系統(tǒng)更有效地驗(yàn)收一行代碼比500行架構(gòu)說明更

5、有說服力架構(gòu)師往往喜歡待在象牙塔里，堆砌大量架構(gòu)文檔，然后希望其他開發(fā)人員能乖乖地去實(shí)施。這樣做的效果往往是不好的，一方面很難有這樣的牛人能洞察所有的細(xì)節(jié)，在文檔里就預(yù)測(cè)性地解決了所有問題，另一方面也不利于架構(gòu)師與開發(fā)人員的溝通。比較好的做法是架構(gòu)師參與具體實(shí)施，在實(shí)施中驗(yàn)證和改進(jìn)架構(gòu)設(shè)計(jì)，與大家達(dá)成一片也便于加深彼此配合的默契程度。不存在放之四海皆準(zhǔn)的解決方案不存在最好的架構(gòu)，只有最合適的架構(gòu)。不會(huì)有一種架構(gòu)方案，在任何項(xiàng)目里都適用。雖然我們承認(rèn)模式的重要性，但在實(shí)際項(xiàng)目里要有選擇性吸收，根本上要本項(xiàng)目和實(shí)際困境出發(fā)，不要被既有的模式和經(jīng)驗(yàn)先入為主，因?yàn)闆]有一種已有方案能完全不修改地適用于你

6、。架構(gòu)設(shè)計(jì)要平衡兼顧多方需求架構(gòu)師從某種角度來講就是一劑膠水，把業(yè)務(wù)部門的需求、項(xiàng)目進(jìn)度的需求、測(cè)試的需求和開發(fā)工程師本身的需求有效地捏合在一起，平衡與兼顧以至達(dá)到皆大歡喜。其他職能的人都只是focus在某一局部，需要架構(gòu)師這樣的人來通盤考慮，因此他的工作是最雜的，絕不是簡(jiǎn)簡(jiǎn)單單地拿出一份架構(gòu)文檔就OK了，需要考慮系統(tǒng)安全、易用性、可測(cè)性、商業(yè)價(jià)值、長(zhǎng)期規(guī)劃、發(fā)布管理和部署方式，使得各個(gè)部門人的需求得到響應(yīng)本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：先確保解決方案簡(jiǎn)單可用，再考慮通用性和復(fù)用性系統(tǒng)的復(fù)雜性往往是架構(gòu)師基于通用性和復(fù)用性的設(shè)計(jì)而引入的，很多具體問題往往不需要通用性和復(fù)用性的解決方案。如

7、果存在多個(gè)可實(shí)施方案難以取舍，先簡(jiǎn)單后通用原則可以成為最終的評(píng)判標(biāo)準(zhǔn)。架構(gòu)師提供具體解決方案時(shí)，無需排斥通用和靈活，但是如果過早脫離具體情況，只會(huì)迷失在無限的可能性里，被復(fù)雜的配置選項(xiàng)、超負(fù)荷的參數(shù)列表、冗長(zhǎng)羅嗦的接口，以及存在缺陷的抽象所淹沒。先簡(jiǎn)單滿足需求，當(dāng)重復(fù)需求再次發(fā)生時(shí)，通過重構(gòu)來達(dá)到復(fù)用是一種不錯(cuò)的方式架構(gòu)師應(yīng)該親力親為架構(gòu)師干久了往往會(huì)脫離技術(shù)本身，迷茫在抽象之中，這是很危險(xiǎn)可怕的。架構(gòu)師要取得其他同事的信任，應(yīng)該比業(yè)務(wù)人員更懂業(yè)務(wù)，比開發(fā)人員更懂具體的編碼，比測(cè)試人員更懂如何有效地測(cè)試，就像航班的主駕駛員，雖然不需要親自操作，但經(jīng)驗(yàn)豐富，持續(xù)地監(jiān)視著情況，一旦發(fā)現(xiàn)異常隨時(shí)采取

8、行動(dòng)。架構(gòu)師應(yīng)該項(xiàng)目的交付和質(zhì)量負(fù)有最終的責(zé)任。架構(gòu)師應(yīng)該盡可能地參與項(xiàng)目，不能把技術(shù)決策和方向上的難題拆分出扔給別人，需要采取更務(wù)實(shí)的辦法，比如親自動(dòng)手研究或和其他成員討論。持續(xù)集成是架構(gòu)師的重要任務(wù)普通的開發(fā)人員會(huì)focus在各自負(fù)責(zé)的小模塊，只會(huì)對(duì)單個(gè)模塊負(fù)責(zé)，而架構(gòu)師需要對(duì)整個(gè)系統(tǒng)負(fù)責(zé)，持續(xù)集成是一種對(duì)整個(gè)系統(tǒng)進(jìn)行有效控制的好方法，架構(gòu)師有責(zé)任讓它運(yùn)行起來。避免進(jìn)度調(diào)整失誤雖然保障進(jìn)度是PM的職責(zé)，但變更要發(fā)生的時(shí)候，作為對(duì)技術(shù)最有發(fā)言權(quán)的架構(gòu)師應(yīng)該站出來，把變更的必要性和風(fēng)險(xiǎn)進(jìn)行仔細(xì)分析，最大限度地支持PM的決策。取舍的藝術(shù)我們做系統(tǒng)，特別是互聯(lián)網(wǎng)系統(tǒng)，絕不是做一個(gè)變形金剛，而是做一

9、個(gè)有缺陷但卻滿足了現(xiàn)階段商業(yè)需求的系統(tǒng)，因此架構(gòu)師需要有取舍的藝術(shù)，你的架構(gòu)是能用有限的資源滿足最迫切的需求，舍掉那些看是光鮮卻無太多用處的東西打造數(shù)據(jù)庫(kù)堡壘在上層的程序設(shè)計(jì)中，架構(gòu)師一般都會(huì)推崇先簡(jiǎn)單實(shí)現(xiàn)，然后在逐步重構(gòu)的敏捷方式，但對(duì)于較為穩(wěn)定的后端數(shù)據(jù)庫(kù)，我們需要采取更為謹(jǐn)慎的態(tài)度，因?yàn)閿?shù)據(jù)庫(kù)是整個(gè)系統(tǒng)的基石，無論是業(yè)務(wù)設(shè)計(jì)還是技術(shù)設(shè)計(jì)都得保持它的穩(wěn)定性，這是整個(gè)系統(tǒng)穩(wěn)定的基礎(chǔ)。我們往往會(huì)發(fā)現(xiàn)這么一個(gè)現(xiàn)象，當(dāng)程序第一版上線后，數(shù)據(jù)庫(kù)里表只會(huì)增加不會(huì)刪除，也不會(huì)刪除多余的字段，每次數(shù)據(jù)庫(kù)變更都會(huì)引起所有人的緊張，也會(huì)使得本已混亂的數(shù)據(jù)庫(kù)設(shè)計(jì)更為混亂。重視不確定性優(yōu)良的架構(gòu)能夠從整體上降低設(shè)

10、計(jì)決策的重要性，糟糕的架構(gòu)則會(huì)使得常常突出選擇的重要性。如果出現(xiàn)兩個(gè)合理地選擇，架構(gòu)師應(yīng)該停下來，設(shè)法找出介于兩者之間的、具有更低重要性的決策，了解兩者之外還存在其他選擇，比決策結(jié)果本身更有價(jià)值不要輕易放過不起眼的問題項(xiàng)目的失敗或線上故障往往是由于項(xiàng)目過程中的不起眼問題所引起，比如一些特殊的邊界情況，而這些問題絕不能指望開發(fā)主力們?nèi)グl(fā)現(xiàn)和解決，因?yàn)樗麄兊淖⒁饬Χ紩?huì)focus在主要矛盾上，作為時(shí)刻監(jiān)控項(xiàng)目的架構(gòu)師應(yīng)該擔(dān)當(dāng)起發(fā)現(xiàn)這些"小bug"的義務(wù)。讓大家學(xué)會(huì)復(fù)用架構(gòu)師有義務(wù)提高開發(fā)人員可復(fù)用地解決問題的意識(shí)，比如以上幾種措施：讓大家把自己能復(fù)用的代碼及時(shí)共享給他人加強(qiáng)復(fù)用代

11、碼的易用性，避免誤用讓大家認(rèn)識(shí)到已有資源好過自己動(dòng)手架構(gòu)文檔的抽象程度要適中架構(gòu)師寫架構(gòu)文檔常常很糾結(jié)，寫得太高層次的話就太空洞，無切實(shí)的指導(dǎo)意義；寫得太具體的話，比如指明到類的各種UML圖，就會(huì)很約束開發(fā)人員。文檔要寫到什么程度，關(guān)鍵在于滿足他人的需求，比如業(yè)務(wù)部門想從文檔中得知系統(tǒng)各功能的實(shí)施可行性，因此你的文檔要能體現(xiàn)各主要功能是如何滿足的。測(cè)試人員想知道系統(tǒng)內(nèi)部如何流轉(zhuǎn)和如何對(duì)系統(tǒng)進(jìn)行測(cè)試，因此你的文檔要體現(xiàn)系統(tǒng)主要模塊的運(yùn)行流程和系統(tǒng)可測(cè)試性。開發(fā)人員需要知道系統(tǒng)各自模塊的劃分和之間的交互規(guī)范，因此你的文檔要體現(xiàn)模塊化設(shè)計(jì)。PM需要知道這個(gè)項(xiàng)目有哪些風(fēng)險(xiǎn)點(diǎn)，因此你的文檔要體現(xiàn)風(fēng)險(xiǎn)點(diǎn)識(shí)

12、別和如何規(guī)避。DBA和運(yùn)維人員需要知道系統(tǒng)的數(shù)據(jù)量和性能情況，因此需要指明系統(tǒng)如何應(yīng)對(duì)大數(shù)據(jù)量的情況。關(guān)鍵一點(diǎn)，架構(gòu)師不是為了設(shè)計(jì)而設(shè)計(jì)，是要想清楚別人為什么要看你的文檔，怎樣滿足別人的需求先嘗試后決策設(shè)計(jì)中有很多需要決策的點(diǎn)，很多架構(gòu)師喜歡在象牙塔里憑借經(jīng)驗(yàn)做決策，感覺這就是架構(gòu)師需要干的。其實(shí)，這樣的做法往往會(huì)讓你很被動(dòng)，不如延遲決策，把需要決策的點(diǎn)拋出來，讓大家去嘗試，在實(shí)踐比較中，其實(shí)無須決策，正確的選擇自然就出來了，這樣也更能拉近你和大家的距離，提高大家的積極性和你的權(quán)威性掌握業(yè)務(wù)領(lǐng)域知識(shí)架構(gòu)師的角色任務(wù)在于理解業(yè)務(wù)問題、業(yè)務(wù)目標(biāo)、業(yè)務(wù)需求、并設(shè)計(jì)技術(shù)架構(gòu)來滿足它們。掌握業(yè)務(wù)領(lǐng)域知識(shí)

13、將有利于架構(gòu)師選擇合適的架構(gòu)模式，更好地制定針對(duì)未來的擴(kuò)展計(jì)劃。coding是屬于設(shè)計(jì)范疇很多人常常把軟件開發(fā)類比于傳統(tǒng)行業(yè)，把coding比作是生產(chǎn)過程，因此很多一線開發(fā)人員稱作自己為代碼工人，很多架構(gòu)師也是這么認(rèn)為，只是把開發(fā)人員當(dāng)作實(shí)現(xiàn)自己設(shè)計(jì)的生產(chǎn)工具而已。其實(shí)coding相對(duì)于傳統(tǒng)行業(yè)應(yīng)該屬于設(shè)計(jì)范疇，真正生產(chǎn)過程實(shí)際上是由工具來完成的編譯、構(gòu)建和發(fā)布過程。架構(gòu)師更應(yīng)該把coding當(dāng)作設(shè)計(jì)來看，從紙上的設(shè)計(jì)到coding后的代碼還有很多設(shè)計(jì)點(diǎn)可挖，同樣的輸出的背后也許來源于完全不同的coding，其軟件成品的價(jià)值也是完全不同的。本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：讓開發(fā)人員自己做

14、主架構(gòu)師雖然需要為系統(tǒng)的設(shè)計(jì)負(fù)責(zé)，但無須包攬所有的設(shè)計(jì)工作，應(yīng)該給予團(tuán)隊(duì)成員足夠的自主權(quán)，讓他們發(fā)揮自己的創(chuàng)意和能力，你的工作是確保大家的工作能很好的組合在一起，幫助他人解決棘手困難。當(dāng)你發(fā)現(xiàn)同事遇到麻煩時(shí)，可以主動(dòng)給出建議，但更可取的做法是創(chuàng)造良好的氛圍，讓大家主動(dòng)向你征求意見?？刂祈?xiàng)目規(guī)模架構(gòu)師要試圖避免做那種"超大型"系統(tǒng)，因?yàn)檫@種系統(tǒng)往往難以控制，控制項(xiàng)目規(guī)模的辦法通常有：抓住真正需求分而治之設(shè)置優(yōu)先級(jí)盡快交付原則架構(gòu)師不是演員，而是管家有些架構(gòu)師誤解了證明自己價(jià)值的含義，以為是炫耀技術(shù)才華，甚至是刁難開發(fā)團(tuán)隊(duì)，把自己放在高高在上的位子，試圖讓別人來崇拜你。其實(shí)架構(gòu)

15、師的職責(zé)和管家類似，承擔(dān)著管理技術(shù)資產(chǎn)的責(zé)任，要深入了解系統(tǒng)里各個(gè)細(xì)節(jié)，要精打細(xì)算，而不是浮在表面做無實(shí)文章。關(guān)注性能高性能往往和代碼優(yōu)美性常常沒法兼容，有些架構(gòu)師往往不在乎性能上的點(diǎn)滴損耗，為了代碼更重用或更優(yōu)美，不惜多查一次數(shù)據(jù)庫(kù)，多與外系統(tǒng)交互一次，這種做法會(huì)讓后期的性能提升很被動(dòng)，性能壓力會(huì)逼迫你打破原有的設(shè)計(jì)，為提升性能把代碼搞得支離破碎。架構(gòu)師需要珍惜任何一點(diǎn)的性能損耗。對(duì)復(fù)雜性要有前瞻意識(shí)在實(shí)際的運(yùn)行環(huán)境中，往往簡(jiǎn)單的系統(tǒng)都有可能變得非常復(fù)雜，簡(jiǎn)單的遠(yuǎn)程接口可能調(diào)不通、穩(wěn)固的數(shù)據(jù)庫(kù)可能down掉、消息順序可能會(huì)錯(cuò)亂、服務(wù)器可能會(huì)無緣無故地down機(jī)，不要假設(shè)這些情況不會(huì)發(fā)生，架構(gòu)

16、師應(yīng)該對(duì)復(fù)雜的情況有前瞻意識(shí)，要在假設(shè)類似于前面的狀態(tài)存在的情況下設(shè)計(jì)軟件。關(guān)注邊界和接口任何系統(tǒng)或模塊的邊界和接口都是與外交互的門面，有交互就暗藏著誤解和不恰當(dāng)?shù)膭澐?，保持接口的順暢交互是架?gòu)師的重要職責(zé)。往往bug發(fā)生在模塊與模塊之間、系統(tǒng)與系統(tǒng)之間，項(xiàng)目的失敗也往往因?yàn)橄到y(tǒng)間交互問題，因此架構(gòu)師需要給予足夠的關(guān)注助力開發(fā)人員架構(gòu)師的完美設(shè)計(jì)需要開發(fā)人員是實(shí)現(xiàn)，因此有業(yè)務(wù)想辦法提升開發(fā)團(tuán)隊(duì)的戰(zhàn)斗力，常有以下方式：尋找或開發(fā)工作需要的工具，并附上使用技巧做定期的分享或提高團(tuán)隊(duì)學(xué)習(xí)氣氛，保持團(tuán)隊(duì)技術(shù)上的先進(jìn)性參與開發(fā)團(tuán)隊(duì)的招聘工作給予開發(fā)人員更多的決策空間，幫助其成長(zhǎng)保護(hù)好開發(fā)人員，讓他們盡可

17、能地免于雜事之中直接參與開發(fā)，分擔(dān)壓力記錄決策的理由架構(gòu)師常常需要權(quán)衡和決策，但決策過后卻沒有把決策的過程和理由記錄下來，其實(shí)這是在浪費(fèi)很大的一筆財(cái)富。質(zhì)疑假設(shè)架構(gòu)師往往需要假設(shè)一種情境，然后在這種情境下給出方案和做出決策，很多人包括自己從來都是糾結(jié)于這個(gè)方案的優(yōu)劣，并不斷改進(jìn)，但卻忽視了這種假設(shè)的情境是否成立，而這個(gè)可能是萬惡之源。關(guān)注系統(tǒng)的支持和維護(hù)架構(gòu)師通常是由開發(fā)人員成長(zhǎng)而來，因此天然地把注意力放在功能開發(fā)上，常常忽視系統(tǒng)的支持和維護(hù)方面，給支持人員和維護(hù)人員造成不便。架構(gòu)師需要清晰知道一個(gè)系統(tǒng)生命周期80%在于維護(hù)上面，而系統(tǒng)的價(jià)值需要支持人員去不斷傳遞給客戶，他們的需求需要得到重視

18、。有以下幾點(diǎn)需要注意：清晰性可測(cè)性正確性可跟蹤性不要急于求解很多架構(gòu)師都有解決難題的欲望，一遇到問題，就立馬陷入解決問題的泥潭中。而更可取的是審視問題本身，看是否可以改變問題，或是干脆繞開問題，很多時(shí)候技術(shù)上的難題在通過業(yè)務(wù)上的優(yōu)化是可以避免的。我們不要立足點(diǎn)設(shè)為解決特定問題，而是應(yīng)該立足于客戶需求優(yōu)秀軟件是培育出來的很多架構(gòu)師需要在軟件的第一版本就一鳴驚人，拿出完美的作品，其實(shí)真正受歡迎的系統(tǒng)是在不斷發(fā)布中演化而來，對(duì)于互聯(lián)網(wǎng)軟件更是如此。架構(gòu)師需要做的是打好系統(tǒng)的基礎(chǔ)，使其容易修改和擴(kuò)展，傾聽用戶的反饋，不斷地在無數(shù)次改進(jìn)中培育我們的軟件本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：原則大于個(gè)人口

19、味很多架構(gòu)師都有著豐富的經(jīng)驗(yàn)和個(gè)人風(fēng)格，以至于在平常工作中常以個(gè)人口味作為決策的依據(jù)，對(duì)于普通的開發(fā)人員也許是可行的，我們鼓勵(lì)大家有個(gè)人特色，但架構(gòu)師更應(yīng)該依據(jù)原則辦事，需要維護(hù)和遵守一套大家公認(rèn)的原則，以此作為判斷是非的工具從"可行走骨架"開始敏捷管理崇尚盡早集成，在架構(gòu)設(shè)計(jì)這一塊，這個(gè)原則也行之有效。架構(gòu)師在開始階段無需陷入某些難題或細(xì)節(jié)里，應(yīng)該盡快地把各個(gè)核心模塊串接起來，并能發(fā)動(dòng)開發(fā)人員使其簡(jiǎn)單地運(yùn)轉(zhuǎn)起來，骨架一旦就緒，再進(jìn)入健身環(huán)節(jié)。這樣做的好處，一方面可以盡早消除大家之間的誤解，也可以帶來正朝著正確方向前進(jìn)的信心數(shù)據(jù)是核心數(shù)據(jù)為王是大家深知的道理，只要這個(gè)系統(tǒng)擁

20、有有價(jià)值的數(shù)據(jù)，那么這個(gè)系統(tǒng)就有生命力。架構(gòu)設(shè)計(jì)中，數(shù)據(jù)無小事，任何數(shù)據(jù)只要是存在于系統(tǒng)中，就需要給予足夠的重視，也許是個(gè)廢棄的字段，但它也許會(huì)有一天被人錯(cuò)誤的引用到，或是時(shí)不時(shí)地遭到別人的詢問是干嘛用的。根據(jù)投資回報(bào)率進(jìn)行決策很多架構(gòu)師認(rèn)為計(jì)算和分配資源是PM要做的事情，與自己無關(guān)，自己要做的是設(shè)計(jì)最優(yōu)的系統(tǒng)。其實(shí)，這個(gè)最優(yōu)不光是技術(shù)上的最優(yōu)，往往在實(shí)際項(xiàng)目中大家所關(guān)注的是投資回報(bào)率最優(yōu)，老板想用最少的投資獲取符合需求的產(chǎn)品，PM想用最少的人力發(fā)布項(xiàng)目，開發(fā)人員想用少的代碼完成功能等等，作為架構(gòu)師應(yīng)該把投入產(chǎn)出比作為決策的一個(gè)重要因素起碼有兩個(gè)可選解決方案一個(gè)經(jīng)驗(yàn)豐富的架構(gòu)師會(huì)對(duì)一些關(guān)鍵的問

21、題給出多個(gè)解決方案，并能分析其優(yōu)缺點(diǎn)，并最后一般取舍之后做出選擇，這是一種令人信服的說明問題和解決問題的方式。不能不了解硬件軟件架構(gòu)師常常無法正確考慮硬件因素，有多種原因，但大多和缺乏硬件的了解脫離不了干系。最好的解決辦法是加強(qiáng)與基礎(chǔ)設(shè)施架構(gòu)師合作，共同對(duì)架構(gòu)和設(shè)計(jì)進(jìn)行評(píng)估架構(gòu)無小事很多系統(tǒng)建設(shè)初期的瑣碎事情在架構(gòu)師看來是些小事情，比如單元測(cè)試、多余的庫(kù)依賴、版本號(hào)的升級(jí)、開發(fā)人員不合理的代碼風(fēng)格等等，這些事情不給于重視盡早解決，會(huì)在將來的某天去解決會(huì)需要數(shù)倍的成本，有效率的架構(gòu)師會(huì)盡早解決這些"小事"警惕新技術(shù)，不輕易拋棄老技術(shù)很多架構(gòu)師包括大部分的開發(fā)人員都有新技術(shù)的追求傾向，但暗藏在每個(gè)新玩意后面的是風(fēng)險(xiǎn)和缺陷，在引入每項(xiàng)新技術(shù)之前，需要給予足夠的評(píng)估，不要只看到它power的一面，更應(yīng)該熟知其潛在的危害。而對(duì)于已接收過現(xiàn)實(shí)檢驗(yàn)的老技術(shù)不要輕易拋棄，可能它存在些缺陷是某些