Improved Code review.

huanlin · Apr 14, 2024 · dac7d67 · dac7d67
1 parent d138553
commit dac7d67
Show file tree

Hide file tree

Showing 2 changed files with 9 additions and 0 deletions.
diff --git a/content/en/blog/2024-04-14-code-review/images/lgtm.png b/content/en/blog/2024-04-14-code-review/images/lgtm.png
diff --git a/content/en/blog/2024-04-14-code-review/index.md b/content/en/blog/2024-04-14-code-review/index.md
@@ -42,6 +42,8 @@ Code review 可提升程式碼的品質，包括可讀性、可維護性等等
 
 於是可能出現一種情形：少量變動的 PR，容易獲得其他人的 review 建議；<mark>若 PR 變動量大到一個程度，review 建議可能就只有四個字母：LGTM。</mark>也就是 looks good to me 的意思。
 
+![](images/lgtm.png#center)
+
 然後，團隊成員可能會看到越來越多的 LGTM。至於有沒有真的看程式碼，就自由心證了。
 
 ### 合作無間
@@ -71,6 +73,13 @@ Code review 可提升程式碼的品質，包括可讀性、可維護性等等
 - This code looks like shit. (:thumbdown)
 - Rename the `PowerOff` method to `TurnPowerOff`.
 
+第一個例子很明顯，「looks like shit」是很粗魯的話，更別提如果只有簡單寫這句，毫無建設可言，那就是純粹的罵人，來找碴的。
+
+第二個例子則有可能是好的，也可能是糟糕的建議。但如果只寫那樣一句，完全不說明任何理由，便可能讓接受該評論的原作者感到不被尊重，引起一些質疑：
+
+- 「我的方法命名完全沒有違反團隊的 coding standard，為什麼一定要改成你習慣的名稱？」
+- 「平日趕進度已經很忙，很多功能和品質方面的問題都等著處理，現在竟然要花時間去討論這種無關痛癢的小地方？」
+
 Code review 是知識傳遞與彼此溝通想法的過程，其中必然有溝通的藝術成分，這點需要放在心上，以免因為忙碌而忘了基本的尊重。在提出 review 建議之前，不妨先站在對方的立場想一下他為什麼要這樣寫，而不那樣寫。如果想不到理由，或有任何不確定的地方，可以先詢問對方：
 
 「請問這段程式碼這樣寫的原因是因為 XXX 嗎？或者是其他想法？我覺得如果改成這樣....」