记一堂公开课《前端架构的设计与进化》思考总结

以下是我结合课程的思考总结，若有什么问题，欢迎留下意见

架构及架构设计

架构是针对业务系统的各方面设计，可以包含但不等于 技术栈的选择、框架或类库的选择，它更多的是针对某个业务实现的合理解决方案；

框架是很好的搭建项目工具，技术栈是开发的基础，这只是成就一个项目的基石。架构的设计方案若可形成较优解，则可不断推动前端的发展及进步，理解MVVM模式就是一种针对前端“Model-View”分离管理相互关联提升交互的一种架构的落地。

业务可大可小，业务可以是整个产品，或是某个环节的一部分如“微前端”，理解小则精，大的链路是由小链路连接起来的；一个线上产品的架构设计就是从开发到上线运行及后续维护运营等整个业务相关流程的实现方案的评估与选择；某个环节如老旧项目和新技术项目的整合的“微前端”方案选择；

做架构需要注意的关键点

核心理念

核心理念是团队共同认可的架构思路及方向，与业务形态相关，具备前瞻性，是取舍的结果。

从 生命周期、体验要求、兼容性要求、逻辑复杂程度、UI交互复杂度、涉及团队量、核心功能模块 等去分析去做取舍去选择方案，打好基础，不断优化；

组件框架

切入角度：模板引擎、通讯模型、开发模式、基础类库

团队技术栈范围、兼容、自适应、强内容/强交互/游戏类型、大应用功能尽量避开谷歌产品（断崖式快速更新）、合适而非最新（技术无好坏无新旧，看如何使用合适）；

新技术和前瞻性不是互斥问题，前瞻性是为以后拓展预留发挥的空间，新技术要看是否适合，哪一点的收益大于成本是非常关注的点；

开发规范

目的：可读、可扩展、可维护；

• 编码规范
  规范已经基本共识，很多公司都有自己的一套规范，最重要的是可以努力通过工具进行代码规范的自动化监测，提高准确性，减少基础的问题；
• 设计思路
• 模块拆分
  业务是否相关、模块重要程度、服务是否通用、产品或技术角度来看
• 代码结构
  切入点：预想业务复杂多倍，开发人员多，特性及版本多，主路径按功能、版本或渠道
  • egg服务架构：
    • 分层：表现层、业务层、逻辑层、数据层
    • 思想：隔离变化、沉淀共识
    • 奉行：约定大于配置

工具平台

工具平台的完善过程就是前端架构工程化的推进过程：
代码管理 - 开发调试 - 代码编译 - 项目构建 - 模块管理 - 配置部署 - 测试支撑 - 性能检测 - 性能分析 - 安全扫描 - 规范约束 - 统计分析 - 运营支撑

工具平台选择：像官方、行业主流看齐；构建工具gulp，模块化工具webpack，运维监控stke

平台工具是架构的体现，不是必要条件；关键在于评估投入和收益；

流程边界

前端 - 大前端（前端 + 前端BFF） - 全栈，打破流程边界得益于技术的发展和个人主观积极进取，fighting

经验沉淀

最强大的点在于控制，控制风险在局部；
最大风险在于传承，依赖后续同事维护和进化；
经验沉淀、理念传承；

机构设计常遇到的问题

• 目标不清晰：要解决的本质问题未抽象清楚
• 过度参考：类似方案架构设计是否符合应用
• 追求新技术：单纯新技术很容易出问题
• 缺少全局观：不为后续考虑
• 团队成员能力未考虑

架构中的设计技巧

业务理念、前瞻、痛点、跨界、步步为营

架构演进的助力

技术栈升级、业务形态变更、前端边界突破

前端观点记录

前端不是不能做些什么，关键在于发现；
坚持做正确和难的事情，开花结果只是早晚的事情；

思考

自定义组件，原生js是否有望支持，像Svelte那样；
大前端：前端 + BFF；全栈：前端+后端；
前端离业务略远、离用户很近，优化性能及体验首当其冲，业务沉淀积累去解决业务层面上的痛点；全栈必然是技术层面上的下一步；