前端系统设计是什么？前端系统设计的思考架构

本篇详细解说本收录在 E+ 的前端系统设计专题

过去两篇前端系统设计主题内容，我们分别讨论了前端系统设计 - 设计聊天系统 (Chat System)，以及前端系统设计 - 设计即时共编文件系统 (Collaborative Editor) 。这一篇我们将往后退一步，来聊聊前端的系统设计，有哪些应该要思考的点当能掌握这些思考点，未来面对不同的前端要设计，都能够更有架构地思考与应对。

前端系统设计是什么?

一般提到系统设计，多数人可能第一时间会想到软体工程师面试常见的系统设计，这类系统设计会需要针对某个场景 (例如设计短网址服务、设计脸书的动态墙、设计 YouTube)，去设计可扩展、高可用、高效能的分散式系统。在这类系统设计中，具体会牵涉到我们在系统设计五大心法：水平扩张、快取、非同步、避免单点故障、监控一文谈到的水平扩张、快取、非同步、避免单点故障、监控等概念。

而这类面试通常会是通用软体工程师 (general software engineer)，或者后端工程师、全端工程师，相对比较常会遇到。而对于前端工程师，则是更常会遇到前端系统设计。

前端系统设计某部分与上述的软体工程系统设计重叠，问的问题也是类似 (例如设计脸书动态墙、设计 YouTube)，但又有其独特的部分。举例来说，前端的架构、前端的技术取舍，以及前端要特别侧重的前端效能、使用体验、无障碍 (a11y)、国际化 (i18n)，这些对前端工程师重要，但一般通用系统设计不会问到的问题。

关于前端要侧重的面向，非常推荐 React 核心团队 Dan Abramov 之前写的《The Elements of UI Engineering》一文，该文详尽地解析了重点面向。

前端系统设计的思考架构

在了解完侧重点后，接着来聊如何展开前端的系统设计。不论是在实际工作上，或者是在面试，能够主动去引导并完成前端系统设计，是迈向资深不可或缺的。

目前业界比较多使用的前端系统设计框架是由 GreatFrontEnd 作者提出的 RADIO 框架，该思考架构如下

Requirement 需求探索
Architecture 架构建立
Data 资料模型
Interface 接口定义
Optimization 深入优化

需求探索

如同后端系统设计，前端系统设计也推荐从需求探索开始，根据不同的问题，要去厘清任何不清楚的地方。比较推荐的做法，是戴上产品经理的帽子，试着从产品经理的角度去思考。

前端系统设计在问厘清问题时，会分为功能需求与非功能需求。以动态墙为例，功能需求会包含动态墙具体要有的元素，例如动态是纯文字或支援多媒体，或者是纯展示或会支援留言与按赞。

而非功能需求则是即使没做，产品还是能用，只是可能体验不会是最好。以动态墙来说，非功能需求可能包含无限滚动 (infinite scrolling) 、虚拟化展示 (virtualization)，或者要不要支援离线浏览。

在这个阶段，是在检验你「是否能有效面对模糊情境」。在实际工作上，很多时候产品经理的思考会需要工程端的协助，来考虑更全面，这时需要工程端协助厘清问题，或者更深入去想执行细节要考量的面向。理想上，在跟产品经理过需求时，前端工程师要详读需求，然后把任何不够具体、不够清楚的地方，都留言提问。

而在面试，面试官则会刻意不在一开始就给所有资讯，因为会想测验候选人是否会主动去厘清。因此在遇到要设计的系统时，这个步骤千万不能省略！

总结来说，在需求探索，请务必确保自己有做到

能对要解决的问题有清楚的理解，任何模糊不清的地方都会追问
功能与非功能需求，都需要涵盖到
有进一步收敛什么是最重要的问题 (确保接下来的讨论都能在核心上)

架构建立

在厘清完需求后，接着要做的，会是根据需求提出前端设计。而要能够有效沟通，在最开始推荐先从架构面着手。所谓的架构，就是要展开一个系统中所需要的元素、各个元素扮演什角色，以及各元素彼此如何交互，以让系统能完整运行。

从前端的角度来看，常见的架构包含 MVC，Model 是存放资料的地方，View 是展示的地方，而 Controller 是控制逻辑的地方。而除了前端的 MVC 彼此的互动外，还需要有跟后端伺服器的交互 (例如常见的 HTTP 或者 WebSocket)。

或者是单一资料流的 Flux 架构，Flux 架构有存放资料的 Store，以及展示 UI 的 View，透过在画面上的操作，会由 Dispatcher 发送 Action 来改动资料存放的 Store，而 View 在根据更新后的 Store 来展示新的内容。

不论是 MVC 或 Flux 或其他常见的架构，没有哪个绝对比其他架构好。需要在了解完需求后，根据需求提出最合适的架构方式。

更进一步说，如果要让架构完整，就会需要去考量更广的元素，例如前端要做监控，如果有任何 JavaScript 错误，或者画面变成白屏，会需要第一时间触发监控的警告，而这就需要有前端监控的元素在架构图中。

又或者有些前端的控制，不想要写死在前端的应用中，希望用配置的方式 (config-driven)，那就会需要有一个键值的外部机制 (key-value store) 能够轻松地去操作 (例如社群中许多人用的 LaunchDarkly )。

架构图要广可以到很广，像是现代许多前端开发也都会导入 A/B 测试，或者是使用者行为资料的搜集 (例如 Google Analytics)，都可能是前端架构图中的一个元素。至于究竟要包含到什么元素，就需要在最开始去厘清，这也是为什么说需求厘清是非常非常重要的。

特别注意，工作时开发新产品，可以先就大方向进行讨论，确保整体逻辑通顺后，再往下进行深入讨论 (详后面会提到的深入优化)。如果是在面试中，可以先跟面试官讨论要展开到什么程度，然后再把完整的架构图画出来。

总结来说，在架构建立，请务必确保自己有做到

有针对上一步骤的需求，提出相对应的解决方案
提出的架构，能完整呼应需求，该有的要素都需要有
架构有考量到未来的扩展，能以复用、最小改动方式来支援新需求

本文为 E+ 成长计划的深度内容，截取前三分之一开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)