Code Reivew的目的是為了使所有代碼的代碼健康得到改善（代碼健康是指代碼的可維護(hù)性六孵，可閱讀性次乓，穩(wěn)定性及簡(jiǎn)潔性）磷雇。所有的工具魄幕，流程都是為此目的而設(shè)計(jì)的。
為了達(dá)到這一目的，我們必須權(quán)衡取舍姜凄。
首先政溃，開發(fā)人員必須針對(duì)改善代碼而有所行動(dòng)，畢竟如果你從來不去改善代碼态秧，則代碼基永遠(yuǎn)不會(huì)得到改善董虱。同時(shí)，評(píng)審員如果使任何變更都很難以被批準(zhǔn) ,則開發(fā)者以后就不會(huì)去改善代碼了申鱼。
另一方面愤诱，評(píng)審員有責(zé)任去保證每一次提交列表(CL)沒有降低整個(gè)代碼庫(kù)的代碼健康。這很棘手捐友，因?yàn)榇a庫(kù)整體的健康程度的下降是由于經(jīng)常性的一小部分代碼質(zhì)量下降積累而致的淫半。特別是當(dāng)一個(gè)團(tuán)隊(duì)在重大的時(shí)間限制下，他們覺得必須走捷徑以實(shí)現(xiàn)他們的目標(biāo)匣砖。
此外科吭，評(píng)審員對(duì)他們審查的代碼擁有所有權(quán)和責(zé)任。他們希望確保代碼庫(kù)保持一致猴鲫、可維護(hù)对人，以及“Code Review應(yīng)該Review什么”中提到的所有其他內(nèi)容。
因此变隔，我們得到了以下規(guī)則作為我們?cè)诖a審查中期望的標(biāo)準(zhǔn):
一般來說规伐，代碼審查者應(yīng)該通過那些絕對(duì)能提高代碼健康的但是并不完美的提交列表(CL).
這是所有代碼審查指南中的高級(jí)原則。
當(dāng)然匣缘，這是有限制的猖闪。例如，如果CL添加了評(píng)審員不希望在其系統(tǒng)中使用的功能肌厨，那么即使代碼設(shè)計(jì)良好培慌，評(píng)審員也可以拒絕批準(zhǔn)。
這里的一個(gè)關(guān)鍵點(diǎn)是柑爸，沒有所謂的“完美”代碼吵护，只有更好的代碼。評(píng)審員不應(yīng)該要求作者在批準(zhǔn)之前對(duì)CL的每一個(gè)微小部分進(jìn)行打磨表鳍。相反馅而，評(píng)審員應(yīng)該權(quán)衡取得進(jìn)展的需要和他們所建議的變更的重要性。評(píng)審員不應(yīng)該追求完美譬圣，而應(yīng)該追求持續(xù)改進(jìn)瓮恭。作為一個(gè)整體，提高系統(tǒng)的可維護(hù)性厘熟、可讀性和可理解性的CL不應(yīng)該因?yàn)樗皇恰巴昝赖摹倍七t幾天或幾周屯蹦。
評(píng)審員總是可以自由地留下評(píng)論维哈，表示某些東西可能會(huì)更好，但是如果它不是很重要登澜，可以在前面加上“Nit:”這樣的前綴阔挠，讓作者知道這只是一種修飾，他們可以選擇忽略脑蠕。
注意:在本文檔中购撼，沒有任何內(nèi)容證明檢入會(huì)明顯地惡化系統(tǒng)的整體代碼健康狀況的CL是合理的。只有在“緊急情況”下你才會(huì)這么做谴仙。
指南
代碼評(píng)審的一個(gè)重要功能是向開發(fā)人員傳授有關(guān)語(yǔ)言份招、框架或一般軟件設(shè)計(jì)原則的新知識(shí)。留下有助于開發(fā)人員學(xué)習(xí)新東西的評(píng)論總是好的狞甚。隨著時(shí)間的推移，共享知識(shí)是改善系統(tǒng)代碼健康狀況的一部分廓旬。請(qǐng)記住哼审，如果您的評(píng)論純粹是教育性的，但對(duì)于滿足本文檔中描述的標(biāo)準(zhǔn)不是至關(guān)重要的孕豹，請(qǐng)?jiān)谇懊婕由稀癗it:”或以其他方式表明作者不必在本CL中解決它涩盾。
- 技術(shù)事實(shí)和數(shù)據(jù)壓倒了意見和個(gè)人偏好。
- 在風(fēng)格方面励背，風(fēng)格指南是絕對(duì)權(quán)威春霍。任何沒有在樣式指南中的純樣式點(diǎn)(空格等)都是個(gè)人偏好的問題。風(fēng)格應(yīng)該與現(xiàn)有的一致叶眉。如果沒有以前的風(fēng)格址儒，那就接受作者的風(fēng)格。
- 軟件設(shè)計(jì)的各個(gè)方面幾乎從來都不是純粹的風(fēng)格問題或個(gè)人偏好衅疙。它們是建立在基本原則基礎(chǔ)上的莲趣，應(yīng)該以這些原則為依據(jù)，而不是簡(jiǎn)單地以個(gè)人觀點(diǎn)為依據(jù)饱溢。 有時(shí)有一些有效的選項(xiàng)喧伞。如果作者能夠證明(通過數(shù)據(jù)或基于可靠的工程原理)幾種方法是同樣有效的，那么評(píng)審員應(yīng)該接受作者的偏好绩郎。否則潘鲫，選擇取決于軟件設(shè)計(jì)的標(biāo)準(zhǔn)原則。
- 如果沒有其他規(guī)則適用肋杖，那么評(píng)審員可以要求作者與當(dāng)前代碼庫(kù)中的內(nèi)容保持一致溉仑，只要這不會(huì)惡化系統(tǒng)的整體代碼健康狀況。
解決分歧
在代碼評(píng)審的任何分歧中兽愤，第一步總是讓開發(fā)人員和評(píng)審員根據(jù)本文檔的內(nèi)容和CL作者指南和評(píng)審員指南中的其他文檔達(dá)成一致彼念。
當(dāng)達(dá)成一致意見變得特別困難時(shí)挪圾，通過評(píng)審員和作者之間進(jìn)行一次面對(duì)面的會(huì)議或視頻會(huì)議來解決分歧，而不是試圖通過Code Review的評(píng)論來解決逐沙。(如果您這樣做了哲思，請(qǐng)確保將討論的結(jié)果記錄在CL的評(píng)論中，以供將來的讀者參考吩案。)
如果這還不能解決問題棚赔，最常見的解決方法就是升級(jí)。通常情況下徘郭，升級(jí)的途徑是更廣泛的團(tuán)隊(duì)討論靠益，讓TL參與進(jìn)來，請(qǐng)求代碼維護(hù)者做出決定残揉，或者請(qǐng)求經(jīng)理提供幫助胧后。不要因?yàn)樽髡吆驮u(píng)審員不能達(dá)成一致意見而讓CL懸而未決。
