軟件架構(gòu)師應(yīng)該知道的97件事讀后感(轉(zhuǎn))

　　  　　客戶需求高于一切  　　  　　不要為了自己的項目經(jīng)歷上添加光彩而去一味追求時髦而光鮮的方案，而是應(yīng)該扎根客戶需求，腳踏實地地為客戶著想，這樣才能更體現(xiàn)技術(shù)的價值，不至于迷失方向。架構(gòu)師首先不要把自己當做技術(shù)人員，而是業(yè)務(wù)人員，把實現(xiàn)業(yè)務(wù)需求作為至上的目標，學(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)決定性能  　　  　　最好提升性能的方法不是痛苦地做一次次對即將上線的產(chǎn)品做性能測試和提升，而是在架構(gòu)設(shè)計的時候就把性能作為重要因素，從架構(gòu)底層考慮分布式、緩存、系統(tǒng)交互劃分等影響性能的重點。提前關(guān)注性能，是解決性能問題代價最小的方式  　　  　　分析客戶要求背后的真實需求  　　  　　合同上或UC上只是客戶的要求，而并非100%是客戶真實的需求，架構(gòu)師的重要責(zé)任就是挖掘隱藏在要求背后的真實需求，這個不但可以最大化滿足客戶，也往往可以幫助我們避開技術(shù)壁壘，當真正抓住客戶需求的時候，我們也許能用更為簡單的替代方案滿足客戶  　　  　　溝通是架構(gòu)師達成目標的核心技能  　　  　　常用的溝通技能和準則有以下幾點：  　　  　　 * 不要把溝通當做對抗  　　 * 不要帶有情緒與人溝通  　　 * 表達自己方案之前傾聽他人觀點  　　 * 站立發(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)說明更有說服力  　　  　　架構(gòu)師往往喜歡待在象牙塔里，堆砌大量架構(gòu)文檔，然后希望其他開發(fā)人員能乖乖地去實施。這樣做的效果往往是不好的，一方面很難有這樣的牛人能洞察所有的細節(jié)，在文檔里就預(yù)測性地解決了所有問題，另一方面也不利于架構(gòu)師與開發(fā)人員的溝通。比較好的做法是架構(gòu)師參與具體實施，在實施中驗證和改進架構(gòu)設(shè)計，與大家達成一片也便于加深彼此配合的默契程度。  　　  　　不存在放之四海皆準的解決方案  　　  　　不存在最好的架構(gòu)，只有最合適的架構(gòu)。不會有一種架構(gòu)方案，在任何項目里都適用。雖然我們承認模式的重要性，但在實際項目里要有選擇性吸收，根本上要本項目和實際困境出發(fā)，不要被既有的模式和經(jīng)驗先入為主，因為沒有一種已有方案能完全不修改地適用于你。  　　  　　架構(gòu)設(shè)計要平衡兼顧多方需求  　　  　　架構(gòu)師從某種角度來講就是一劑膠水，把業(yè)務(wù)部門的需求、項目進度的需求、測試的需求和開發(fā)工程師本身的需求有效地捏合在一起，平衡與兼顧以至達到皆大歡喜。其他職能的人都只是focus在某一局部，需要架構(gòu)師這樣的人來通盤考慮，因此他的工作是最雜的，絕不是簡簡單單地拿出一份架構(gòu)文檔就OK了，需要考慮系統(tǒng)安全、易用性、可測性、商業(yè)價值、長期規(guī)劃、發(fā)布管理和部署方式，使得各個部門人的需求得到響應(yīng)。  　　  　　先確保解決方案簡單可用，再考慮通用性和復(fù)用性  　　  　　系統(tǒng)的復(fù)雜性往往是架構(gòu)師基于通用性和復(fù)用性的設(shè)計而引入的，很多具體問題往往不需要通用性和復(fù)用性的解決方案。如果存在多個可實施方案難以取舍，先簡單后通用原則可以成為最終的評判標準。架構(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)異常隨時采取行動。架構(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)，絕不是做一個變形金剛，而是做一個有缺陷但卻滿足了現(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è)計決策的重要性，糟糕的架構(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ù)用代碼的易用性，避免誤用  　　 * 讓大家認識到已有資源好過自己動手  　　  　　架構(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和運維人員需要知道系統(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)師選擇合適的架構(gòu)模式，更好地制定針對

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

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

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

報考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