要Review的指標

前端代碼Review主要關注以下幾個方面：

1、代碼質量：代碼是否簡潔、易讀、易維護。是否遵循了一致的編碼風格和規范，例如ESLint、Prettier等。
2、功能實現：代碼是否實現了預期的功能，是否有潛在的bug或邏輯錯誤。
3、性能優化：代碼是否進行了必要的性能優化，例如避免不必要的渲染、使用了合適的數據結構和算法等。
4、安全性：代碼是否存在可能的安全風險，例如XSS攻擊、CSRF攻擊等。

5、可測試性：代碼是否易于測試，是否有單元測試和集成測試。
6、可讀性：代碼是否易于理解，是否有足夠的注釋和文檔。
7、可復用性：代碼是否有高度的模塊化和復用性。
8、兼容性：代碼是否兼容不同的瀏覽器和設備。

助記：功性讀復全兼測

功能Review

• 無需人為檢測，但注釋要寫明白，TS類型要寫清楚，讓用的人如沐春風；
• 該匹配單元測試的建議配套單元測試，不落人以口實~

性能Review

前端代碼中一些典型的、肉眼可見的需要性能優化的地方包括：

1、過度渲染：如果你的應用在沒有必要的情況下進行了過多的渲染，這可能會導致性能問題。例如，在React中，如果你的組件在props沒有改變的情況下進行了重新渲染，那么你可能需要使用shouldComponentUpdate/SCU或React.PureComponent或useEffect來避免不必要的渲染。
2、大量DOM操作：頻繁的DOM操作是非常耗費性能的。如果你的代碼中有大量的DOM操作，你可能需要考慮使用虛擬DOM或其他優化技術（例如DocumentFragment）。
3、大量的網絡請求：如果你的應用發送了大量的網絡請求，這可能會導致性能問題。你可能需要考慮使用緩存、預加載、懶加載等技術來減少網絡請求。
4、大型JavaScript文件：如果你的JavaScript文件過大，這可能會導致加載和解析時間過長。你可能需要考慮使用代碼分割、懶加載等技術來減小文件大小。
5、未優化的圖片和媒體文件：如果你的網站使用了大量的未優化的圖片和媒體文件，這可能會導致加載時間過長。你可能需要考慮使用圖片壓縮、適當的文件格式、CDN等技術來優化你的媒體文件。
6、阻塞渲染的CSS和JavaScript：如果你的CSS和JavaScript阻塞了頁面的渲染，這可能會導致用戶體驗不佳。你可能需要考慮使用非阻塞的加載技術，如異步加載、延遲加載等。

非阻塞加載CSS和JS

阻塞渲染的CSS和JavaScript是一個常見的前端性能優化問題。當瀏覽器加載網頁時，它會按照HTML文檔的順序解析每個元素。當遇到<link>或<script>標簽時，瀏覽器會停止HTML解析，去下載和執行CSS或JavaScript文件，這就是所謂的“阻塞渲染”。

以下是一些優化阻塞渲染的CSS和JavaScript的策略：

1、異步加載JavaScript：使用async屬性可以使瀏覽器異步加載JavaScript，即在下載JavaScript文件的同時，瀏覽器可以繼續解析HTML。但是，這可能會導致JavaScript在DOM還未完全解析時就開始執行，因此只適用于那些不依賴DOM的JavaScript文件。

2、延遲加載JavaScript：使用defer屬性可以使瀏覽器延遲執行JavaScript，即在DOM解析完畢后，再執行JavaScript。這適用于那些依賴DOM的JavaScript文件。

3、內聯關鍵CSS：將關鍵的CSS（即渲染首屏內容所需的CSS）內聯到HTML中，可以避免瀏覽器等待CSS文件的下載和解析。但是，這可能會增加HTML文件的大小，因此只適用于小量的CSS。

4、媒體查詢：使用媒體查詢可以讓瀏覽器只下載適用于當前設備的CSS，從而減少不必要的下載；本質是一種CSS的按需加載技術

以上就是優化阻塞渲染的CSS和JavaScript的一些策略。

可讀性Review

關注一下以下要點：

• 變量、函數、類、文件和文件夾的語義化命名
• 注釋
• 文檔
• TS類型聲明

復用性Review

正在review的這段代碼可復用性如何，高的話是否可以：

• 封裝為函數
• 封裝為類
• 封裝為指令
• 封裝為hook
• 封裝為組件
• 封裝為模塊

