程式碼審查：網站或 App 擁有者為什麼需要它

您經營一個網站、一家網路商店或一個小型 App。程式碼是某個人寫的：外包廠商、朋友、早已不再合作的代理商，或是看了幾個週末教學影片的您自己。它大致上能運作，但您無法判斷它是穩固的，還是用膠帶勉強黏起來的。程式碼審查就是請沒寫過這段程式碼的人再看一次，在小問題變成昂貴的大問題之前回答這個疑問。

什麼時候值得做審查

• 在您為完成的作品付款之前。 審查能看出您拿到的程式碼是否合理，還是充滿便宜行事的寫法。
• 當您接手一個專案時。 沒有文件的舊程式碼，在有人解釋之前就是一個黑盒子。
• 當某個地方一再出問題時。 有時會失敗的表單、很慢的頁面、每次修好又出現的錯誤。
• 在上線或大型促銷之前， 這時一個錯誤就會造成實際的金錢損失。
• 當您自己寫程式， 想知道哪裡可以做得更好時。

審查會找出什麼

審查者會逐行閱讀程式碼，尋找：

• 錯誤： 在某些情況下會失敗的邏輯，例如購物車是空的、日期在月底，或名字裡有撇號。
• 有風險的地方： 寫死在程式碼裡的密碼、未經檢查就使用的使用者輸入、透露太多資訊的錯誤訊息。
• 弱點： 現在能運作，但在流量增加或函式庫更新時就會出問題的程式碼。
• 可讀性： 不清楚的命名、過長的函式和重複的程式碼，會讓日後的每次修改都更慢、更貴。

問題會依重要程度排序，讓您知道該先修什麼、什麼可以等。

審查不做的事

審查是閱讀和解釋程式碼，不會在您的伺服器上執行它，也不會測試您正在運作的網站。它不是完整的資安稽核，也不是負載測試。請把建議的修正當作提案：負責維護專案的人應該在上線前逐一測試。

如何選擇要提供的部分

很少需要整個網站。挑出最重要的部分：

• 金流經過的地方： 結帳、付款、價格和折扣。
• 使用者輸入資料的地方： 註冊、登入、聯絡和搜尋表單。
• 出問題的地方： 您看到的錯誤背後的檔案或函式。

從對的地方挑出幾百行，比把所有東西的幾千行都丟過去更能說明問題。

如何準備程式碼

• 移除機密資訊。 把密碼、API 金鑰和客戶資料換成像 PASSWORD_HERE 這樣的預留文字。
• 註明程式語言和版本， 例如 PHP 8 或使用 React 的 JavaScript。
• 用一兩句白話說明程式碼應該做什麼。
• 完整複製確切的錯誤訊息， 如果有的話。
• 說明要著重在哪裡： 錯誤、速度、可讀性或有風險的地方。

如何運用審查結果

把審查結果分享給負責維護程式碼的人，並約定修正的順序，從最嚴重的開始。如果您自己不懂技術，白話的摘要能幫助您問對問題，並判斷對方的回答。

重點整理

程式碼審查是一次獨立的檢視，能在客戶發現之前找出錯誤、有風險的地方和弱點。如果您需要審查，可以訂購程式碼審查：您貼上最多 100、400 或 1,000 行程式碼，並描述出了什麼問題，就能拿到一份書面說明，包括程式碼的作用、依重要程度排序的問題清單，以及可以在您自己的專案中測試的修正片段。只有在您驗收作品後才會撥付款項。