嵌入式軟件 Code Review 的錯誤實踐

嵌入式專欄

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

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

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



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

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