概述

代碼審查有時(shí)會(huì)讓人覺得有點(diǎn)乏味。但是它們對(duì)于創(chuàng)建工作良好、易于使用并且不會(huì)引起安全問題的PHP應(yīng)用程序來說是絕對(duì)必要的。好消息呢？有一種方法可以使代碼審查有效。讓我們分解一下在審查PHP代碼時(shí)要尋找的關(guān)鍵內(nèi)容。

核心原則

1. 功能檢查：代碼是否完成了它的工作？

代碼審查最重要的方面是確保代碼實(shí)現(xiàn)了其預(yù)定目的。重點(diǎn)關(guān)注代碼邏輯，從接收輸入到產(chǎn)生輸出的執(zhí)行流程。檢查是否有不合邏輯的步驟、錯(cuò)誤的計(jì)算，或者流程可能會(huì)意外停止的地方。

• 檢查輸入：代碼是否正確處理了它可能接收到的所有類型的數(shù)據(jù)？這包括用戶輸入、數(shù)據(jù)庫數(shù)據(jù)或來自外部系統(tǒng)的信息。
• 檢查輸出：驗(yàn)證代碼產(chǎn)生的結(jié)果是否正確，并且格式符合預(yù)期。輸出數(shù)據(jù)是否符合要求？

徹底的測(cè)試是確保功能的關(guān)鍵。單元測(cè)試幫助我們系統(tǒng)地檢查具有不同輸入變量的代碼的各個(gè)組件，確保代碼在所有情況下都按預(yù)期運(yùn)行。

在這個(gè)步驟中，我發(fā)現(xiàn)能夠?qū)⒋a發(fā)布到審查應(yīng)用程序或暫存服務(wù)器，并確認(rèn)我在代碼審查中的發(fā)現(xiàn)及其實(shí)際工作方式是很有幫助的。對(duì)于棘手的部分，我也傾向于搜索添加的單元測(cè)試。如果它們丟失了，請(qǐng)作者添加它們可能是一個(gè)好主意。

2. 代碼功能：是否按設(shè)計(jì)工作？

在一個(gè)可靠的代碼審查的核心，我們需要回答一個(gè)基本的問題：這些代碼做了它應(yīng)該做的事情嗎？開始直接將代碼與項(xiàng)目的需求或規(guī)范進(jìn)行比較。您是否已實(shí)現(xiàn)所有必要的功能？是否有不正確的行為或缺少任何東西？接下來，仔細(xì)地逐步執(zhí)行代碼的邏輯。執(zhí)行是否遵循從接收到的輸入到最終輸出的合理路徑？尋找任何無意義的分支（比如總是為假的if語句）、無限循環(huán)或潛在的崩潰。

檢查代碼如何處理所有形式的輸入。它是否可以處理不同的用戶條目、從數(shù)據(jù)庫中提取的各種數(shù)據(jù)，或者來自另一個(gè)系統(tǒng)的信息？同樣重要的是，輸出是否正確，格式是否正確，并與應(yīng)用程序的其他部分預(yù)期的內(nèi)容保持一致？

技術(shù)提示：不要只是通過點(diǎn)擊應(yīng)用程序來測(cè)試。雖然開發(fā)人員承擔(dān)編寫單元測(cè)試的主要責(zé)任，但不要低估在代碼審查期間批判性眼光的價(jià)值。

• 缺少測(cè)試：是否存在沒有相應(yīng)單元測(cè)試的代碼塊？
• 邊緣用例：測(cè)試是否只覆蓋預(yù)期的場(chǎng)景，還是包括意外的輸入和邊界條件？
• 測(cè)試質(zhì)量：測(cè)試是否寫得很好，它們是否清楚地聲明了預(yù)期的結(jié)果？

在檢查時(shí)，想象一下用戶可能故意（或意外）嘗試破壞代碼的方式。你能給它輸入奇怪的輸入，引起不尋常的事件序列，或者使它過載嗎？彈性代碼應(yīng)該優(yōu)雅地處理這些場(chǎng)景。熟練使用像Xdebug這樣的調(diào)試工具。它允許您暫停代碼執(zhí)行，逐行單步執(zhí)行，并在事情發(fā)生變化時(shí)仔細(xì)檢查變量的值。對(duì)于前端代碼，我喜歡考慮可能出現(xiàn)的不同UI狀態(tài)。

一些關(guān)鍵的狀態(tài)包括空狀態(tài)，加載狀態(tài)和錯(cuò)誤狀態(tài)，但重要的是要進(jìn)一步：

