设计理念
组件设计
现状及趋势：Web 开发以组件为基础，JavaScript 社区主流是函数式编程。
组件设计应以实现目标用户需求为准。组件过于灵活以适应不同的运行环境，诱发开发者随意进行组装，导致最终组合的产品中包含大量冗余的 HTML、CSS 和 JavaScript，并无脑发送给用户。
抽取复杂组件时，注意是消除复杂性，而不是转移它。
基于特定框架、UI 库的组件，在框架、库版本重大更新，甚至更换时，自我更新成本过大。组件应独立框架，而不是适应框架。
CSS 使用 @container 容器查询，基于父级容器尺寸适配，消除 @media 媒体查询只能全局适配的局限性。
合理使用 @scope 作用域规则和 :scope 作用域选择器
框架
React.dev：直接使用框架，尽管项目可能在起步阶段不一定需要框架所提供的一切，但很可能会在未来的某个时候有所需求，那时即可轻松添加这些新功能。否则后续就得自行添加额外的库来解决各种功能需求，拉高各组件间匹配的难度。
框架依赖的配置和 Node 模块过多，已极大影响首次加载和运行性能，Node 模块安全性问题也越发突出。
跨平台框架
- Wasm（WebAssembly）二进制一个缺陷，不利于调试，例如查看源代码。
- Flutter 在 Android 平台渲染质量仍然不高，Web 渲染器包括 HTML 和 CanvasKit 选项，其中 CanvasKit 使用 WebGL 绘制 Flutter GUI。
架构
观察架构时，应当从多个视角进行考量：用例、逻辑视图、流程视图、实现视图与部署视图等。DevOps 就是将部署和实现视图融合了起来。
一切架构都属于设计，但并不是所有设计都属于架构。架构代表的是塑造系统形式和功能的一系列重要设计决策，其中的“核心”则是以变更成本来衡量。
当代架构师的大部分工作，简化成选择框架和组件并将它们编排在一起。框架本身也代表着大型系统的精髓。属于最顶尖级别的架构决策，逐渐成为常规框架的固有组成部分。
决策维度
- 责任度。比如初创公司，只需要关注能不能赚钱，可以编写一次性的软件，实现出来就行。但如果是开发下一代洲际弹道导弹系统，就得拿出更负责任的态度。
- 风险。评估最差结果是什么，如果项目发生故障就会威胁人身安全，就得使用更规范的架构。
- 复杂性。假设构建的是市面上已经成熟的系统，AI 大模型就能快速搞定、根据提示词构建起应用程序。但如果要构建的是更复杂的系统，或之前并不存在的东西，则考虑就较多。
ECMAScript 标准化趋势
TC39 Rob Palmer：“我们见证了工具（tools）、框架（frameworks）和模式（patterns）的迭代，随着时间推移，我们会在标准层面择取其中已趋同的点，并努力为降低应用程序技术栈的复杂度铺平道路。这样 Node 模块目录才能持续瘦身，越来越多的功能（functionality）由语言自身直接提供。”
TC39 Rob Palmer 和 Ecma Daniel Ehrenberg 均认为 ECMAScript 标准化需保守地（conservatively）进行，因为一旦发现设计有误且需要修正（比如 Web 组件），那从 Web 平台中移除错误的成本是非常高的。相比之下，Polyfill 和基于工具的功能实现（标准候选版）允许更快的反馈周期，保护了 Web 兼容性，无需让开发者等待正式流程走完所有阶段。
打包
打包工具解决的问题：
- JavaScript 宿主环境不支持模块，大型项目只能先合并成单一脚本再执行。
- Node.js 的模块机制与浏览器不兼容，须进行兼容处理。
rollup.js 特点：输出代码整洁，体积小，无 import 和 export 语句；摇树（tree-shaking），打包时自动删除没有用到的代码。
技术选型
多语言、多框架选择时，需考虑因素有：公司业务规划（契合度）、现有人力资源（成本）、团队技术提升（持久性）。
图形图像技术：使用第三方 UI 组件库、图表库，是否需二次开发，或者自主开发。
前端全职 VS 全栈
全职专注于：浏览器性能、跨平台、辅助功能、设计和测试部门间的桥梁、用户体验。
减少认知负担
- 深层模块（deep module） - 接口简单，功能复杂；
- 浅层模块（shallow module） - 接口复杂，功能简单。
深层模块把复杂性隐藏，方便使用。浅层模块过多会使项目难以理解，不仅要记住每个模块的职责，还要记住它们之间的所有交互。
开发成本控制
尽可能让事情简单化；尽可能少造轮子；尽可能使用已验证的、可靠的技术。
减少类型检查依赖
类型系统在编译阶段就能发现错误，但其自身会引入不必要复杂性。通过松耦合的组件、简洁的接口、严格的调用顺序，也可以构建出可靠的大型系统。
软件工程
整个软件工程的发展史，就是一段抽象层次不断提升的历史。
遗留系统，当代码被写下的瞬间，它其实就成了遗留系统，直到最终废弃。除非代码的设计之初就充分考虑到可废弃性，否则必然会有一部分代码难以甚至根本不可变动——这对应的就是成本（技术债）。以自动化方式发现遗留软件系统中的模式。
很难单凭代码就体会到当初开发者做出的那些设计决策，以及理解他们当初做出选择时的具体背景。在核心决策者离开之后，项目会出现漂移。
20 世纪 60 年代，人口不断增加，社会保障持续提升，银行和政府诞生了大量文职工作，掀起过人力流程自动化的浪潮。
复杂系统起源于第二次世界大战和冷战环境下孕育出的 SAGE 系统——即半自动地面防空系统。这是软件工程第一个黄金时代，见证了结构化分析与设计技术的兴起，这个时期包括函数式语言，或者叫算法语言，比如 Fortran、COBOL、APL 以及 Lisp 等等。拆分系统的主要方式是依靠算法。
但这时的软件系统最大的短板在于其并非分布式，而采取的是单体式架构。分布式系统的兴起，也是率先出现在国防领域。ARPANET 阿帕网就是由政府部门提供资助，特别是 DARPA。
解决分布式系统难题时，兴起了 Simula、Smalltalk、Ada、C++ 等语言，诞生了面向对象的软件开发方法，也标志着软件工程第二个黄金时代的开启。
类在抽象方面表现出色，而做错的部分则是过分强调继承的概念，继承的意义在于节省代码。
大语言模型其实是种相当不可靠的方案，但确实能生成一些相当连续的结果，也凭借基于互联网语料库的训练帮助人类探索极其复杂的潜在空间。在规模效应下所能实现的收益正在迅速递减。
更新于[2026-06-15]
文章参考