昨天我們聊到當時組織在程式碼控管的狀況其實等於沒有控管，而我們也討論團隊是怎麼做之後，下一步就是程式碼的審查作業了，而團隊是怎麼處理這件事情的呢~

就讓我們接下來看：

Situation

團隊長期以「能跑就好」為導向，需求急、交付快，但缺少系統化管理的品質門檻。常見問題包括：

• 外包程式是直接由外包廠商修改，IT 因不瞭解使用的程式語言，也無明確 code diff，因此並沒有做任何程式碼檢查。
• 內部開發的程式修改都是單人作業，彼此不清楚其他人的程式，也沒有進行任何檢查。
• 缺乏一致風格，重複 Bug 反覆出現，知識流程被鎖在個人腦中。
• 緊急修補直接推上主線，沒人第二雙眼睛檢視；事故追溯困難。

Task

目標不是為了「卡進度」，而是把「品質、知識傳承、風險控管」內建進交付流程。
所以團隊在程式碼審查上有了以下任務：

• 制定程式碼交付標準
• 所有線上程式碼都通過程式碼審查（code review）。
• 把培力與文化寫進流程：讓 Code Review 成為跨層級的教學現場，而非「找碴現場」。

Action

• 當有了昨天談到的版控後，要進行程式碼審查的導入就比較容易了，這時候所有的異動都可以在 code diff 中看到，也能夠讓團隊有討論的依據。
• 這時也建立起標準 PR Template，使審查的工程師更易於了解需求背景。
• 再來是 PR merge 之前必須要審查通過。
• 不過如一開始所說的，因為 IT 並不具備部分的程式語言的開發能力，因此程式碼審查在一開始推動的時候形式的意義大於實質產出。當程式技術棧整合之後，團隊也已經熟悉程式碼審查的概念，真正的程式碼審查就自然而然的發生了。

Result

• 程式碼審查除了確保上線的程式碼有第二雙眼睛看過，增進程式碼的品質和穩定度。同時也提供同儕彼此分享與學習討論的場景。
• 開發人員可以彼此討論出最佳做法，也逐漸從中形成大家共同的程式風格（coding style）。
• 團隊所形成的程式風格在新成員加入時，也能夠進一步加速新成員上手的時間。

以上，對於團隊的程式碼產出，團隊管理者從「程式碼控管」與「程式碼審查」著手，並且也產出了成效
但還有一個重要的部分就是「測試」了。
這部分我們明天再來談囉~