image from pixabay

隨著業(yè)務(wù)規(guī)模擴(kuò)大、團(tuán)隊(duì)組成變復(fù)雜，如何降低項(xiàng)目實(shí)施風(fēng)險(xiǎn)乾闰，降低軟件復(fù)雜度變得尤為關(guān)鍵。 我從 Martin Flower盈滴、Joel Spolsky（軟件隨想錄 作者） 等巨匠智慧中尋找解決復(fù)雜工程之道涯肩，其中 Code Review 是行之有效手段。 我認(rèn)同 Code Review 價(jià)值也是忠實(shí)執(zhí)行者巢钓。

加入螞蟻以后病苗，我在所接觸項(xiàng)目中都大力推廣 Code Review。 感謝團(tuán)隊(duì)信任和支持症汹，目前 CR 協(xié)作進(jìn)展順利硫朦， 項(xiàng)目 CR 從最早不主動(dòng)，到現(xiàn)在形成基于模塊 Owner 制度 CR 和 Peer Review背镇。 我也曾經(jīng)在 3 個(gè)月內(nèi)處理完成 700 多個(gè) Pull Request咬展，并在 PR 討論中中都留下一些有價(jià)值討論。 這里我將自己對(duì) Code Review 一些理解記錄下來(lái)瞒斩。

這一篇先講講進(jìn)入 Code Review 之前需要做準(zhǔn)備工作破婆。

評(píng)估團(tuán)隊(duì)成熟度

image from pixabay

不管是在一個(gè)遺留系統(tǒng)上推廣 Code Review，還是在一個(gè)新團(tuán)隊(duì)推廣 Code Review胸囱， 起手式不是立馬挽起袖子猛干祷舀，而是應(yīng)當(dāng)觀察一下當(dāng)前所處情況是否允許自己推動(dòng)這個(gè)「艱巨」任務(wù)。 最需要觀察的是團(tuán)隊(duì)成熟度烹笔。

我將團(tuán)隊(duì)成熟度粗略分為草臺(tái)班子裳扯、成長(zhǎng)型團(tuán)隊(duì)、成熟團(tuán)隊(duì)箕宙。 具體衡量指標(biāo)可以有成員技術(shù)儲(chǔ)備嚎朽、團(tuán)隊(duì)成員信任度、團(tuán)隊(duì)負(fù)責(zé)人對(duì)工程管控力度柬帕。 相信集團(tuán)內(nèi)大部分團(tuán)隊(duì)處于成長(zhǎng)型哟忍、成熟型團(tuán)隊(duì)。 但如果考慮到生態(tài)同學(xué)一起協(xié)作陷寝，或者臨時(shí)因?yàn)榫o急項(xiàng)目湊在一起锅很，就比較容易成為「草臺(tái)班子」。

如果還停留在草臺(tái)班子凤跑，那就得先在團(tuán)隊(duì)內(nèi)形成一定共識(shí)： 包括技術(shù)共識(shí)和合作模式的共識(shí)爆安。 技術(shù)共識(shí)需要包括：技術(shù)棧共識(shí)、好代碼定義仔引、研發(fā)流程共識(shí)等扔仓。 合作模式共識(shí)需要包括：沖突解決機(jī)制褐奥、職責(zé)范圍邊界、決策機(jī)制等翘簇。 如果基本共識(shí)還沒(méi)有形成就倉(cāng)促進(jìn)入 Code Review撬码，那就容易將一件好事變成工程師戰(zhàn)爭(zhēng)。

并不是所有團(tuán)隊(duì)版保、項(xiàng)目都適合無(wú)差別引入 Code Review呜笑。這么幾種情況建議暫緩 Code Review 推廣：

• 老板和同事都不支持甚至反對(duì)
• 業(yè)務(wù)重要性低，或者團(tuán)隊(duì)都是特立獨(dú)行高手
• 創(chuàng)新業(yè)務(wù)需要快速上線彻犁，這時(shí)候適合將這類(lèi)任務(wù)分發(fā)給配合度高老團(tuán)隊(duì)叫胁，或者給高手單兵作戰(zhàn)

當(dāng)條件不滿(mǎn)足時(shí)也不用氣餒。先成為一個(gè)布道師吧汞幢，探索一下團(tuán)隊(duì)中有沒(méi)有相似想法的人驼鹅，了解一下他們擔(dān)心點(diǎn)和訴求點(diǎn)。 相信只要條件允許森篷，沒(méi)有人會(huì)拒絕提高工程質(zhì)量谤民。

構(gòu)建「好代碼」共識(shí)

image from pixabay

Code Review 核心產(chǎn)出物是代碼，如何界定代碼是好是壞就至關(guān)重要疾宏。 根據(jù) Bjarne（「C++ Programming Language」作者）、Grady Booch（「面向?qū)ο蠓治雠c設(shè)計(jì)」作者）等人定義触创， 總結(jié)下來(lái)好代碼有這么基本特征（via「Clean Code」）：

