iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 4
0
Software Development

軟體開發隨筆談系列 第 4

為程式碼變動做出解釋

今天比較忙,時間較少,不如就簡單延續昨天的話題閒聊吧。

昨天講到〈如何導入 Code Review〉,既然講到 Code Review,就代表會有一份程式碼的變動。要請別人幫忙 Code Review,總不會是把變動丟給對方看,就開始在站在旁邊等對方了吧。

這份變動只是結果。既然有變動,總會有個原因,背後總會藏個幾個「為什麼」。為什麼要有這份變動,是來自於什麼需求或修復哪個 Bug 嗎?為什麼針對這個目的我要這樣實作呢?我想這兩個大概是最基本的。

所以在請別人 Code Review 時,要先讓對方知道這份變動的淵源,比如說附上 Issue Tracker 的連結,讓對方知道為什麼要這麼做,這樣對方才能去評估你的做法是不是最好的解法。若只是直接將解法給對方看,要求對方看懂,那 Code Review 就無法發揮最大價值,有點可惜了。

在其他 IT 鐵人參賽者 johnliutw 的文章語言的選擇與比較( 1 ) 與前言中,有看到 fx777 的一篇回覆,裡面有句話講得很好,在這邊做個引用:

工程師的工作是解決問題,其次才是寫程式。

借用這個概念。也就是說,這份變動只是為了解決問題的一個方式而已。若只是要對方看你的方式對不對,而不去跟他講是要解決什麼問題,那麼 Code Review 的重點就會變成聚焦在這個解法在技術上是否可行,而不會著重在一起思考有沒有其他更好的解法,或是這個解法有沒有辦法更好。

如果是透過程式碼託管服務提供的方法以非同步交流的方式去 Code Review(例如:Pull Request),那最好在一開始就先寫明這份變動和什麼 issue(s) 相關、是為了解決什麼問題,以及這份變動、解法大概做了哪些事。

如果是兩個人坐在一起 Code Review 那就更好了,如果你能順暢的向對方解釋上面提到的問題,以及你解法的脈絡,那通常這份變動有問題的可能就不大。如果連解釋都有困難,那可能你對自己的變動信心也不足,或是連你自己也不知道自己在做什麼。

透過思考如何解釋的過程,也能順便釐清自己的思路,或許會發現之前沒注意到的細節,並且得到更好的做法。呼應昨天的論述,透過 Code Review 讓自己與對方都真正理解這份程式碼變動吧。


上一篇
如何導入 Code Review
下一篇
我們都應該要略懂全端
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言