不要在前端这样做,否则……开发人员的前端良好实践
控制台日志
删除。
在生产代码中删除 console.log 以防止敏感信息泄露并提高性能非常重要。
控制台错误和警告
调查并修复。
解决生产代码中的控制台错误对于保持流畅、无错误的用户体验非常重要。
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 等。
如果贵公司有 UX、QA 和网络安全/渗透测试团队,请与他们合作。
害怕沟通
你是一个人。
无论何时遇到困难,请致电另一位开发人员或技术主管来分享您所面临的问题。
通过结对编程和共同思考可以更快地解决问题!
请记住:他们曾经处于您的位置并且会帮助您!
希望你喜欢!😃✌🏻
您还有其他提示吗?
支持我的工作☕️请我喝杯咖啡
文章来源:https://dev.to/lucasm/frontend-best-practices-guide-or-dont-do-it-on-frontend-32n4