Alan Tsai 的學習筆記


學而不思則罔,思而不學則殆,不思不學則“網貸” 記錄軟體開發的點點滴滴 著重於微軟技術、網頁開發、DevOps、C#, Asp .net Mvc、Azure、AI、Chatbot、Docker、Data Science

[01]讓團隊彼此知道程式碼走向 - 淺談Code Review的好處及意義篇

2019-05-05 Sunday
[01]淺談Code Review的好處及意義篇 - 讓團隊彼此知道程式碼走向.jpg
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/、https://www.freepik.com/free-photo/magnifying-glass-stock-market-graph-paper_3095564.htm

程式碼對於工程師來説,就像是自己的小孩一樣,要時常的關心它,如果不怎麽做很容易導致長歪。

當程式碼還只是自己維護的情況下,掌控肯定很高,畢竟只有自己在開發而已,但是當是一個團隊在開發的時候,怎麽掌控或者知道走向就變的很重要。

這也就是Code Review的主要目的,這篇來看一下爲什麽要做code Review,Code Review要看什麽,以及有什麽工具可以協助這一件事情。

Code Review是什麽?

當我們在寫文章的時候,會請專門人員來校稿一樣,Code Review是一樣的概念。

當程式碼針對某一個功能/問題修正了之後,請另外一位工程師協助看看程式碼是否有任何問題,這就是Code Review。

Code Review有什麽好處,應該做嗎?

執行Code Review有一些好處:

團隊凝聚力更高

由於當有任何修改要上的時候,會請其他工程師互相review程式碼,因此大家更清楚程式碼走向

換句話説,凝聚力會更加的高,因爲彼此知道修改了什麽。

知識共享

要達成一個功能有很多種不同的寫法,但是很有可能有些寫法比較簡潔,或者更優化,這個時候透過review可以讓工程師知道這個事情。

舉例來説,開發一定有自己的框架,很有可能某些功能框架已經有提供,但是另外一個使用者不知道。

透過review告訴他,那麽不止程式碼更一致,未來也更清楚知道怎麽寫更好。

因此,達到了知識共享的目的。

程式碼的一致性更高

每個人有不同的開發習慣,但是團隊一定會有制定整個團隊的習慣。

透過Code Review可以互相提醒,讓整體程式碼一致性更好。

從上面幾個好處,可以發現到,code review真的是一個可以讓團隊以及程式碼更加好的一個流程。這個也可以從Stack Overflow 2019的問卷調查看的出來:


快7成的工程師認爲Code Review有價值。來源:https://insights.stackoverflow.com/survey/2019#work-_-code-review

但是他的壞處是什麽?

Code Review的壞處是什麽?

好處不可能都全占,那麽如果今天要在團隊做Code Review的壞處是什麽?

很簡單,就是需要花時間。換句話説,會增加團隊的開發成本

因爲開發完了,要請另外一個工程師來看,那麽那個工程師看的過程就是一個額外需要花時間的地方。

那到底會花多少時間呢?

同樣是Stack Overflow 2019 的報告,這項調查詢問每一個禮拜平均在Code Review花的時間:


平均每一個禮拜花的時間。來源:https://insights.stackoverflow.com/survey/2019#work-_-code-review

從上面可以看到,大約3/4的人每一個星期至少需要花不超過5小時的時間來做code review。

以我自己的經歷來説,我至少每一個禮拜需要花至少6個小時在Code Review這件事情 - 甚至有可能更多。

不過個人覺得這個時間是值得的。

Code Review要看什麽?

如果說,團隊覺得Code Review是值得投資的一件事情,那麽,下一個問題就是,Code Review到底要看什麽?

第一個想到的可能是,看看功能是否有運作正常,例如是否有修復好bug或者有把功能開發正確。但是實際上Code Review一般不是用來找defect。

有研究指出15%的code review是找到可能的bug,但是實際上50%相關的comment都是和程式碼的可維護性(maintainability)有關係。

Code Review怎麽加速?

知道Code Review在看什麽之後,爲了減少Code Review要花的時間,那麽怎麽樣能夠讓Code Review花的時間減少呢?

Reviewer要知道修改的目的是什麽

首先,如果Reviewer對於要Review的功能不清楚,那麽花的時間就會比較久。

因此,每一個修改對應的Ticket裡面的DoD (Definition of Done)寫的好不好很重要。

使用好的工具 - Pull Request

在Review的過程一定會需要針對某段程式碼進行comment,然後原開發者經過修改之後,會有新的update

這些部分好的工具應該可以讓Reviewer容易做到,而Pull Request就是這麽一個好用的工具。

下一篇會有詳細介紹pull request
每一次Review只要包含一個功能

這個和git裡面提到的原則一樣,每一個commit只應該有一個相關的修改。

同樣道理,要review的每一段,都應該只有一個相關修改。

在之後的篇幅將會介紹,如果包含多個修改,爲什麽會導致review要更花時間。

結語

這篇介紹了,什麽是Code Review,Code Review的好處/壞處,以及如果要做Code Review要看什麽以及如何加速。

如果看完了這篇,決定想要在公司開始code review這件事情,那麽有個好工具可以讓您上天堂。

在下一篇(何爲Pull Request並且如何建立 - 以Azure DevOps爲例)將來介紹工具的部分,也就是所謂的Pull Request。

看看什麽是PUll Request,怎麽建立,並且使用在Code Review。

參考資料

微軟關於Code Review這件事在看什麽
Code reviews are not (primarily) for finding bugs

如果文章對您有幫助,就請我喝杯飲料吧
街口支付QR Code
街口支付QR Code
台灣 Pay QR Code
台灣 Pay QR Code
Line Pay 一卡通 QR Code
Line Pay 一卡通 QR Code
街口支付QR Code
支付寶QR Code
街口支付QR Code
微信支付QR Code
2019-05-05 Sunday
comments powered by Disqus