• 正確
• 可測(cè)試
• 不重復(fù)
• 少且簡(jiǎn)單
• 可讀

深思一下這些基本特征背后道理：代碼是人類(lèi)和機(jī)器溝通工具坎藐，好代碼也要利于人類(lèi)閱讀和再次書(shū)寫(xiě)。 人比機(jī)器更犯錯(cuò)哼绑，機(jī)器算力在成倍增長(zhǎng)岩馍，因此簡(jiǎn)單易維護(hù)重要度逐步增高。 這些樸素道理也正是語(yǔ)言從低級(jí)語(yǔ)言進(jìn)化到高級(jí)語(yǔ)言驅(qū)動(dòng)力抖韩， 也是近幾年高級(jí)語(yǔ)言語(yǔ)言特性主打點(diǎn)（類(lèi)型系統(tǒng)蛀恩、格式系統(tǒng)、面向人類(lèi)同步思想異步設(shè)計(jì)）茂浮。

但上面這幾條原則太底層了双谆，無(wú)法成為實(shí)踐標(biāo)準(zhǔn)。 因此行業(yè)基于這些公理衍生了不少實(shí)踐定理席揽，我將其分為工程規(guī)約和設(shè)計(jì)范式兩類(lèi)顽馋。

工程規(guī)約包含語(yǔ)言風(fēng)格規(guī)約和應(yīng)用工程規(guī)約。 語(yǔ)言風(fēng)格規(guī)約比較容易理解幌羞，開(kāi)源世界提供了很多選擇寸谜。硅谷大廠 Google / Facebook / Uber 等都有不少規(guī)約提供。 國(guó)內(nèi)還有極具價(jià)值的「阿里巴巴 Java 開(kāi)發(fā)手冊(cè)」属桦，我稱(chēng)之為 50331 ;) （PS：「阿里巴巴 Java 開(kāi)發(fā)手冊(cè)」不僅有語(yǔ)言風(fēng)格規(guī)約熊痴、也有應(yīng)用工程規(guī)約和一部分設(shè)計(jì)規(guī)約）他爸。 這里羅列了一些常見(jiàn)面向語(yǔ)言的 Style Guide。

• Google Style Guides | styleguide
  • 包含 C++ / Object-C / Java / Python / R / Shell / HTML CSS / JavaScript / AngularJS / Common Lisp / Vimscript
• alibaba/p3c: Alibaba Java Coding Guidelines pmd implements and IDE plugin
  • Java
• airbnb/javascript: JavaScript Style Guide
  • JavaScript
• uber-go/guide: The Uber Go Style Guide.
  • Go

應(yīng)用工程規(guī)約關(guān)注點(diǎn)則更為落地：包括依賴(lài)管理果善、配置管理诊笤、應(yīng)用層次結(jié)構(gòu)、對(duì)外服務(wù)暴露約束岭埠，數(shù)據(jù)建模盏混，文檔注釋?zhuān)瑴y(cè)試管理， 甚至包含中間件使用規(guī)約惜论。 這些規(guī)約逐步從「如何表達(dá)代碼」延展到到「如何管理工程」许赃。 這塊發(fā)揮空間比較大，中大規(guī)模團(tuán)隊(duì)會(huì)有應(yīng)用框架組這樣團(tuán)隊(duì)馆类。 基于應(yīng)用框架對(duì)使用方式方法約束混聊。針對(duì)具體業(yè)務(wù)使用也會(huì)給出針對(duì)性建議。 這些定理總結(jié)出來(lái)往往以輕量 Best Practice 和重量級(jí)應(yīng)用框架對(duì)外輸出乾巧。

這里舉兩個(gè)例子說(shuō)明一下應(yīng)用工程規(guī)約應(yīng)該講清楚哪些問(wèn)題句喜。 第一個(gè)例子 alibaba/COLA 這個(gè)項(xiàng)目來(lái)說(shuō)，它約束了整體工程結(jié)構(gòu)沟于，并且明確的通過(guò) Archetype 幫助（約束）用戶(hù)行為咳胃。 第二個(gè)例子是 RoR / Django 這類(lèi) RoR 框架，他們使用約定大于配置方式旷太，基于 ActiveRecord 這種模式約束了用戶(hù)如何使用框架展懈， 從 Model、Controller 到 Router供璧，對(duì)立面則是 Spring MVC / Flask 這類(lèi)框架存崖，幾乎只提供純技術(shù)特性，不約束開(kāi)發(fā)者行為睡毒。

除了阿里 Java 開(kāi)發(fā)手冊(cè)来惧，這里提供三個(gè)應(yīng)用工程規(guī)范供參考：

• alibaba/COLA: Clean Object-oriented & Layered Architecture
• SOFA 項(xiàng)目工程結(jié)構(gòu) - 螞蟻金服金融科技 和 SOFA 微服務(wù)平臺(tái)概述 - 螞蟻金服金融科技
• realpython/python-guide: Python best practices guidebook, written for humans.