安全性Review

在前端代碼的安全性Review中，主要關注以下幾個方面：

1、跨站腳本攻擊（XSS）：檢查代碼中是否正確地對用戶輸入進行了轉義，以防止插入惡意的JavaScript代碼。例如，當使用React時，它默認會轉義所有的用戶輸入，但如果你使用dangerouslySetInnerHTML（或Vue中的v-html），則需要特別小心。
2、跨站請求偽造（CSRF）：檢查是否在所有的POST請求中使用了CSRF令牌，以防止攻擊者偽造用戶的請求。
3、點擊劫持：檢查是否使用了適當的HTTP頭，如X-Frame-Options，來防止點擊劫持攻擊。
4、內容篡改：檢查是否所有的HTTP請求都使用了HTTPS，以防止混合內容問題，這可能會導致用戶的數據被竊取（傳輸過程中被抓包）。
5、輸入驗證：檢查是否在客戶端和服務器端都進行了輸入驗證，以防止注入攻擊，圖形或字符驗證碼、短信驗證、CSRF-token等的本質都是加入隨機真人校驗機制，狠重要！
6、敏感信息泄露：檢查代碼中是否有可能泄露敏感信息的地方，如在URL、錯誤消息或日志中包含敏感信息。
7、依賴的安全性：檢查所有的第三方依賴是否都是最新的，是否有已知的安全漏洞。

點擊劫持

X-Frame-Options 是一個HTTP響應頭，用于控制網頁是否可以被其他網頁通過、或等元素嵌入。這個響應頭的主要目的是為了防止點擊劫持/Clickjacking攻擊。

X-Frame-Options有三個可能的值：

1. DENY：此頁面不能被嵌入到任何其他頁面中。

2. SAMEORIGIN：只有同源的頁面（即，URL的協議、域名和端口都相同）才能嵌入此頁面。

3. ALLOW-FROM uri：只有指定的頁面可以嵌入此頁面。但是，這個值已經被廢棄，不再被大多數現代瀏覽器支持。

如果沒有設置X-Frame-Options頭，或者設置的值不是上述三個值之一，那么任何頁面都可以嵌入此頁面。因此，為了防止點擊劫持攻擊，建議總是設置X-Frame-Options頭。

兼容性Review

在前端代碼的兼容性Review中，主要關注以下幾個方面：

1、瀏覽器兼容性：檢查代碼是否能在所有支持的瀏覽器中正常工作。這包括檢查是否使用了某些瀏覽器可能不支持的JavaScript特性或CSS屬性，以及是否正確地使用了polyfill和前綴。
2、設備兼容性：檢查代碼是否能在所有支持的設備中正常工作，包括不同的操作系統、屏幕大小和分辨率。
3、響應式設計：檢查代碼是否適應了不同的屏幕大小，包括手機、平板和桌面。
4、無障礙性：檢查代碼是否遵循了無障礙性標準，如WAI-ARIA，以確保所有用戶，包括那些使用輔助技術的用戶，都能使用你的應用。
5、國際化和本地化：檢查代碼是否支持多種語言和地區，包括正確地使用了日期、時間和數字的格式。
6、性能：檢查代碼在低性能的設備或網絡環境下是否還能正常工作。

即充分考慮不同瀏覽器、不同設備、不同屏幕、不同國家、不同人群。

什么是polyfill

• Polyfill是一段代碼（通常是JavaScript），用于為舊的或不支持某些特性的瀏覽器提供這些特性的實現。Polyfill的目的是讓開發者能夠使用新的、更高級的API，而不用擔心兼容性問題。
• 例如，Array.prototype.includes是一個新的JavaScript特性，用于檢查數組中是否包含某個元素。但是，這個特性在IE瀏覽器中是不支持的。為了在IE中也能使用這個特性，我們可以使用一個polyfill，如下：

• 這段代碼首先檢查Array.prototype.includes是否存在。如果不存在（即，瀏覽器不支持這個特性），那么就給Array.prototype添加一個includes方法，這個方法的行為和原生的includes方法一樣。
• 在實際開發中，我們通常不會自己寫polyfill，而是使用已經存在的polyfill庫，如core-js或polyfill.io。
• 需要注意的是，雖然polyfill可以讓我們在舊瀏覽器中使用新特性，但是它也有一些缺點。首先，polyfill會增加代碼的大小，可能會影響網頁的加載速度。其次，polyfill可能無法完全模擬新特性的行為，特別是一些復雜的或與性能相關的特性。因此，在使用polyfill時，需要權衡其利弊。

