轉(zhuǎn)架構(gòu)設(shè)計準則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16、狀態(tài)存在的情況下設(shè)計軟件。關(guān)注邊界和接口任何系統(tǒng)或模塊的邊界和接口都是與外交互的門面，有交互就暗藏著誤解和不恰當?shù)膭澐郑３纸涌诘捻槙辰换ナ羌軜?gòu)師的重要職責(zé)。往往bug發(fā)生在模塊與模塊之間、系統(tǒng)與系統(tǒng)之間，項目的失敗也往往因為系統(tǒng)間交互問題，因此架構(gòu)師需要給予足夠的關(guān)注助力開發(fā)人員架構(gòu)師的完美設(shè)計需要開發(fā)人員是實現(xiàn)，因此有業(yè)務(wù)想辦法提升開發(fā)團隊的戰(zhàn)斗力，常有以下方式：尋找或開發(fā)工作需要的工具，并附上使用技巧做定期的分享或提高團隊學(xué)習(xí)氣氛，保持團隊技術(shù)上的先進性參與開發(fā)團隊的招聘工作給予開發(fā)人員更多的決策空間，幫助其成長保護好開發(fā)人員，讓他們盡可能地免于雜事之中直接參與開發(fā)，分擔(dān)壓力記錄決策的理

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

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

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

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

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