• 部分加載狀態(tài)：數(shù)據(jù)在逐步加載時(shí)如何顯示？UI的不同部分是否有清晰的加載指示器？
• 輸入驗(yàn)證狀態(tài)：UI如何立即傳達(dá)表單驗(yàn)證的成功或失敗（例如，內(nèi)聯(lián)錯(cuò)誤消息）？
• 成功狀態(tài)：在一個(gè)動(dòng)作之后（例如，提交一份表格），成功是如何傳達(dá)的？
• 交互狀態(tài)：元素是否提供懸停、聚焦或活動(dòng)狀態(tài)的視覺反饋？

3. 代碼可讀性：你能讀懂它嗎？

可讀的代碼對(duì)于可維護(hù)性和協(xié)作是必不可少的。讓我們把重點(diǎn)放在使您的代碼易于人類和機(jī)器解析。從嚴(yán)格遵守PSR-1和PSR-12等編碼標(biāo)準(zhǔn)開始。這些標(biāo)準(zhǔn)為PHP代碼建立了一種通用語言，定義了縮進(jìn)、命名約定、文件組織等規(guī)則。

通過遵循標(biāo)準(zhǔn)，您的代碼變得可預(yù)測(cè)和一致，減少了閱讀者的認(rèn)知負(fù)擔(dān)。PSR等社區(qū)標(biāo)準(zhǔn)最大限度地減少了新加入項(xiàng)目的開發(fā)人員的學(xué)習(xí)曲線，并提高了與不同開發(fā)工具的兼容性。

在代碼審查期間，仔細(xì)評(píng)估變量和函數(shù)命名。這些名稱是否清楚地表達(dá)了它們的目的，避免了單字母變量、不必要的縮寫或模糊的術(shù)語？命名良好的元素有助于自文檔化的代碼，最大限度地減少了對(duì)解釋性注釋的需求。如果有注釋，它們是否專注于解釋邏輯或設(shè)計(jì)選擇背后的“為什么”，而不是簡(jiǎn)單地重復(fù)代碼的功能？

如果代碼感覺很復(fù)雜，建議作者重構(gòu)。這可能涉及提取方法，使用更具描述性的變量名，或?yàn)榍逦鹨娭匦聵?gòu)造代碼塊。強(qiáng)調(diào)長(zhǎng)期可維護(hù)性的重要性，即使目前需要一些額外的努力。

使用鏈接器（如PHPCS）和靜態(tài)分析工具（如PHPStan）作為審查過程的一部分。這些工具有助于執(zhí)行標(biāo)準(zhǔn)，捕捉潛在的問題，并促進(jìn)一致的可讀性。尋找代碼和已建立的標(biāo)準(zhǔn)之間的不匹配，作為潛在的改進(jìn)領(lǐng)域。

如果您發(fā)現(xiàn)自己在評(píng)審過程中很難理解代碼流，這就強(qiáng)烈地表明將來的可維護(hù)性將是一個(gè)挑戰(zhàn)。不要猶豫，向作者提出這一點(diǎn)-合作討論往往可以發(fā)現(xiàn)更好的解決方案或澄清潛在的邏輯。

除了格式和命名，嚴(yán)格遵守項(xiàng)目或公司特定的編碼規(guī)則。這些內(nèi)容涵蓋了命名空間、代碼組織和架構(gòu)模式等方面。雖然自動(dòng)化工具可以捕獲許多違規(guī)行為，但在審查過程中要保持警惕，以發(fā)現(xiàn)工具可能遺漏的潛在問題。這確保了整個(gè)代碼庫的一致性。

4. 安全性

Web應(yīng)用程序是攻擊的主要目標(biāo)。在PHP世界中，安全的代碼審查會(huì)特別關(guān)注一些關(guān)鍵領(lǐng)域。

首先，永遠(yuǎn)不要相信來自外部來源的數(shù)據(jù) 處理所有用戶輸入（表單提交、URL參數(shù)等）潛在的惡意使用PHP內(nèi)置的過濾器函數(shù)（filter_var，filter_input）去除危險(xiǎn)字符（例如，<script>標(biāo)簽以防止XSS）并執(zhí)行規(guī)則以確保輸入與您期望的匹配（例如，正確的電子郵件格式或有效的數(shù)字范圍）。

為了保護(hù)您的應(yīng)用程序免受臭名昭著的SQL注入漏洞的影響，請(qǐng)避免直接將用戶輸入連接到SQL查詢中。相反，依賴于mysqli或PDO準(zhǔn)備語句（或者更好，在數(shù)據(jù)庫抽象層[DBAL]或一些好的ORM上）。它們清楚地將SQL結(jié)構(gòu)與用戶提供的數(shù)據(jù)分開，允許數(shù)據(jù)庫安全地處理數(shù)據(jù)并消除SQL注入嘗試。刪除危險(xiǎn)字符（例如，<script> 標(biāo)簽以防止XSS）并強(qiáng)制執(zhí)行規(guī)則以確保輸入符合你的期望。

