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