看单个前端项目架构好坏。
从拿到一个新人（以前没有接触过这个项目）拿到新功能的开发需求来看，就是新需求能否快速完成上线包括3点：开发人员能否快速完成开发；测试人员能否快速完成测试；发布是否方便。 除此之外从全局看还有：监控；性能；安全
开发人员能否快速完成开发
- 代码托管、分支管理
- 项目开发启动（工程化）：开发模式下的接口调用，登录态的获取，是否需要做一些特殊配置才能在开发环境跑起来，某些能力是否在开发模式下不能完整走通，需要到测试环境等
- 项目结构与md文档：能否快速的了解熟悉项目支持开发工作，是否有很多需要特别注意的点（单看代码没用，需要熟悉项目的人员面对面的沟通），项目相关开发文档是否完整。
- eslint、pritter的使用；ts的类型完整度
- 抽象（组件化）：公共部分的抽象（组件、工具方法、hooks），是否做好了单元测试、业务型部分的抽象（组件、工具方法、hooks）。各种已抽象的能力是否能快速找到。需要新增的抽象，是否能快速借助老的抽象完成；展示类组件还需要特别说明一点，就是前人与UI设计师打下的一些共识基础（ui输出的一致性）；如果是调整现有逻辑，那么抽象的好坏还决定了调整的影响范围
- API层：老的接口是否能快速的找到；新增接口是否能快速配置接入；全局错误处理；业务员行错误能否抛出到业务层
- 状态管理：少部分全局的状态借助全局状态机（redux、pinia、公共hooks、全局provider、localStorage）管理；绝大部分状态肯定是就近原则；但是会出现一些极端情况下的流程类状态需要夸组件或夸页面之间共享（比如订单数据，需要在下单页、支付页、等待页、订单详情页共享），当然这种情况是可以借助服务端的持久化来处理（需要即请求服务端返回数据），但是为了更好的优化体验需要怎么处理，而且需要有较强的可读性（不是随便写入localStorage）
- 范式代码：肯定是尽量越少越好，范式代码代表着大量的约定。一般非框架或者语言的约定，在执行和延续上都会很差。范式代码能否抽象到工厂完成，不需要每次都copy一遍。
测试人员能否快速完成测试
当然新需求本身的测试是避免不了的，但是抽象和分层和好坏直接决定了新需求对已有逻辑的影响范围。
- 需求变更涉及到需要调整公共代码（组件、工具方法、hooks），是否做好了单元测试（vitest; testing-library+jest）
- 业务需求本身的集成测试（vitest; testing-library+jest）
- 端测（cypress），是否在测试发布中集成了e2e。
以上的适项目和团队的情况，可选择性的处理
发布是否方便
- 自动化发布，无需开发人员手动部署。一般使用jenkins；根据团队和公司情况自建自动化的发布系统等。
- 灰度，少量流量切给新版本。
- 回滚，发布出现问题，需要回滚，是否有自动化的回滚策略。
监控
这里只是主要是错误监控，react的ErrorBoundary/vue的errorCaptured，合理的选择第三发方监控工具如arms/sentry等。
安全
- https是肯定要用的
- xss：注入，不管是前端的还是服务端的，主要是吧用户提交的数据当场代码逻辑的一部分来使用，比如把用户的一段输入作为页面的一部分用innerHtml直接写入。需要前后端一起配合，对用户的输入做转义。还有未来降低注入后的危害可以配置csp或者是httponly
- csrf：主要是登录cookie的问题。关键请求需要验证码；会话使用jwt（其实加一个不在cookie中的token也行）；cookie的SameSite。
- 点击劫持。配置X-FRAME-OPTIONS。
- 越权方面的就交给安全测试去做了，前端做好按照策略或者角色做好菜单和页面权限的控制就ok。
性能 内容比较多需要单独说
