軟件架構(gòu)師應(yīng)該知道的97件事讀后感(轉(zhuǎ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ù)需求作為至上的目標(biāo)，學(xué)會(huì)拒絕成本高，性價(jià)比不高的技術(shù)。  　　  　　簡(jiǎn)化根本復(fù)雜性  　　  　　常常為了解決某一局部復(fù)雜性引入了更為復(fù)雜的框架或產(chǎn)品，使得復(fù)雜性不減反增。往往正確的方式是做減法而不是加法，把最根本的復(fù)雜源找到，把根鏟除。  　　  　　關(guān)鍵問(wèn)題可能不是出在技術(shù)上  　　  　　總結(jié)失敗的項(xiàng)目常常會(huì)糾結(jié)于選擇了錯(cuò)誤的技術(shù)。其實(shí)技術(shù)并沒(méi)有錯(cuò)，而是在使用技術(shù)上或是在執(zhí)行過(guò)程中人為的偏差導(dǎo)致。而架構(gòu)師解決這種人為的問(wèn)題比較好的方式是溝通，通過(guò)有效地溝通把技術(shù)貫徹下去  　　  　　以溝通為中心，堅(jiān)持簡(jiǎn)明清晰和開明的風(fēng)格  　　  　　架構(gòu)師不要坐在象牙塔里，命令開發(fā)人員實(shí)施你的設(shè)計(jì)和決策，而是應(yīng)該盡量簡(jiǎn)化你的設(shè)計(jì)，透徹地與他們溝通，并且關(guān)鍵在于開明地接受他們的建議并勇于推翻自己的決策  　　  　　架構(gòu)決定性能  　　  　　最好提升性能的方法不是痛苦地做一次次對(duì)即將上線的產(chǎn)品做性能測(cè)試和提升，而是在架構(gòu)設(shè)計(jì)的時(shí)候就把性能作為重要因素，從架構(gòu)底層考慮分布式、緩存、系統(tǒng)交互劃分等影響性能的重點(diǎn)。提前關(guān)注性能，是解決性能問(wè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á)自己方案之前傾聽(tīng)他人觀點(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)天衣無(wú)縫，這往往是使系統(tǒng)更為復(fù)雜和脆弱的來(lái)源。先承認(rèn)是系統(tǒng)總會(huì)有缺陷的，只是把這些缺陷設(shè)定為容易察覺(jué)和維護(hù)的點(diǎn)  　　  　　量化非功能性需求  　　  　　往往功能性需求容易量化，因?yàn)檫@些是看得見(jiàn)和摸得著的，但像性能好、可擴(kuò)展性好、高可用性等這些非功能性需求卻不好量化，但作為架構(gòu)師要有意識(shí)地去定義和量化這些需求，只有這樣才能更好地和其他部門更好溝通，謀求更多資源，也便于系統(tǒng)更有效地驗(yàn)收  　　  　　一行代碼比500行架構(gòu)說(shuō)明更有說(shuō)服力  　　  　　架構(gòu)師往往喜歡待在象牙塔里，堆砌大量架構(gòu)文檔，然后希望其他開發(fā)人員能乖乖地去實(shí)施。這樣做的效果往往是不好的，一方面很難有這樣的牛人能洞察所有的細(xì)節(jié)，在文檔里就預(yù)測(cè)性地解決了所有問(wèn)題，另一方面也不利于架構(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)闆](méi)有一種已有方案能完全不修改地適用于你。  　　  　　架構(gòu)設(shè)計(jì)要平衡兼顧多方需求  　　  　　架構(gòu)師從某種角度來(lái)講就是一劑膠水，把業(yè)務(wù)部門的需求、項(xiàng)目進(jìn)度的需求、測(cè)試的需求和開發(fā)工程師本身的需求有效地捏合在一起，平衡與兼顧以至達(dá)到皆大歡喜。其他職能的人都只是focus在某一局部，需要架構(gòu)師這樣的人來(lái)通盤考慮，因此他的工作是最雜的，絕不是簡(jiǎn)簡(jiǎn)單單地拿出一份架構(gòu)文檔就OK了，需要考慮系統(tǒng)安全、易用性、可測(cè)性、商業(yè)價(jià)值、長(zhǎng)期規(guī)劃、發(fā)布管理和部署方式，使得各個(gè)部門人的需求得到響應(yīng)。  　　  　　先確保解決方案簡(jiǎn)單可用，再考慮通用性和復(fù)用性  　　  　　系統(tǒng)的復(fù)雜性往往是架構(gòu)師基于通用性和復(fù)用性的設(shè)計(jì)而引入的，很多具體問(wèn)題往往不需要通用性和復(fù)用性的解決方案。如果存在多個(gè)可實(shí)施方案難以取舍，先簡(jiǎn)單后通用原則可以成為最終的評(píng)判標(biāo)準(zhǔn)。架構(gòu)師提供具體解決方案時(shí)，無(wú)需排斥通用和靈活，但是如果過(guò)早脫離具體情況，只會(huì)迷失在無(wú)限的可能性里，被復(fù)雜的配置選項(xiàng)、超負(fù)荷的參數(shù)列表、冗長(zhǎng)羅嗦的接口，以及存在缺陷的抽象所淹沒(méi)。先簡(jiǎn)單滿足需求，當(dāng)重復(fù)需求再次發(fā)生時(shí)，通過(guò)重構(gòu)來(lái)達(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í)采取行動(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)行起來(lái)。  　　  　　避免進(jìn)度調(diào)整失誤  　　  　　雖然保障進(jìn)度是PM的職責(zé)，但變更要發(fā)生的時(shí)候，作為對(duì)技術(shù)最有發(fā)言權(quán)的架構(gòu)師應(yīng)該站出來(lái)，把變更的必要性和風(fēng)險(xiǎn)進(jìn)行仔細(xì)分析，最大限度地支持PM的決策。  　　  　　取舍的藝術(shù)  　　  　　我們做系統(tǒng)，特別是互聯(lián)網(wǎng)系統(tǒng)，絕不是做一個(gè)變形金剛，而是做一個(gè)有缺陷但卻滿足了現(xiàn)階段商業(yè)需求的系統(tǒng)，因此架構(gòu)師需要有取舍的藝術(shù)，你的架構(gòu)是能用有限的資源滿足最迫切的需求，舍掉那些看是光鮮卻無(wú)太多用處的東西  　　  　　打造數(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)的基石，無(wú)論是業(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è)計(jì)決策的重要性，糟糕的架構(gòu)則會(huì)使得常常突出選擇的重要性。如果出現(xiàn)兩個(gè)合理地選擇，架構(gòu)師應(yīng)該停下來(lái)，設(shè)法找出介于兩者之間的、具有更低重要性的決策，了解兩者之外還存在其他選擇，比決策結(jié)果本身更有價(jià)值  　　  　　不要輕易放過(guò)不起眼的問(wèn)題  　　  　　項(xiàng)目的失敗或線上故障往往是由于項(xiàng)目過(guò)程中的不起眼問(wèn)題所引起，比如一些特殊的邊界情況，而這些問(wèn)題絕不能指望開發(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ù)用地解決問(wèn)題的意識(shí)，比如以上幾種措施：  　　  　　 * 讓大家把自己能復(fù)用的代碼及時(shí)共享給他人  　　 * 加強(qiáng)復(fù)用代碼的易用性，避免誤用  　　 * 讓大家認(rèn)識(shí)到已有資源好過(guò)自己動(dòng)手  　　  　　架構(gòu)文檔的抽象程度要適中  　　  　　架構(gòu)師寫架構(gòu)文檔常常很糾結(jié)，寫得太高層次的話就太空洞，無(wú)切實(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í)別和如何規(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)做決策，感覺(jué)這就是架構(gòu)師需要干的。其實(shí)，這樣的做法往往會(huì)讓你很被動(dòng)，不如延遲決策，把需要決策的點(diǎn)拋出來(lái)，讓大家去嘗試，在實(shí)踐比較中，其實(shí)無(wú)須決策，正確的選擇自然就出來(lái)了，這樣也更能拉近你和大家的距離，提高大家的積極性和你的權(quán)威性  　　  　　掌握業(yè)務(wù)領(lǐng)域知識(shí)  　　  　　架構(gòu)師的角色任務(wù)在于理解業(yè)務(wù)問(wèn)題、業(yè)務(wù)目標(biāo)、業(yè)務(wù)需求、并設(shè)計(jì)技術(shù)架構(gòu)來(lái)滿足它們。掌握業(yè)務(wù)領(lǐng)域知識(shí)將有利于架構(gòu)師選擇合適的架構(gòu)模式，更好地制定針對(duì)

【軟件架構(gòu)師應(yīng)該知道的97件事讀后感(轉(zhuǎn))】相關(guān)文章：

Java架構(gòu)師的職責(zé)02-26

讀后感：讀{大人應(yīng)該知道孩子的事}的淺薄體會(huì)04-28

報(bào)考BEC之前需要知道的五件事05-04

Java架構(gòu)師的職責(zé)合集14篇02-27

我知道了我知道了作文04-05

Java架構(gòu)師的職責(zé)（錦集14篇）02-26

《汽車轱轆轉(zhuǎn)呀轉(zhuǎn)》教案02-09

假期里的一件事作文（通用97篇）12-22

應(yīng)該的作文09-02

我知道作文06-12