史海峰：架構(gòu)評審的意義
許多公司的項目流程中都有架構(gòu)評審環(huán)節(jié)，卻鮮少有人提起，大概對于參與者來說都并不是多么愉快的經(jīng)歷，一提都要皺著眉頭，各有一肚子苦水涌上心頭，慨嘆不堪回首。
被評審的同學感覺像是過堂，冥冥中有人在高聲呼喝“升堂~~威武~~”，生怕自己一句話沒說明白，對面的黑臉胖子就會蹦起來叫“開鍘”，沒通過評審連死的心都有。
依我看，這源于認知沖突(這個詞兒是從《架構(gòu)即未來》里學的)，參與各方的認知不一致，甚至引發(fā)情感沖突。
今天簡單說說我對架構(gòu)評審的認識，主要是評審的意義所在，理解了意義，目標一致，自然同心協(xié)力。
曾經(jīng)有次架構(gòu)評審，兩位其他部門的同事問我架構(gòu)設(shè)計有什么特別思維，要掌握哪些不為人知的高能技巧。
我當時心思還在方案上，順口回答其實跟編程做開發(fā)都是一脈相承的，該怎么拆分解耦怎么抽象聚合，道理上都是一樣一樣一樣的啊。
大概這個答案不符合兩位同事的預(yù)期，他們臉上有些失望，還有些不以為然，可能認為我在敷衍或者是本身就其實難副，就沒再繼續(xù)交流下去。
似乎不久之后，他們都離開了那個公司，不知如今是否找尋到了滿意的答案。
如今再想，當年的確回答得太狹隘了，架構(gòu)設(shè)計還要考慮很多其他方面。
架構(gòu)評審、跟技術(shù)方案評審、CodeReview一樣，都是項目流程必要環(huán)節(jié)，是指對架構(gòu)設(shè)計方案進行評審。
在傳統(tǒng)的軟件工程理論中，設(shè)計階段產(chǎn)出物就是設(shè)計文檔，包括概要設(shè)計/詳細設(shè)計，但不分產(chǎn)品和研發(fā)，所以文檔既包括功能描述，也包括技術(shù)實現(xiàn)，有些對日外包的項目，甲方發(fā)過來的文檔里連偽代碼都寫好了，就等著你翻譯成代碼，外包工程師純粹就是一個翻譯機器。
而到了互聯(lián)網(wǎng)時代，提倡敏捷迭代，總嫌傳統(tǒng)方式太重，流程復(fù)雜，影響效率，什么都希望短平快，在扁平化的組織中，經(jīng)常是需求火速分發(fā)到一線研發(fā)，然后就靠個人折騰去了。
實際上達到一定規(guī)模的公司多半會進行架構(gòu)評審，即由架構(gòu)評審組織(架構(gòu)評審委員會之類)制定架構(gòu)設(shè)計文檔規(guī)范，設(shè)計人員根據(jù)規(guī)范編寫方案，設(shè)計人員當面向評審人員講解方案，回答評審人員問題，評審人員提出意見和建議，雙方進行討論以充分溝通，最終由評審人員決定是否通過，一次評審不通過可以修改后再次評審。
本質(zhì)上架構(gòu)評審跟測試相同，都為了保證質(zhì)量，也沒見誰對測試有多反感，宣稱不需要測試通過就可以直接上線的。
由于技術(shù)人員普遍存在文人相輕的心理，對于參加評審被人挑毛揀刺的活動容易有所抵觸。
評審過程中會講到實現(xiàn)的關(guān)鍵點，因此有些相關(guān)人員也會參與了解，比如測試、數(shù)據(jù)、安全等，可能在無形中增加了被審者的心理壓力。
畢竟架構(gòu)設(shè)計代表著更高階的技術(shù)能力，當面當眾被指出問題要求修改，慣于“一人我擼代碼”的研發(fā)人員容易自尊心受傷，面子上掛不住。
有強烈的技術(shù)個人自由主義傾向的同學，并不適合團隊作戰(zhàn)。
只注重研發(fā)實現(xiàn)，技術(shù)新潮，不關(guān)注線上性能、持續(xù)運維、故障應(yīng)急的程序猿，再牛也不是好攻城獅。
自己的設(shè)計被指出問題，提出改進建議，不喜反惱，則是心態(tài)不成熟的表現(xiàn)。
架構(gòu)評審的目的是什么?
把關(guān)，確保方案合格，各方面都考慮到了，避免缺陷和遺漏，不求方案多牛，至少不犯錯。
保證架構(gòu)設(shè)計合理和基本一致，符合整體原則。
維持對系統(tǒng)架構(gòu)的全局認知，避免黑盒效應(yīng)。
通過評審發(fā)掘創(chuàng)新亮點，推廣***實踐。
以上四點重要性從高到低排列。
可見，評審都是對事，而不是對人，參與評審的各方是平等的，各司其職，而項目是服務(wù)于公司業(yè)務(wù)的。
有人會自信滿滿拍著胸脯說自己的設(shè)計已經(jīng)足夠***，不需要再費時間給別人講，你敢保證別人的也跟你一樣***么?這次***了，下次也會么?
方案設(shè)計不僅僅是考慮功能實現(xiàn)，還有很多非功能需求，以及持續(xù)運維所需要的工作，需要工程實踐經(jīng)驗，進行平衡和取舍。
架構(gòu)設(shè)計往往沒有想象中那么簡單純粹，甚至一多半的精力要關(guān)注非核心的方面。
隨便舉幾個例子：
- 互聯(lián)網(wǎng)金融公司的系統(tǒng)沒有對賬機制——你還敢投錢在里面么?
- 有的人號稱玩轉(zhuǎn)高并發(fā)多線程，扣減積分/余額程序就是先查詢，再判斷夠不夠，夠的話就減掉后更新。——不知道被人白刷掉多少呢，刷多了應(yīng)該能發(fā)現(xiàn)，拜托，對賬都沒有，你怎么發(fā)現(xiàn)?
- 對異常情況考慮不全，數(shù)據(jù)流斷了，數(shù)據(jù)就丟了，邏輯要是再復(fù)雜點兒，時間再久一點，再想修復(fù)?愁死你。
- 核心業(yè)務(wù)應(yīng)用，方案設(shè)計很費心思，但沒考慮過性能指標，也沒想過怎么監(jiān)控告警——這都是沒吃過虧，捅過簍子的。
- 有人對著自己的***方案講著講著，不等別人指出，就發(fā)現(xiàn)了數(shù)據(jù)邏輯沒有完整閉環(huán)的問題。
有人會說經(jīng)驗都是趟坑積累出來的，否則沒法成長，你問問老板愿意拿業(yè)務(wù)系統(tǒng)當練手的試驗田么?
于是有了架構(gòu)評審，更多有豐富經(jīng)驗的人花較少的時間成本，快速的過一遍方案設(shè)計，三個臭皮匠賽過諸葛亮，更何況有資格做架構(gòu)評審的，都是見識過各種情況的。
但不代表評審的人就高人一等更權(quán)威，再牛的人，討論技術(shù)方案，也要以理服人。
有些做評審的，認為浪費自己時間，因為總是那些常見問題，還要耐心聽完，自己似乎沒有得到什么提高，請注意，能避免犯錯，系統(tǒng)不至于三天兩頭到處冒煙，這就是莫大的光榮。
有些被評審的，在評審時感覺低人一頭，仿佛被人審判，進一步會想“憑什么你來評審我，你算老幾啊，這業(yè)務(wù)你沒我懂啊!”對不起，這真不是業(yè)務(wù)百科知識大賽。
身邊的人牛就不爽，覺得沒啥了不起，碰到業(yè)界大神又驚呼真平易近人!
其實大神本來就平易近人，不會覺得自己高高在上，心智成熟，有自知之明。
大牛之所以成為大牛，也許就因為人家不飄飄然，腳踏實地，勤于做事，虛懷若谷，空杯心態(tài)。
系統(tǒng)是滿足需求，實現(xiàn)業(yè)務(wù)功能的，大家都是為了能查漏補缺才坐到一起。
良好的心態(tài)才能合作，才能共贏。功勞是大家的，出了問題，共擔責任，不能置身事外。
***一句，既然都來了，放下那些有的沒的，好好琢磨方案才是正道!
【本文為51CTO專欄作者“史海峰”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號“IT民工閑話（ITCrossTalker）”獲取聯(lián)系和授權(quán)】