配置polyfill

• 安裝polyfill庫通常是第一步，但是你可能還需要進行一些配置，以確保polyfill能夠在你的代碼中正確地工作。
• 具體的配置步驟取決于你使用的polyfill庫和構建工具。
• 以core-js和babel為例，你可以按照以下步驟來配置polyfill：

1. 首先，安裝core-js和@babel/preset-env：

2. 然后，在你的.babelrc文件（或者babel的配置文件）中，添加@babel/preset-env預設，并設置useBuiltIns和corejs選項：

• 這里的useBuiltIns選項有兩個可能的值："usage"和"entry"。如果設置為"usage"，那么babel會自動檢測你的代碼中使用了哪些新特性，然后只包含這些特性的polyfill。如果設置為"entry"，那么你需要在你的代碼的入口文件中，手動導入所有需要的polyfill：

以上就是配置polyfill的一個示例。需要注意的是，這只是一個基本的配置，實際的配置可能會更復雜，取決于你的具體需求和環境。

可測試性Review

在前端代碼的可測試性Review中，主要關注以下幾個方面：

1、單元測試：檢查代碼是否易于進行單元測試。這包括檢查函數是否是純函數（即，相同的輸入總是產生相同的輸出，沒有副作用），以及是否避免了全局狀態。

2、集成測試：檢查代碼是否易于進行集成測試。這包括檢查組件是否正確地使用了props和state，以及是否避免了直接操作DOM。

3、端到端測試：檢查代碼是否易于進行端到端測試。這包括檢查頁面是否有易于定位的元素（如有特定id或data-test屬性的元素），以及是否有清晰的用戶流程。

4、測試覆蓋率：檢查代碼的測試覆蓋率是否足夠。這包括檢查是否所有的函數和分支都有對應的測試。

5、模擬和打樁：檢查代碼是否易于進行模擬和打樁。這包括檢查函數是否避免了直接調用復雜的依賴（如網絡請求或數據庫操作），以及是否提供了足夠的接口來替換這些依賴。

6、錯誤處理：檢查代碼是否正確地處理了可能的錯誤。這包括檢查是否有錯誤處理函數或catch塊，以及是否有對應的錯誤測試。

端到端測試

• 端到端（End-to-End，E2E）測試 是一種測試方法，用于測試應用的整個工作流程，從用戶界面到數據庫，確保所有部分都能正確地協同工作。
• 在React應用中，我們可以使用Cypress或Puppeteer等工具來進行E2E測試。以下是一個使用Cypress進行E2E測試的基本步驟：

1、安裝Cypress：首先，你需要在你的項目中安裝Cypress。你可以使用npm或yarn來安裝：

2、編寫測試：然后，你可以在cypress/integration目錄下編寫你的E2E測試。以下是一個簡單的測試示例，它測試了用戶是否能正確地登錄：

3、運行測試：最后，你可以使用Cypress的CLI來運行你的測試：

這將會打開Cypress的測試運行器，你可以在這里選擇你要運行的測試。

以上就是在React應用中進行E2E測試的基本步驟。需要注意的是，這只是一個基本的示例，實際的E2E測試可能會更復雜，包括測試更多的用戶交互和應用狀態。

功性讀復全兼測! OVER，收工干飯！

原文鏈接：https://juejin.cn/post/7283748394601840680

MCSS服務的全稱是多媒體類調度器，它可以自動提高音頻和視頻播放的優先級。在PC配置不佳的情況下，禁用此服務可以在一定程度上減少游戲延遲或視頻播放延遲。您可以通過以下步驟進行設置。

1. 首先，打開“開始”菜單，進入“注冊表編輯器”，搜索并打開注冊表

2. 然后，在注冊表中找到“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Audiosrv”。

3.然后在右邊找到“DependOnService”，雙擊打開它

4. 在彈出的“編輯多個字符串”窗口中找到并刪除MMCSS，單擊“確定”保存并退出

5. 以上就是禁用MMCSS服務來減少游戲延遲或者緩解視頻播放延遲的方法，希望對你的朋友有所幫助!

溫馨提示：

點擊文章頂部頭像或者名稱關注作者，學習更多的大家經常遇到的電腦常識哦！等你呦