最后，小心處理錯(cuò)誤。避免向用戶顯示原始錯(cuò)誤消息（數(shù)據(jù)庫錯(cuò)誤、堆棧跟蹤），因?yàn)樗鼈兛赡軙?huì)泄露敏感的系統(tǒng)信息。相反，將錯(cuò)誤記錄到一個(gè)文件中，供開發(fā)人員進(jìn)行故障排除，確保這些日志本身受到保護(hù)，不受未經(jīng)授權(quán)的訪問。當(dāng)出現(xiàn)錯(cuò)誤時(shí)，向用戶顯示通用的、有幫助的錯(cuò)誤消息，并記錄詳細(xì)信息以進(jìn)行內(nèi)部調(diào)試。在我們的例子中，我們主要使用Monolog并將日志轉(zhuǎn)發(fā)到DataDog或NewRelic等工具。我們也總是有一個(gè)哨兵實(shí)例連接，以收集更多的信息的問題。

雖然現(xiàn)代框架提供了內(nèi)置的安全功能，但在代碼審查期間確保其正確實(shí)現(xiàn)至關(guān)重要。密切關(guān)注這些方面：

• 輸入清理：代碼是否仔細(xì)地過濾和驗(yàn)證來自用戶的任何數(shù)據(jù)（表單、URL參數(shù)等）？尋找特定于框架的輸入清理函數(shù)或方法。
• 預(yù)處理語句：數(shù)據(jù)庫查詢是否始終使用預(yù)處理語句構(gòu)建？檢查框架方法，這些方法有助于防止SQL注入。
• 錯(cuò)誤處理：代碼是否避免向用戶暴露原始錯(cuò)誤消息或堆棧跟蹤？是否在內(nèi)部記錄錯(cuò)誤，以便開發(fā)人員進(jìn)行故障排除？在出現(xiàn)故障時(shí)，是否有用戶友好的后備機(jī)制？

5. PHP性能優(yōu)化

執(zhí)行緩慢的代碼會(huì)讓用戶感到沮喪，并且可能會(huì)耗盡服務(wù)器資源。一個(gè)全面的代碼審查應(yīng)該始終考慮性能優(yōu)化，特別是關(guān)注以下方面：

• 更智能的算法：你構(gòu)建代碼的方式對(duì)速度有很大的影響。分析您的核心算法，并尋找使用更有效數(shù)據(jù)結(jié)構(gòu)的機(jī)會(huì)（例如，考慮哈希表而不是用于搜索的嵌套循環(huán)）。熟悉大O表示法有助于理解代碼的效率如何隨著較大的數(shù)據(jù)集而擴(kuò)展。
• 數(shù)據(jù)庫交互：對(duì)數(shù)據(jù)庫的每個(gè)查詢都會(huì)增加開銷。通過使用緩存技術(shù)（Memcached，Redis）將頻繁訪問的數(shù)據(jù)存儲(chǔ)在內(nèi)存中，減少不必要的數(shù)據(jù)庫調(diào)用。當(dāng)你確實(shí)需要查詢時(shí)，優(yōu)化你的SQL：適當(dāng)?shù)厥褂盟饕苊猥@取比你需要的更多的數(shù)據(jù)，并注意復(fù)雜的連接可能會(huì)減慢速度。在開始使用緩存之前，首先關(guān)注索引和查詢優(yōu)化。
• 尋找瓶頸：不要盲目?jī)?yōu)化！使用像Blackfire這樣的分析工具來精確測(cè)量你的應(yīng)用程序在哪里花費(fèi)了大部分時(shí)間。這將精確定位最需要注意的函數(shù)或數(shù)據(jù)庫查詢。Blackfire提供了對(duì)執(zhí)行時(shí)間、函數(shù)調(diào)用和內(nèi)存使用的寶貴見解。

技術(shù)說明

• 過早的優(yōu)化是一個(gè)陷阱：首先關(guān)注干凈的、功能性的代碼。過早地過度優(yōu)化會(huì)使代碼更難閱讀。
• 緩存有多種形式：根據(jù)應(yīng)用程序的需要，在內(nèi)存緩存、基于文件的緩存甚至HTTP緩存之間進(jìn)行選擇。
• 數(shù)據(jù)集越大，算法的影響就越大：對(duì)小規(guī)模數(shù)據(jù)運(yùn)行良好的代碼可能會(huì)隨著輸入大小的增加而爬取。

請(qǐng)?zhí)貏e注意數(shù)據(jù)庫遷移。密切關(guān)注數(shù)據(jù)庫遷移，同時(shí)考慮代碼性能和遷移過程本身。大型遷移可能需要相當(dāng)長(zhǎng)的時(shí)間（甚至可能需要幾分鐘），因此提前了解潛在影響至關(guān)重要。

