前言
你是否曾在前端與後端之間遊走，身兼多職？過去三年，我雖以後端工程師之名，卻肩負前端 Code Review 的重任。如今，前端團隊人力充沛，我終於得以卸下這份責任。回顧這段旅程，我從中學到了什麼？這篇文章將分享我的經驗與心得，帶你一探前後端協作的獨特視角。
後端協助前端 Review 的原因
為何後端工程師會負責前端 Code Review？這得從我的入職故事說起。
我應徵的職位是「前端軟體工程師」，歷經一面技術對談、二面實作考核、三面高層面談，幸運獲得錄取。入職時，團隊已有四人：一位前端與三位後端。當時後端人力吃緊，恰好我有後端經驗，便被安排支援後端，負責開發 Web 後端與定義 API，滿足前端功能需求，這也促成我從前端轉向後端的契機。
公司推崇 Code Review 文化，每項程式碼產出皆需經他人審查。起初，前端 Review 由主管負責，但隨著主管業務繁忙，無暇兼顧，這份重擔最終落在我這位「前前端工程師」肩上。
後端協助前端 Review 的好處
Code Review 本身的價值可參考：程式碼審查 (Code Review) 的重要性與最佳實踐，本文將聚焦於後端參與前端 Review 為前端、後端及整個團隊帶來的獨特優勢。
對前端的好處
API 由後端實作，後端工程師在開發過程中更能預見潛在的錯誤情境，例如 503 Service Unavilable。透過參與前端 Code Review，後端可確認前端是否妥善處理這些邊界情況，同時確保前端對 API 的理解無誤，從而提升前端程式碼品質與穩定性。
對前後端雙方的好處
網頁服務開發中，前後端以 API 為橋樑，但雙方對同一份 API 的解讀常因 Codebase 或經驗差異而不同。若有人熟悉前後端實作細節，便能扮演溝通橋樑，整合雙方觀點，提出兼顧兩端的解決方案，促進更順暢的協作。
對團隊的好處
熟稔前後端程式碼意味著掌握系統全貌。一旦產品出現問題，這份全局視野能快速定位問題根源，甚至精準指出是前端或後端的哪段程式碼有誤。這不僅降低 Debug 難度，也為團隊節省可觀的營運成本。
後端協助前端 Review 的壞處
前端新功能開發往往改動幅度不小。例如，最近一項功能涉及 108 個檔案、7000 行程式碼變更，完整 Review 一輪需耗費 9 個工作天，且不包含後續討論、修改與再審查的時間。更極端的案例是一次功能改動高達 13000 行，耗時更甚。
如此長時間的 Review 對後端而言，形同人力被抽調，可能加重其他後端同仁的負擔。正如 Giray Özil 幽默所述：
Ask a programmer to review 10 lines of code, he'll find 10 issues. Ask him to do 500 lines and he'll say it looks good.
大規模改動易導致 Review 品質下滑，這是後端參與前端 Review 的一大挑戰。
Code Review 需投入大量心力與時間。我習慣逐行審查，挖掘潛在問題，這份細緻或許是 Review 耗時的關鍵。
兩層 Review
近一年來，前端團隊陸續迎來新成員，目前已有四位前端工程師。我們的開發流程為：前端完成程式碼後先互相 Review，待功能開發完畢並通過內部 Review 後，再由我進行第二層審查。此流程旨在讓前端同仁學習 Review 技巧，同時透過我的二次審查，提醒他們忽略的細節，逐步提升 Code Review 能力。
決定放手的理由
後端協助前端 Review 雖有諸多優勢，但這份職責最初僅因前端人力不足而由我暫代。如今，兩層 Review 流程已運行一年，前端團隊的 Review 能力日趨成熟，是時候讓他們獨立承擔這份責任，回歸自主運作！
結語
入職時的特殊情境，讓我從前端工程師「意外」轉為後端，但這三年協助前端 Review 的經歷，卻讓我深入理解前後端協作的精髓。未來，我期盼前端團隊能自信運行 Review 流程，而我也能將這份經驗帶入新挑戰。若你也身處前後端交錯的環境，不妨換個視角審視彼此的程式碼，或許會發現意想不到的火花！
