嵌入式軟件 Code Review 的錯(cuò)誤實(shí)踐

嵌入式專欄

關(guān)注+星標(biāo)公眾號(hào)，不錯(cuò)過(guò)精彩內(nèi)容

來(lái)源 | 網(wǎng)絡(luò)code review，即代碼審查、檢查、評(píng)審等。軟件工程的code review是一項(xiàng)十分重要的評(píng)審工作，然而在日常的軟件開(kāi)發(fā)工作進(jìn)行code review的時(shí)候，我發(fā)現(xiàn)團(tuán)隊(duì)成員有時(shí)候可能會(huì)固守某些實(shí)踐經(jīng)驗(yàn)。然而這些實(shí)踐經(jīng)驗(yàn)對(duì)于整個(gè)軟件項(xiàng)目來(lái)說(shuō)，可能是錯(cuò)誤的。分享這些我認(rèn)為是錯(cuò)誤的實(shí)踐經(jīng)驗(yàn)，歡迎大家一起討論。

圖片來(lái)源公眾號(hào)：碼農(nóng)翻身什么時(shí)候都一定要做Code ReviewCode Review是否一定有必要呢？我的答案是不一定，我覺(jué)的需要分時(shí)間，分項(xiàng)目。在公司創(chuàng)業(yè)之始，1，2兩個(gè)人吭哧吭哧的把整個(gè)產(chǎn)品從0到1的搭建出來(lái)，Code Review既沒(méi)有條件（沒(méi)有別人可以review），也沒(méi)有必要，將產(chǎn)品實(shí)現(xiàn)，讓項(xiàng)目活下來(lái)才是最重要的。在線上出了Bug，分分鐘損失成百上千的時(shí)候，顯然以救急為主，等Code Review黃花菜都涼了。當(dāng)然這里分情況，如果是非常顯而易見(jiàn)的bug，比如你非常確定是一個(gè)條件寫反了，那么不用廢話趕緊上。如果這個(gè)修改不那么輕巧，那么多一雙眼睛看一遍往往會(huì)大大降低再次引入bug的幾率。Code Review主要是用來(lái)讓別人檢查Bug的將Code Review視為別人替自己檢查Bug的手段，可能代表了相當(dāng)一部分程序員的想法。在Code Review中查錯(cuò)確實(shí)是一個(gè)重要的目的，但并不應(yīng)該成為唯一的目的。除了檢查Bug，Code Review還是：1. 維持代碼質(zhì)量、統(tǒng)一代碼風(fēng)格的手段。每個(gè)人的技術(shù)能力，背景各不相同，放任自由的發(fā)揮可以寫出很多質(zhì)量不同，風(fēng)格迥異的代碼。通過(guò)Code Review，可以迫使大家將代碼質(zhì)量維持在大家都可以接受的程度，并且是的項(xiàng)目的代碼風(fēng)格盡量統(tǒng)一。2. 一個(gè)互相學(xué)習(xí)的過(guò)程。對(duì)于初學(xué)者，我們可以指出其代碼中的風(fēng)格、設(shè)計(jì)等方面的不足，可以直接“教育”別人該怎么寫代碼。反過(guò)來(lái)，在Review別人的代碼時(shí)，我們也可以學(xué)習(xí)作者是怎么寫代碼的，如何調(diào)用的API，用到了哪些設(shè)計(jì)模式。不僅新手可以向老鳥(niǎo)學(xué)習(xí)，老鳥(niǎo)們也有很多機(jī)會(huì)向新手們學(xué)習(xí)。我就是通過(guò)Review畢業(yè)的同事的代碼學(xué)些的Java的JOOQ框架。3. 一個(gè)了解同事工作內(nèi)容的機(jī)會(huì)。程序員平時(shí)可能會(huì)比較關(guān)注在自己的開(kāi)發(fā)任務(wù)上，而自己的同事正在做什么，怎么做，這些信息通過(guò)Code Review可以最直觀的了解。比如你的同事可能需要和你改同一個(gè)文件，這樣你可以知道他改的思路，可以避免在代碼合并之前產(chǎn)生沖突。初級(jí)工程師的代碼需要檢查Bug，高級(jí)工程師的代碼不需要檢查Bug很多時(shí)候，對(duì)于初級(jí)工程師的代碼，大家都會(huì)很踴躍的去review，并且會(huì)有以找到代碼中的Bug而顯示自己的“資深”的榮耀。但是對(duì)于高級(jí)工程師寫的代碼，要么人家根本不給你建Code Review，要么即使把你加到Code Review里，也礙于自己的地位不敢去提意見(jiàn)�；蛘叽蠹叶紝�(duì)高級(jí)工程師給予了充分的信任，對(duì)于他們建立的Code Review請(qǐng)求都不怎么仔細(xì)看，直接LGTM（Looks Good To Me）。然而這是不對(duì)的， 初級(jí)工程師寫小bug，高級(jí)工程師寫要命的bug。初級(jí)工程師做的任務(wù)也比較初級(jí)，而高級(jí)工程師做的任務(wù)也會(huì)比較重要。如果你去關(guān)注一下公司的重大生產(chǎn)環(huán)境事故，事故的引起者是高級(jí)工程師的可能性遠(yuǎn)遠(yuǎn)大于初級(jí)工程師。這和“出車禍的都是老司機(jī)”，“淹死的都是會(huì)游泳的”的道理一樣，“高級(jí)”工程師由于專注于高屋建瓴的設(shè)計(jì)，反而有可能忽視了代碼中的細(xì)節(jié)。同時(shí)“高級(jí)”工程師對(duì)于自身的技術(shù)信心較足，往往會(huì)忽視一些基本的自我測(cè)試等環(huán)節(jié)。所以不論初級(jí)，高級(jí)工程師寫的代碼，Code Review都是必要的，只是側(cè)重點(diǎn)可能會(huì)不同。在檢查Bug這件事上，我們?cè)趹?zhàn)略上相信同事，戰(zhàn)術(shù)上要懷疑同事。Code Review提的問(wèn)題越多越好我在工作中遇到過(guò)一些這樣的“Code Review噴子”，同事提交了一段100行不到的代碼，被洋洋灑灑的提了十幾二十處問(wèn)題。同事對(duì)在有些問(wèn)題上回復(fù)了一下自己的意見(jiàn)，雙方就一些蘿卜白菜的問(wèn)題蓋了十幾層高樓。結(jié)果兩三天過(guò)去了，論戰(zhàn)還在進(jìn)行。我曾經(jīng)在被這樣“猛烈”的Code Review轟炸中，為了讓所有的Reviewer都高興，前后更改數(shù)十次，每次修改都有不同的同事提出各種各樣的意見(jiàn)。并且最后關(guān)頭為了一個(gè)設(shè)計(jì)上的分歧，將代碼進(jìn)行了大的重構(gòu)，最終終于被接受（Accept）。然而代碼合并之后卻出現(xiàn)了低級(jí)的Bug，回頭查了一下，正是最后一次的大重構(gòu)引入了這個(gè)bug。為什么會(huì)出現(xiàn)這樣的結(jié)果呢？一個(gè)Code Review進(jìn)行的時(shí)間越長(zhǎng)，Author的耐心越來(lái)越差，Reviewer也越來(lái)越只關(guān)注他們“希望”你做出的改變，反而屬于撿了芝麻丟了西瓜。如果一個(gè)Code Review中的提交太多，對(duì)于review過(guò)程是不利的。每個(gè)Reviewer的記憶是有限的， 可能只能記得第一二次代碼的修改。如果一次Code Review中出現(xiàn)多個(gè)提交，審閱最新的提交則會(huì)喪失之前的上下文，則會(huì)出現(xiàn)我上面遇到的問(wèn)題。我們做Code Review的目的并不是追求完美的Code，世界上沒(méi)有完美的Code，任何代碼片段，只要足夠長(zhǎng)，都可以有可改進(jìn)的地方。每個(gè)人心中的完美代碼各不相同，有的人喜歡這樣寫，有的人喜歡那樣寫。在不違反前面說(shuō)的代碼質(zhì)量、統(tǒng)一風(fēng)格的基礎(chǔ)上，應(yīng)該遵守“誰(shuí)寫代碼誰(shuí)做主”的原則。來(lái)源：https://www.cnblogs.com/chaosyang/p/code-review-wrong-practices.html------------ END ------------



●專欄《嵌入式工具》
●專欄《嵌入式開(kāi)發(fā)》
●專欄《Keil教程》
●嵌入式專欄精選教程

關(guān)注公眾號(hào)回復(fù)“加群”按規(guī)則加入技術(shù)交流群，回復(fù)“1024”查看更多內(nèi)容。
點(diǎn)擊“閱讀原文”查看更多分享。