比工程規(guī)約更難定義的是設(shè)計(jì)范式，核心點(diǎn)是解決「如何做架構(gòu)決策」演顾。 設(shè)計(jì)范式?jīng)Q策過(guò)程在系統(tǒng)架構(gòu)設(shè)計(jì)和系分設(shè)計(jì)階段就應(yīng)當(dāng)完成了供搀。 如果設(shè)計(jì)范式差異性導(dǎo)致代碼在 Code Review 階段出現(xiàn)意見(jiàn)不一。 要么是這個(gè)團(tuán)隊(duì)過(guò)于草臺(tái)班子偶房，要么是這個(gè)項(xiàng)目架構(gòu)師/負(fù)責(zé)人在前期設(shè)計(jì)做的工作太少了趁曼。

當(dāng)一個(gè)團(tuán)隊(duì)遵循相近設(shè)計(jì)范式，意味著他們達(dá)到了同一級(jí)別技術(shù)儲(chǔ) 備棕洋，并形成了統(tǒng)一自頂向下設(shè)計(jì)打法挡闰。 在 Code Review 過(guò)程中，一些范式使用完全可以將 GoF23 / S.O.L.I.D. / DDD 這些術(shù)語(yǔ)概念拎出來(lái)。 相信 Commiter 和 Reviewer 可以基于業(yè)務(wù)場(chǎng)景快速達(dá)成一致摄悯。

方法論貼在墻上是無(wú)法解決開(kāi)發(fā)中中遇到設(shè)計(jì)問(wèn)題赞季，在代碼中真刀真槍干，Show me the fuck code奢驯。

Code Review 溝通協(xié)作機(jī)制

image from pixabay

除了工程規(guī)約申钩，還有一件事情往往會(huì)被忽略，如何解決沖突瘪阁？ 這個(gè)沖突不是指代碼 Conflict撒遣，而是面對(duì)技術(shù)方案決策時(shí)候交流討論。

文無(wú)第一武無(wú)第二管跺，兩個(gè)秀才在一起能吵到天翻地覆面紅耳赤义黎。 技術(shù)層面 Augue 容易陷入我說(shuō)我有理你說(shuō)你有理局面。這種情況如何解決豁跑？ 沒(méi)有一個(gè)好協(xié)作機(jī)制廉涕，會(huì)倒逼 Commiter 和 Reviewer 退縮，不能充分展開(kāi)討論艇拍。 這是我們不想看見(jiàn)狐蜕。

很多時(shí)候技術(shù)決策就是在 40% 正確性 和 60% 正確性中間選擇，看中長(zhǎng)期收益和短期收益就可能導(dǎo)致結(jié)論不一樣卸夕。 非黑既白反而不容易有爭(zhēng)論层释。想要促進(jìn)快速?zèng)Q策，一套沖突解決機(jī)制就不可缺少快集。 因此一定要在事前制定一套沖突解決機(jī)制湃累。大部分沖突解決都可以使用這么一套邏輯：數(shù)據(jù)、邏輯碍讨、民主、獨(dú)裁蒙秒。 當(dāng)需要進(jìn)行某個(gè)技術(shù)或者產(chǎn)品決策時(shí)候勃黍，最優(yōu)先方式是用數(shù)據(jù)來(lái)量化，證明自己觀點(diǎn)晕讲。 當(dāng)數(shù)據(jù)不充分時(shí)候覆获，可以進(jìn)行邏輯歸納推衍形成結(jié)論。 當(dāng)形成邏輯不能服眾眾說(shuō)紛紜時(shí)候瓢省，可以使用民主方式進(jìn)行裁決弄息。 當(dāng)民主也無(wú)法生效，就需要 Owner / 一號(hào)位力排眾議勤婚，進(jìn)行獨(dú)裁決策了摹量。

CodeReview 有這么幾種形式，同步離線、異步離線缨称、同步在線凝果。 處于同步形式 CodeReview 需要盡快處理掉 PR，這時(shí)候協(xié)作機(jī)制一定要干凈利索睦尽，避免大家在 PR 反反復(fù)復(fù)來(lái)來(lái)回回討論器净。 如果每個(gè) PR 都要消耗數(shù)次來(lái)回溝通，我建議將 CR 形式升級(jí)到同步在線当凡，拉個(gè)會(huì)議立刻將事情解決山害。

如果在一個(gè)實(shí)現(xiàn)方案上真無(wú)法決策，如果不涉及原則沿量，那我建議使用擱置爭(zhēng)議浪慌，使用 TODO @commiter what, how, when 方式先標(biāo)記意見(jiàn)和處理時(shí)間，先行將工程開(kāi)發(fā)往下推進(jìn)欧瘪。

一切準(zhǔn)備好了眷射，謝天謝地，終于可以進(jìn)入 Code Review 階段了佛掖。 我們下篇文章再來(lái)講進(jìn)入 Code Review 階段的事情妖碉。

原文鏈接: 淺談 Code Review 之事前準(zhǔn)備 - Log4D

3a1ff193cee606bd1e2ea554a16353ee