原文出處：https://dev.to/lucasm/frontend-best-practices-guide-or-dont-do-it-on-frontend-32n4
console.log
請刪掉。
刪除 production 程式碼中的 console.log 以防止敏感資訊洩漏。
控制台錯誤和警告
調查並修復。
解決 production 程式碼中的控制台錯誤對於保持流暢且無錯誤的使用者體驗非常重要。
TypeScript 中的 any
請使用準確的型別。
應盡量減少在 TypeScript 中使用“any”，轉而使用明確類型，以增強程式碼的可靠性和可維護性。
註解未使用的程式碼
請刪掉。
註解掉未使用的程式碼是一種不好的做法，因為它會使程式碼變得混亂，妨礙維護，並可能導致註解資訊過時。
超級元件和功能
如果您的元件很大，那麼就該將其分成更小的元件了。
想想 SOLID 的古老原則「單一職責」。
無論您是編寫函數程式碼還是類別程式碼。
多次重寫CSS
不要重複重寫顏色、字體和大小，使用設計標記來發揮自己的優勢，建立全域 CSS 變數或使用函式庫。
與您的團隊討論使用設計令牌的優勢。
Linter 的標誌
修復你的程式碼。
範例：使用 /* eslint-disable @typescript-eslint/no-unused-vars */
不要傳送帶有 linter 錯誤的 Pull 請求。
如果您確實需要忽略，請仔細考慮可以忽略哪些 linter 警告。
重新渲染和循環消耗大量資源或崩潰
範例：JavaScript 循環函數或 React 中的 useEffect 應用不佳。
這可能會導致 API 呼叫或值無限重複，從而導致記憶體溢出並導致應用程式崩潰。
修正你的邏輯。
- 注意：您的應用程式在瀏覽器中執行並消耗有限的用戶記憶體資源。
前端的商業邏輯
請勿放置。
人們普遍認為，任何前端應用程式都不能有業務規則，只有使用者介面固有的規則，用於互動和使用者的成功旅程。
前端是客戶端，不是伺服器。
大公司和企業級應用程式採用的做法是不將業務規則和資料處理暴露在前端，而將其放在後端。
- 注意：對於簡單的無伺服器 Web 應用程式或參考第三方 API 的應用程式，可能有必要在前端放置一些業務規則 - 小心不要向客戶端暴露敏感或成本高昂的動作。
不測試
在您的程式碼庫上進行測試。沒有程式碼是完美的。
單元、整合、安全性、使用者體驗、效能和可存取性測試。使用測試工具產生錯誤報告和改進以糾正您的應用程式。
範例：部署管道中的 Cypress、Lighthouse、SAST 等。
與使用者體驗、品質保證和網路安全/滲透測試團隊合作（如果您公司有）。
恐懼溝通
當您遇到困難時，請致電其他開發人員或技術主管來分享您面臨的問題。
透過 pair programming 和共同思考，可以更快解決問題！
請記住：他們曾經處於您的位置並且會提供幫助！
希望你喜歡！😃✌🏻
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式