前端的质量和安全怎么建设

小麦2024年11月18日1895 字

质量和安全是软件工程时常提及的问题,前端自然也不例外。代码写得好不好,有没有安全漏洞,只是其中一个维度,它更是一个系统性工程。

对于前端开发来说,可以从这四个方面讨论:编码质量,测试,攻击防御和稳定性。

我们会经常讨论编码质量的问题。

每个人的编程经验和习惯不同,写出来的代码自然就不会一样。

采用防御性编程,质量管理工具,以及实施代码评审是常用的提升编码质量的手段。

防御性编程要求程序员在编写代码时预见可能出现的问题,并提前采取措施来规避这些问题。特别是对于弱类型的前端编程语言,做到这一点非常重要。比如:

判空处理:对不确定的输入参数采用短路写法提前判空返回。

异常处理:使用 try-catch 对可能抛出异常的调用进行错误处理。

降级处理:对允许出错的弱依赖场景,可以返回默认值,增加系统的容错性。

防御性编程无法规避一些难以察觉的问题,需要借助质量管理工具来自动分析代码问题。

常用的代码质量管理工具包括静态检查工具和风格控制工具两类。

我们最常用的 ESLint 就属于静态检查,它内置了许多判断规则,这些规则内部对抽象语法树(AST)进行分析判断,来确定是否存在已知问题。

其次是风格控制:Prettier 是一种代码格式化工具,可以根据需要自定义风格偏好,来统一团队的代码风格。

最后是代码评审,代码评审是指不同的人交叉验证代码设计是否合理。

我们之前提到的质量管理工具并不能理解代码设计,只能发现和解决特定的问题。而多数更复杂的问题出现在架构设计阶段,因此多人开发时很有必要进行代码评审。

许多版本控制系统会集成 Pull Request 功能,其实就是发起代码评审。评审时可以根据代码 diff 提出问题或者修改意见,当所有问题解决后再合并代码。

接下来是测试,测试是一种通过编写测试用例,来检查程序执行结果是否符合预期的一种方式。

前端开发常采用的测试手段包括:单元测试,集成测试,兼容性测试,性能测试,UI 测试。

单元测试(Unit Test)的范围最小,通常是对实现某一特定功能的函数进行测试。

常用的单元测试框架包括 Jest 和 Mocha 等。

相比单元测试,集成测试的重点是验证各模块之间的正确性,它的测试范围更大。

常用的集成测试框架包括 Cypress 和 Playwright。

前端代码的运行环境通常是不稳定的,兼容性问题是前端需要解决的难题之一。

尽管许多工具库和框架,都保证了在绝大多数环境中的兼容性,但在实际生产过程中总有漏网之鱼,因此兼容性测试是非常有必要的。

我们可以利用特性探针,验证生产环境中某个 API 是否可用。如果再配合埋点日志收集检测数据,就可以提前准备兼容方案。常用的检测工具 Modernizr 可以做到这点。

此外我们还经常使用 caniuse,BrowserStack、Puppeteer 等工具在应用上线前进行兼容性验证。

接下来是性能测试,我们在「用户体验」章节介绍过性能测试的常用方法,可以翻看之前的视频进一步了解。

最后,UI 测试关注用户界面的展示和交互前后是否符合预期。

可以使用 UI 框架推荐的测试工具来完成,比如 React 的 React Testing Library,Vue 的 Vue Test Utils。它们为框架做了深度优化,相比自己封装更容易使用。

UI 测试既可以进行单元测试,也可以进行端到端测试,甚至是实际录制测试用例,减少测试用例的编写成本。

前端攻防也是老生常谈的问题了,

跨站脚本攻击(XSS)和跨站请求伪造(CSRF)是最典型的两类针对前端应用的攻击方式。

跨站脚本攻击(XSS)是攻击者通过某些手段将恶意代码注入到用户的网页中,来窃取敏感信息或是执行恶意操作。

常用的防御措施就是在代码注入环节进行校验和过滤。

比如采用 sanitize-html 对用户输入进行过滤,特别是需要展示用户输入的业务场景,比如文章发布,评论留言等等。

跨站请求伪造(CSRF)是攻击者诱导用户访问包含恶意代码的网页,在用户不知情的情况下,向没有做好防护的服务器发送恶意请求。

它的防御方法主要有两种:同源检查和 Token 检查,不过这些都需要依赖服务端的检验保护。

最后是稳定性,稳定性时常被我们忽视,但它却影响着前端开发的方方面面。

在一个标准研发流程中,我们采用持续集成的方式迭代应用。构建系统会从公网或内网 NPM 仓库中下载和安装依赖。同时也伴随着不稳定因素,比如三方依赖的错误更新导致构建失败,恶意脚本植入导致敏感信息泄露等。这就是供应链安全。

我们有许多手段提升供应链的稳定性和安全性,比如使用依赖锁文件(package-lock.json)并定期更新,在构建系统中接入安全组件屏蔽恶意版本。

应急预案也是能够有效提升系统稳定性的途径,它是指在系统出现故障或紧急情况时,使用的一套预先制定的处理方案和步骤。

比如在大促场景下,我们可以提前在代码中加入特性开关(Feature Switch),配合 KV 服务推送配置,控制黄条公告的展示实现快速应急。

本期我们从编码质量,测试,攻击防御和稳定性四个方面介绍了前端的质量和安全性应该怎么去建设,下一期我们进一步聊聊在本章中提到的持续集成和部署相关的话题。

记得点个关注,我是小麦,我们下期再见。

评论

你需要先登录才能发表评论
Made by 捣鼓键盘的小麦 / © 2025 Front Talk 版权所有