淺談 Code-Review
淺談 Code-Review 前言 最近，有些朋友也在談論 Code-Review 以及 Code-Review 所遭遇到的困難等，今天我就來談談我自己對 Code-Review 的一些初淺的看法。 近年來我在各中小型企業執行顧問工作，有 API Framework 客製化的框架開發、也有 Redis 導入工作、也有日常維護（專案開發技術顧問角色/Trouble-Shooting/專案軟體架構設計角色/單元測試顧問/教育訓練.../etc），而不管我執行哪一種工作，協助解決 Bug 也好，很多時候的第一件事就是與該團隊成員一起 Code-Review，先來看看程式碼，了解出現問題的 Source Code，這是再稀鬆平常不過的事情了，今天，我就來分享我在各大企業，許多團隊實際進行顧問時的 Code-Review 所看到的一些現象，並分享給各位。 實務上 Code-Review 以我個人的經驗我覺得可以區分為以下兩種： 非正式的 Code-Review： 什麼叫做『非正式的 Code-Review』呢？以往，我在帶團隊做專案時，不管是我與同仁 pair-programming 時，或者相互討論需求時，我們會同時進行 Code-Review，這時你會說這也算？對!!! 我認為，當然算，當然有些決議會記錄下來在下一次正式討論時與團隊同步，但是我個人非常重視這個過程，而且這些討論一樣是在『有團隊開發共同規範的基礎下』進行的。這些通常在位子上就可以進行。 非正式的 Code-Review 其實也有己的進入點（其實非正式場合我不建議用 Code-Review 做為內容表達方式，一來讓人覺得它就是要來噹我的會議、二來就是有犯了什麼錯，所以準備被指正等。） 1). 當 Junior 工程師對需求有問題時 2). 當 Commit 的 Source 或 Pull 下來的 Source 有問題時 3). Merge 出錯時 以上 3). 點我統一說明，非正式場合不建議大費周章發會議通知 + 找所有人一起參與，一來花費過多時間也沒有效率，專案開發是分秒必爭的，本來就不建議有過多的浪費（敏捷也告訴我們要減少浪費）使用最少的資源，與該需求相關人等討論即可，甚至在位子上花 10-20 分即可進行，我個人是建議不要超過 30 分鐘。 Merge 出錯通常可能點出另一種問