本文是“代碼審查關(guān)注什么”系列文章的第一篇（共六篇）夯缺。
我們一起來討論下代碼審查强岸。如果你花幾秒鐘時間搜索一下代碼審查的信息峦树，你會發(fā)現(xiàn)很多文章都在講為什么代碼審查是件好事（比如Atwood 的這篇博客）。
你也會發(fā)現(xiàn)很多關(guān)于如何使用代碼審查工具的文檔（比如我們自己的 Upsource）戚扳。
然而你很少會發(fā)現(xiàn)一些指南忧便，會告訴你作為代碼審查者在審查別人代碼時需要關(guān)注哪些東西。
之所以沒有權(quán)威的文章告訴你在代碼審查中需要關(guān)注哪些東西帽借，其原因可能是：有太多不同的事情需要關(guān)注珠增。并且超歌，像其他的需求（功能性的或者非功能性的）一樣，不同的團(tuán)隊對每個方面有不同的優(yōu)先級蒂教。
因為這是一個很大的主題巍举，本文的目的僅僅是列出大綱，用于說明作為代碼審查者在審查代碼時需要關(guān)注的東西凝垛。決定各個方面的優(yōu)先級并不斷的檢驗也是一個非常復(fù)雜的主題懊悯，本身就可以單獨寫出一篇文章。
當(dāng)你在審查其他人的代碼時梦皮，你在關(guān)注什么炭分？
不管你是通過像 Upsource 這樣的工具還是同事的講解來審查代碼，有一些東西是比較容易評判的届氢。比如：
- 格式：空格和換行在哪里欠窒？他們使用的是 tab 還是空格？大括號怎么布局退子？
- 風(fēng)格：變量/參數(shù)聲明為 final ？方法變量是在使用時再定義型将，還是在方法開始的地方定義寂祥？
- 命名：字段、常量七兜、變量丸凭、參數(shù)、類的命名遵循標(biāo)準(zhǔn)了嗎腕铸？名稱有過于簡短嗎惜犀？
- 代碼覆蓋率：這段代碼有寫測試代碼嗎？
檢查這些東西都是有意義的--你希望把不同代碼之間的切換最小化并且減少認(rèn)知負(fù)擔(dān)狠裹，所以你的代碼看起來越一致越好虽界。
然而，在你的團(tuán)隊中涛菠，使用人力檢查這些也許不是對時間和資源的最佳利用莉御，因為很多這樣的檢查都可以自動化進(jìn)行。有很多工具可以保證：你的代碼格式連貫一致俗冻，遵循命名標(biāo)準(zhǔn)和使用 final 關(guān)鍵字礁叔，并且可以發(fā)現(xiàn)一些簡單的編程錯誤導(dǎo)致的 bug。例如迄薄，你可以通過命令行使用 IntelliJ IDEA 的檢查琅关，所以你不必要求所有的團(tuán)隊成員都在他們的 IDE 中運(yùn)行檢查。
你應(yīng)該關(guān)注什么讥蔽？
人類真正擅長的是哪幾類事情涣易？什么是東西是我們在代碼審查中發(fā)現(xiàn)但是檢查工具發(fā)現(xiàn)不了的画机？
事實證明有很多事情。這當(dāng)然也不是一個詳盡的清單都毒，我們也不會在這里就某一項進(jìn)行詳細(xì)討論色罚。然而，你的團(tuán)隊?wèi)?yīng)該就代碼審查應(yīng)關(guān)注什么账劲，展開交流戳护，并且也許是你應(yīng)該關(guān)注的。
設(shè)計
- 新的代碼怎么符合總體的架構(gòu)瀑焦？
- 代碼遵循 SOLID原則腌且，領(lǐng)域驅(qū)動設(shè)計或者其他你的團(tuán)隊喜歡的設(shè)計風(fēng)格嗎？
- 新的代碼中使用了什么設(shè)計模式榛瓮？這些設(shè)計模式合適嗎铺董？
- 如果代碼庫有多種標(biāo)準(zhǔn)或者設(shè)計風(fēng)格，新的代碼和當(dāng)前流行的一致嗎禀晓？代碼是向正確的方向轉(zhuǎn)移精续，還是遵循將被淘汰的舊代碼？
- 代碼是處在正確的位置粹懒？例如重付，如果代碼是和訂單相關(guān)的，它們是否處于 Order Services凫乖？
- 新的代碼有復(fù)用現(xiàn)有的代碼中的一些東西嗎确垫？新的代碼有提供一些現(xiàn)有代碼可以復(fù)用的東西嗎？新的代碼有沒有引入重復(fù)帽芽？如果有删掀，應(yīng)該重構(gòu)成更加可復(fù)用的風(fēng)格，還是這個階段也可以接受导街？
- 代碼是否過度工程化披泪？代碼有沒有創(chuàng)建現(xiàn)在并不需要的重用性？你的團(tuán)隊怎么根據(jù) YAGNI平衡考慮重用性菊匿？
可讀性和可維護(hù)性
- 字段付呕、變量、參數(shù)跌捆、方法以及類的名稱是否真實反映它們所代表的事物徽职？
- 我通過閱讀代碼能夠理解代碼在做什么事情嗎？
- 我能理解測試代碼在做什么嗎佩厚？
- 測試用例覆蓋了好的用例姆钉？測試用例覆蓋了正常場景和異常場景嗎？有沒有還沒考慮到的場景？
- 異常情況的錯誤消息好理解嗎潮瓶？
- 令人困惑的代碼段有沒有文檔描述陶冷、或者代碼注釋或者通過容易理解的測試用例覆蓋（根據(jù)團(tuán)隊喜好）？
功能性
- 代碼是在做預(yù)期的事情嗎毯辅？如果有自動測試來保證代碼的正確性埂伦，測試代碼真的是按照商定的需求來測試的嗎？
- 代碼看起來包含隱藏的 bug 嗎思恐？比如使用了錯誤的變量檢查沾谜，或者偶然使用 邏輯與 取代了 邏輯或。
你有考慮過胀莹。基跑。。描焰？
- 是否存在潛在的安全問題媳否？
- 有沒有監(jiān)管的需求要滿足？
- 對于自動化性能測試沒有覆蓋的區(qū)域荆秦，新的代碼是否引入了可以避免的性能問題篱竭，比如不必要的數(shù)據(jù)庫訪問或者遠(yuǎn)程服務(wù)訪問？
- 作者需要創(chuàng)建公共文檔嗎步绸，或者需要修改已有的幫助文件嗎室抽？
- 用戶交互信息有做過正確性檢查嗎？
- 是否存在明顯的錯誤將導(dǎo)致生產(chǎn)終止靡努？代碼是否會偶然指向測試數(shù)據(jù)庫，或者是否存在硬編碼需要在真實服務(wù)中移除晓折？
敬請期待后續(xù)文章惑朦，我們將詳細(xì)討論這些主題。
