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

昨天講到〈如何導入 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 讓自己與對方都真正理解這份程式碼變動吧。