代碼評(píng)審注意事項(xiàng)

雖然徹底的依賴審計(jì)超出了典型的代碼審查范圍，但以下是需要注意的關(guān)鍵事項(xiàng)：

• 嚴(yán)重過時(shí)的軟件包：注意已安裝的軟件包與其最新版本之間的任何主要版本差異。這可能意味著潛在的兼容性問題或安全風(fēng)險(xiǎn)。
• 漏洞警報(bào)：如果您使用Snyk或Dependabot等工具，請(qǐng)檢查它們是否標(biāo)記了項(xiàng)目依賴項(xiàng)中的任何已知漏洞。
• 版本含義：建議軟件包更新時(shí)，請(qǐng)注意語義版本控制（主要.次要.補(bǔ)丁），因?yàn)橹饕驴赡軙?huì)有破壞性的更改。
• 公司標(biāo)準(zhǔn)：一些組織有關(guān)于依賴關(guān)系更新的特定政策，審閱者應(yīng)該熟悉這些政策。
• 審查范圍：如果時(shí)間允許或者安全性是一個(gè)關(guān)鍵問題，使用可驗(yàn)證性檢查工具進(jìn)行簡(jiǎn)短的依賴性掃描可能是代碼審查的一個(gè)有價(jià)值的補(bǔ)充。

數(shù)據(jù)庫優(yōu)化和安全

始終確保數(shù)據(jù)庫查詢一致地使用預(yù)處理語句，以減輕SQL注入風(fēng)險(xiǎn)。使用與數(shù)據(jù)庫集成的分析工具（例如，MySQL的慢速查詢?nèi)罩荆┗駼lackfire/New Relic等擴(kuò)展來識(shí)別最有效的優(yōu)化。注意索引-確保頻繁查詢的列上存在適當(dāng)?shù)乃饕?，特別是對(duì)于具有多列搜索條件的表。

錯(cuò)誤處理

定義創(chuàng)建錯(cuò)誤層次結(jié)構(gòu)的自定義異常類（例如：DatabaseException、ValidationException）。這種方法可以在整個(gè)代碼庫中實(shí)現(xiàn)粒度錯(cuò)誤處理。策略性地使用不同的日志級(jí)別（調(diào)試、信息、警告、錯(cuò)誤）。

適當(dāng)?shù)嘏渲萌罩居涗浌ぞ撸愿鶕?jù)嚴(yán)重性進(jìn)行存儲(chǔ)或發(fā)出警報(bào)。最后，仔細(xì)考慮顯示給用戶的錯(cuò)誤消息。這些消息應(yīng)該清楚地引導(dǎo)用戶找到解決方案，而不會(huì)泄露敏感的系統(tǒng)細(xì)節(jié)。

由于信息有限，用戶報(bào)告的網(wǎng)絡(luò)安全問題可能很棘手。這就是為什么明確的錯(cuò)誤消息和詳細(xì)的日志是必不可少的。它們?yōu)槟峁┝丝焖俨槊鲉栴}和改善用戶體驗(yàn)所需的線索。

將代碼評(píng)審作為一種習(xí)慣

代碼審查不應(yīng)該被看作是一次性的苦差事，也不應(yīng)該被看作是簡(jiǎn)單地發(fā)現(xiàn)bug的一種方式。通過將它們作為開發(fā)過程中的常規(guī)實(shí)踐，您將不斷提高PHP代碼庫的質(zhì)量。每一次評(píng)審會(huì)議都能構(gòu)建技術(shù)知識(shí)并加強(qiáng)團(tuán)隊(duì)內(nèi)部的協(xié)作。

代碼審查也是在團(tuán)隊(duì)中傳遞知識(shí)的好方法。不僅編寫任務(wù)的開發(fā)人員知道它是如何實(shí)現(xiàn)的，而且進(jìn)行代碼審查的人也會(huì)對(duì)它有很好的理解。在我們的例子中，我們確保添加，刪除或更改的每一行都至少由另一個(gè)人審查。

請(qǐng)記住，干凈、安全和結(jié)構(gòu)良好的代碼不僅僅是美學(xué)。它節(jié)省了調(diào)試時(shí)間，降低了漏洞的風(fēng)險(xiǎn)，并允許您的應(yīng)用程序更優(yōu)雅地?cái)U(kuò)展。讓代碼審查成為你工作流程中不可協(xié)商的一部分。隨著時(shí)間的推移，這些好處將變得更加復(fù)雜，導(dǎo)致更健壯，更容易維護(hù)和更成功的PHP項(xiàng)目。