i18n: update guides
This commit is contained in:
Yangshun
parent
a02793fdbd
commit
10f589c885
|
|
@ -48,8 +48,8 @@ description: 前端/网络开发人员/软件工程师的行为面试指南，
|
|||
|
||||
除此之外，面试官通常鼓励利用跟进问题深入了解候选人的实际动机和理解其表面行动背后的原因。
|
||||
|
||||
1. 你为什么认为你做了(行为)？
|
||||
2. 你为什么不做(行为)？
|
||||
1. 您认为您为什么会这样做？
|
||||
2. 你为什么不那样做？
|
||||
3. 你会怎么在后见之明中改变事情？
|
||||
|
||||
因此，候选人还应准备对每种行动方式的利与弊有扎实的了解，并反思自己的内在动机。
|
||||
|
|
|
|||
|
|
@ -114,8 +114,8 @@ description: 描述：学习如何回答有关前端/网络开发人员/软件
|
|||
- 在合并拉取请求之前运行性能基准测试。
|
||||
- 惰性加载非关键组件，惰性加载屏幕下方内容。
|
||||
- 在页面级别上拆分JavaScript，而不是单独的包（由Next.js处理）。
|
||||
- 对图像使用WebP格式。
|
||||
- 将图像托管在CDN上，Adaptive加载图像，因此移动设备加载较小的图像，合并重复的JavaScript库（data-fns和moment.js），切换到lodash-es，删除了所有jQuery的用法-查看数据以识别不常用的功能并将其从产品详细信息页的代码中删除，JS大小减少了200个+ kb。
|
||||
- 对图片使用WebP格式。
|
||||
- 将图片托管在CDN上，Adaptive加载图片，因此移动设备加载较小的图片，合并重复的JavaScript库（data-fns和moment.js），切换到lodash-es，删除了所有jQuery的用法-查看数据以识别不常用的功能并将其从产品详细信息页的代码中删除，JS大小减少了200个+ kb。
|
||||
- **搜索引擎优化（SEO）**
|
||||
- 使用SEO工具（例如Ahrefs）持续监测SEO。
|
||||
- 与营销团队合作，确保营销内容包含Ahrefs显示的重要关键字。
|
||||
|
|
@ -149,8 +149,8 @@ description: 描述：学习如何回答有关前端/网络开发人员/软件
|
|||
|
||||
正如我们在[行为面试准备概述]中所提到的，面试官鼓励依靠后续问题更多地了解候选人的思考过程和动机，这些后续问题通常属于以下类别：
|
||||
|
||||
- 你为什么认为你做了(行为)？
|
||||
- 你为什么不做(行为)？
|
||||
- 您认为您为什么会这样做？
|
||||
- 你为什么不那样做？
|
||||
- 如果换成后见之明，你会如何做事情？
|
||||
|
||||
在解决问题或实现结果的问题上，面试官最有可能探究这样的问题，以帮助他们更好地了解候选人：
|
||||
|
|
|
|||
|
|
@ -45,14 +45,12 @@ description: 前端开发人员/网络开发人员/软件工程师应该练习
|
|||
|
||||
我们将最常见的行为问题归纳为8大主题。 在学习时查看更多的练习题：
|
||||
|
||||
- “介绍一下你自己…” (/behavioral-interview-guidebook/self-introduction)
|
||||
- [“介绍一下你自己…”] \(/behavioral-interview-guidebook/self-introduction)
|
||||
- “让我来看一下你的简历…”
|
||||
- “为什么加入这个团队或公司？
|
||||
” (/behavioral-interview-guidebook/why-work-here)
|
||||
- “你有什么问题要问我的吗？
|
||||
” (/behavioral-interview-guidebook/questions-to-ask)
|
||||
- [“为什么加入这个团队或公司？”] \(/behavioral-interview-guidebook/why-work-here)
|
||||
- [“你有什么问题要问我的吗？”] \(/behavioral-interview-guidebook/questions-to-ask)
|
||||
- "当你...... 的时候告诉我" （分类为以下主题）
|
||||
- 实现目标和解决问题(/behavioral-interview-guidebook/problem-solving)
|
||||
- 合作(/behavioral-interview-guidebook/collaboration)
|
||||
- [实现目标和解决问题](/behavioral-interview-guidebook/problem-solving)
|
||||
- [合作](/behavioral-interview-guidebook/collaboration)
|
||||
- [成长心态](/behavioral-interview-guidebook/growth-mindset)
|
||||
- 适应能力和灵活性
|
||||
|
|
|
|||
|
|
@ -79,12 +79,12 @@ description: 如何在不同的面试背景下有效地构建你的面试自我
|
|||
|
||||
在特定角色的要求之上，如团队特定的框架和技术，前端招聘经理通常关注以下**4个标准**：
|
||||
|
||||
| 标准 | 例子 |
|
||||
| ---------------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| 了解前端的基本原理：HTML、CSS、JavaScript和相关领域 | "我建立前端应用程序已经有几年了，也为Lodash和jQuery等流行的开源项目做出了贡献。" <br/><br/>"我是我的大学的网络开发课程的教学助理，指导学生从事涉及建立全栈网络应用的项目。" |
|
||||
| 候选人了解的前端技术的广度和深度 | "我使用React、Tailwind、Next.js、Prisma和MySQL建立一个Twitter克隆，作为我的软件工程团队项目的一部分。" |
|
||||
| 主动跟上现代前端技术的步伐 | "我学习了Astro，并使用它重建了我的个人博客，因为Astro对于建立内容驱动的网站非常好。" |
|
||||
| 候选人从事过的相关前端项目，这些项目的复杂性 | "在业余时间，我在React中建立了一个加密货币价格跟踪应用程序，以学习如何建立数据可视化重的客户应用程序，也解决了跟踪我的投资组合的个人痛点。" |
|
||||
| 标准 | 例子 |
|
||||
| ---------------------------------- | ----------------------------------------------------------------------------------------------------- |
|
||||
| 了解前端的基本原理：HTML、CSS、JavaScript和相关领域 | "我建立前端应用程序已经有几年了，也为Lodash和jQuery等流行的开源项目做出了贡献。" <br/><br/>"我是我的大学的网络开发课程的教学助理，指导学生从事涉及建立全栈Web 应用的项目。" |
|
||||
| 候选人了解的前端技术的广度和深度 | "我使用React、Tailwind、Next.js、Prisma和MySQL建立一个Twitter克隆，作为我的软件工程团队项目的一部分。" |
|
||||
| 主动跟上现代前端技术的步伐 | "我学习了Astro，并使用它重建了我的个人博客，因为Astro对于建立内容驱动的网站非常好。" |
|
||||
| 候选人从事过的相关前端项目，这些项目的复杂性 | "在业余时间，我在React中建立了一个加密货币价格跟踪应用程序，以学习如何建立数据可视化重的客户应用程序，也解决了跟踪我的投资组合的个人痛点。" |
|
||||
|
||||
请参考下面好的自我介绍的例子。
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Although algorithmic coding questions aren't specific to front end, the skills n
|
|||
|
||||
There are a ton of resources out there that cover algorithmic coding interviews and since they are not specific to front end, we won't go into too much detail on this page. We recommend referring to [Tech Interview Handbook](https://www.techinterviewhandbook.org) as a free resource if you would like to learn more about algorithmic coding interviews.
|
||||
|
||||
## Exemplos
|
||||
## Examples
|
||||
|
||||
- Reverse a linked list.
|
||||
- Determine if a string contains balanced brackets.
|
||||
|
|
|
|||
|
|
@ -38,11 +38,11 @@ At certain companies, you could be asked to write all required code on the white
|
|||
|
||||
Here's a summary of the various coding environments and what you can do:
|
||||
|
||||
| Environment | Preview | Execute Code | Add 3rd Party Dependencies |
|
||||
| ------------------ | -------- | ------------- | --------------------------- |
|
||||
| Online code editor | Não | Situational | Usually no |
|
||||
| IDEs | Sim | Sim | Sim |
|
||||
| Whiteboard | Não | Não | Não |
|
||||
| Environment | Preview | Execute Code | Add 3rd Party Dependencies |
|
||||
| ------------------ | ------- | ------------ | -------------------------- |
|
||||
| Online code editor | No | Situational | Usually no |
|
||||
| IDEs | Yes | Yes | Yes |
|
||||
| Whiteboard | No | No | No |
|
||||
|
||||
## General Coding Tips
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ These JavaScript coding questions tend to be practical in nature and can come in
|
|||
1. Implement standard built-in classes or methods in the JavaScript language.
|
||||
2. Implement a utility function/class commonly found in popular libraries.
|
||||
|
||||
## Exemplos
|
||||
## Examples
|
||||
|
||||
### JavaScript Standard Built-in Classes/methods
|
||||
|
||||
|
|
|
|||
|
|
@ -16,15 +16,15 @@ description: 为前端/网站开发人员面试准备JavaScript问题的指南
|
|||
|
||||
当他们已经成为语言的一部分时，实现标准类/方法可能看起来有些多余。 然而，浏览器不一致曾经是一个普遍的问题，并且一些语言API在旧浏览器中找不到。 当他们已经成为语言的一部分时，实现标准类/方法可能看起来有些多余。 然而，浏览器不一致曾经是一个普遍的问题，并且一些语言API在旧浏览器中找不到。 因此，开发人员不得不通过在下载的JavaScript中实现这些API来进行填充。 能够实现这些本地函数还显示了对前端基础知识的良好理解。 能够实现这些本地函数还显示了对前端基础知识的良好理解。
|
||||
|
||||
- `Array` 方法：[`Array.prototype.map`]（/questions/javascript/array-map），[`Array.prototype.reduce`]（/questions/javascript/array-reduce），[`Array.prototype.filter`]（/questions/javascript/array-filter）。
|
||||
- `Promise` 和其他`Promise`相关函数：[`Promise.all`]（/questions/javascript/promise-all），[`Promise.any`]（/questions/javascript/promise-any）。
|
||||
- DOM方法：[`document.getElementsByTagName`]（/questions/javascript/get-elements-by-tag-name），[`document.getElementsByClassName`]（/questions/javascript/get-elements-by-class-name）。
|
||||
- `Array` 方法：[`Array.prototype.map`](/questions/javascript/array-map)，[`Array.prototype.reduce`](/questions/javascript/array-reduce)，[`Array.prototype.filter`](/questions/javascript/array-filter)。
|
||||
- `Promise` 和其他`Promise`相关函数：[`Promise.all`](/questions/javascript/promise-all)，[`Promise.any`](/questions/javascript/promise-any)。
|
||||
- DOM方法：[`document.getElementsByTagName`](/questions/javascript/get-elements-by-tag-name)，[`document.getElementsByClassName`](/questions/javascript/get-elements-by-class-name)。
|
||||
|
||||
这些函数远非显而易见的那么简单。 这些函数远非显而易见的那么简单。 让我们以无辜的`Array.prototype.map`为例。 您是否知道： 您是否知道：
|
||||
|
||||
1. 它传递4个参数给回调函数，包括' index '和'this '？
|
||||
2. 它保留稀疏数组中的“孔”，即[1,2,4].map（val=>val\*val）=== [1,4，，16]。
|
||||
3. 3、`map`处理的元素范围在第一个调用_callbackfn_之前设置。 `map`处理的元素范围在第一个调用_callbackfn_之前设置。 在调用map之后附加到数组中的元素将不会被_callbackfn_访问。 如果更改数组的现有元素，则将它们的值作为传递给_callbackfn_的值在`map`访问它们时。 来源：[Array.prototype.map ECMAScript说明]（https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array.prototype.map） 如果更改数组的现有元素，则将它们的值作为传递给_callbackfn_的值在`map`访问它们时。 来源：[Array.prototype.map ECMAScript说明]（https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array.prototype.map）
|
||||
1. 它传递4个参数给回调函数，包括 `index` 和 `this` ？
|
||||
2. 它保留稀疏数组中的“空”，即 `[1, 2, , 4].map(val => val * val) === [1, 4, , 16]`。
|
||||
3. `map`处理的元素范围在第一个调用_callbackfn_之前设置。 在调用map之后附加到数组中的元素将不会被_callbackfn_访问。 如果更改数组的现有元素，则将它们的值作为传递给_callbackfn_的值在`map`访问它们时。 来源：[Array.prototype.map ECMAScript说明]（https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array.prototype.map）
|
||||
|
||||
您的实施不必处理所有这些情况，特别是数组突变的情况。 但是，如果您提到了这些情况，那么这是一个积极的信号。 您的实现越接近规范，您就会显得更加资深/有经验。
|
||||
|
||||
|
|
@ -32,12 +32,12 @@ description: 为前端/网站开发人员面试准备JavaScript问题的指南
|
|||
|
||||
这些函数/类在使用JavaScript构建软件时通常需要，但不在标准语言中（目前）。
|
||||
|
||||
- Lodash/Underscore函数：[`debounce`]（/questions/javascript/debounce），[`throttle`]（/questions/javascript/throttle），[`flatten`]（/questions/javascript/flatten），[`curry`]（/questions/javascript/curry），[`cloneDeep`]（/questions/javascript/deep-clone）。
|
||||
- jQuery方法：[`jQuery.css`]（/questions/javascript/jquery-css），[`jQuery.toggleClass`]（/questions/javascript/jquery-class-manipulation）。
|
||||
- Lodash/Underscore函数：[`debounce`](/questions/javascript/debounce)，[`throttle`](/questions/javascript/throttle)，[`flatten`](/questions/javascript/flatten)，[`curry`](/questions/javascript/curry)，[`cloneDeep`](/questions/javascript/deep-clone)。
|
||||
- jQuery方法：[`jQuery.css`](/questions/javascript/jquery-css)，[`jQuery.toggleClass`](/questions/javascript/jquery-class-manipulation)。
|
||||
- 流行的库：
|
||||
- [`classnames`](/questions/javascript/classnames)
|
||||
- 测试框架（如[Jest]（https://jestjs.io/）/ [Mocha]（https://mochajs.org/））中的“test”/“expect”函数。
|
||||
- [`Emitter`]（/questions/javascript/event-emitter）（它存在于Node.js和许多第三方库中）
|
||||
- 测试框架（如[Jest](https://jestjs.io/) / [Mocha](https://mochajs.org/)）中的“test”/“expect”函数。
|
||||
- [`Emitter`](/questions/javascript/event-emitter)（它存在于Node.js和许多第三方库中）
|
||||
- [Immutable.js](https://immutable-js.com/)
|
||||
- [Backbone.js](https://backbonejs.org/)
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ description: 为前端/网站开发人员面试准备JavaScript问题的指南
|
|||
|
||||
## JavaScript编码面试期间要做的事情
|
||||
|
||||
JavaScript编码面试与算法编码面试有许多相似之处。 一般来说，你应该： 一般来说，你应该：
|
||||
JavaScript编码面试与算法编码面试有许多相似之处。 一般来说，你应该：
|
||||
|
||||
1. 查找您正在编码的平台，并熟悉编码环境：
|
||||
- 支持的编辑器快捷键。
|
||||
|
|
@ -56,7 +56,7 @@ JavaScript编码面试与算法编码面试有许多相似之处。 一般来说
|
|||
- 您可以使用更新的JavaScript语法（ES2016及更高版本）吗？
|
||||
- 代码是要运行在浏览器上还是服务器上（例如Node.js）。
|
||||
- 浏览器支持，因为这将影响您可以使用的浏览器API。
|
||||
4. 向面试官提出解决方案。 向面试官提出解决方案。 与编码面试不同，JavaScript编码面试的重点通常不在复杂的数据结构和算法上。 通过最佳的数据结构和算法选择，可能可以直接跳转到最佳解决方案。 通过最佳的数据结构和算法选择，可能可以直接跳转到最佳解决方案。
|
||||
4. 向面试官提出解决方案。 与编码面试不同，JavaScript编码面试的重点通常不在复杂的数据结构和算法上。 通过最佳的数据结构和算法选择，可能可以直接跳转到最佳解决方案。
|
||||
5. 编写解决方案并在编码时向面试官解释您的代码。
|
||||
6. 编码后，一次阅读您的代码，尝试检测基本错误，例如拼写错误，在初始化变量之前使用变量，不正确使用API等。
|
||||
7. 概述一些基本测试用例和一些边缘情况。 使用这些情况测试您的代码，并确定您的代码是否通过了它们。 如果失败，请调试问题并修复它们。
|
||||
|
|
@ -66,8 +66,8 @@ JavaScript编码面试与算法编码面试有许多相似之处。 一般来说
|
|||
|
||||
## JavaScript编码面试规则
|
||||
|
||||
1. 通过参考下面的“重要概念”熟悉HTML、CSS、JavaScript和DOM概念。 [Quiz section]（/front-end-interview-guidebook/quiz）也可以是一个好的开始，因为您可能会以测验问题的形式被问到这些概念。
|
||||
2. 选择[学习计划]（/get-started）并练习所选学习计划推荐的[JavaScript编码问题]（/questions/js/coding/utilities）。 在做问题的同时，也可以学习某个主题。
|
||||
1. 通过参考下面的“重要概念”熟悉HTML、CSS、JavaScript和DOM概念。 [测验部分](/front-end-interview-guidebook/quiz) 也可以是一个好的开始，因为您可能会以测验问题的形式被问到这些概念。
|
||||
2. 选择[学习计划](/get-started)并练习所选学习计划推荐的[JavaScript编码问题](/questions/js/coding/utilities)。 在做问题的同时，也可以学习某个主题。
|
||||
|
||||
## 重要概念
|
||||
|
||||
|
|
@ -75,9 +75,9 @@ JavaScript编码面试与算法编码面试有许多相似之处。 一般来说
|
|||
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 数据结构 | 数组、地图、堆栈、树、套装 |
|
||||
| 算法 | 二进制搜索、广度优先搜索、深度优先搜索、递归 |
|
||||
| JavaScript语言 | 数据类型（检查类型、类型强制转换）、范围、闭合、回调、如何使用此处关键字、面向对象编程（原型、类、方法），箭头函数与普通函数、通过'Function.prototype.apply（）' / 'Function.prototype.call（）'调用函数，'Promise'，处理多参数 |
|
||||
| JavaScript语言 | 数据类型（检查类型、类型强制转换）、范围、闭合、回调、如何使用此处关键字、面向对象编程（原型、类、方法），箭头函数与普通函数、通过`Function.prototype.apply()` / `Function.prototype.call()`调用函数，`Promise`，处理多参数 |
|
||||
| DOM | DOM遍历、DOM创建、DOM操作、访问元素/节点属性、事件委托 |
|
||||
| 运行时API | 计时器（“setTimeout”、“setInterval”） |
|
||||
| 运行时API | 计时器（`setTimeout`、`setInterval`） |
|
||||
|
||||
## 如何准备JavaScript编码面试
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ JavaScript编码面试类似于算法编码面试，应该采用相似的方法
|
|||
|
||||
- **虚构的想法**。 JavaScript的标准库没有一些有用的数据结构和算法，例如队列、堆、二分搜索，这可以使您在JavaScript编码面试期间更轻松。 然而，您可以询问面试官是否可以假装这样的数据结构/算法存在，并直接在解决方案中使用它，而无需实现它。
|
||||
- **纯函数**。 编写纯函数，这些函数具有可重用和可插入性的好处，即函数不依赖于函数外的状态，并且不会产生副作用。
|
||||
- **明智地选择数据结构**。注意您选择数据结构的选择，并了解代码的时间复杂度。 如果要在解决方案中使用基本JavaScript数组、对象、集合、映射操作，应熟悉这些时间/空间复杂度。 这些时间/空间复杂度在不同的语言中可能有所不同。 不要编写运行时间为O（n<sup>2</sup>）的代码，如果可以使用哈希图来在O（n）运行时间内完成操作，则可以避免此类情况。
|
||||
- **明智地选择数据结构**。注意您选择数据结构的选择，并了解代码的时间复杂度。 如果要在解决方案中使用基本JavaScript数组、对象、集合、映射操作，应熟悉这些时间/空间复杂度。 这些时间/空间复杂度在不同的语言中可能有所不同。 不要编写运行时间为O(n<sup>2</sup>)的代码，如果可以使用哈希图来在O(n)运行时间内完成操作，则可以避免此类情况。
|
||||
- **`this`很重要**。 如果一个函数接受回调函数作为参数，请考虑`this`变量应该如何行动。 对于许多内置函数，`this`是回调函数调用时提供的参数之一。
|
||||
- **回调函数内的突变**。注意回调函数突变正在处理的数据结构。 您可能不需要在面试期间处理此情况，但应在相关情况下明确提出此类情况。
|
||||
- **递归边缘案例**。
|
||||
|
|
@ -104,16 +104,16 @@ JavaScript编码面试类似于算法编码面试，应该采用相似的方法
|
|||
|
||||
从经验上看，在频率和涵盖的重要概念方面，最佳的JavaScript编码面试问题是：
|
||||
|
||||
- [`Debounce`]（/questions/javascript/debounce）
|
||||
- [`Throttle`]（/questions/javascript/throttle）
|
||||
- [`Array.prototype.filter`]（/questions/javascript/array-filter）
|
||||
- [`Promise.all`]（/questions/javascript/promise-all）
|
||||
- [`Curry`]（/questions/javascript/curry）
|
||||
- [`Flatten`]（/questions/javascript/flatten）
|
||||
- [`getElementsByTagName`]（/questions/javascript/get-elements-by-class-name）
|
||||
- [`Deep Clone`]（/questions/javascript/deep-clone）
|
||||
- [`Data Selection`]（/questions/javascript/data-selection）
|
||||
- [Debounce](/questions/javascript/debounce)
|
||||
- [Throttle](/questions/javascript/throttle)
|
||||
- [Array.prototype.filter](/questions/javascript/array-filter)
|
||||
- [Promise.all](/questions/javascript/promise-all)
|
||||
- [Curry](/questions/javascript/curry)
|
||||
- [Flatten](/questions/javascript/flatten)
|
||||
- [getElementsByTagName](/questions/javascript/get-elements-by-class-name)
|
||||
- [Deep Clone](/questions/javascript/deep-clone)
|
||||
- [Data Selection](/questions/javascript/data-selection)
|
||||
|
||||
GreatFrontEnd有[全面的JavaScript编码问题列表]（/questions/js/coding/utilities），您可以练习。 还有可以运行您的代码以验证正确性的自动化测试用例，以及由前FAANG资深工程师编写的解决方案。
|
||||
GreatFrontEnd有[全面的JavaScript编码问题列表](/questions/js/coding/utilities)，您可以练习。 还有可以运行您的代码以验证正确性的自动化测试用例，以及由前FAANG资深工程师编写的解决方案。
|
||||
|
||||
请注意，我们在某些问题中故意含糊不清，并没有在问题说明中全面介绍要求。 但是，我们将在解决方案中涵盖尽可能多的方面。 在阅读解决方案时，如果您发现错过了一些内容，可能会感到沮丧，但是这可以锻炼您的提前思考，并考虑在解决方案工作时需要注意哪些可能区域。 最好在练习期间找出，而不是在实际面试中发现。
|
||||
|
|
|
|||
|
|
@ -109,18 +109,18 @@ Here's a summary of the question types asked by the top US companies.
|
|||
|
||||
| Company | Quiz | Algorithms | JavaScript | UI | System Design | Behavioral |
|
||||
| :------------ | :-----: | :--------: | :--------: | :-: | :-----------: | :--------: |
|
||||
| Airbnb | Não | Sim | Sim | Sim | Não | Sim |
|
||||
| Amazon | Sim | Sim | Sim | Sim | Sim | Sim |
|
||||
| Apple | Sim | Sim | Sim | Sim | Unknown | Sim |
|
||||
| ByteDance | Sim | Sim | Sim | Sim | Não | Sim |
|
||||
| Dropbox | Não | Sim | Sim | Sim | Sim | Sim |
|
||||
| Facebook/Meta | Sim | Não | Sim | Não | Sim | Sim |
|
||||
| Google | Sim | Sim | Sim | Sim | Sim | Sim |
|
||||
| LinkedIn | Sim | Sim | Sim | Sim | Unknown | Sim |
|
||||
| Lyft | Não | Não | Sim | Sim | Sim | Sim |
|
||||
| Microsoft | Sim | Sim | Sim | Sim | Sim | Sim |
|
||||
| Twitter | Sim | Sim | Sim | Sim | Sim | Sim |
|
||||
| Uber | Unknown | Unknown | Sim | Sim | Unknown | Sim |
|
||||
| Airbnb | No | Yes | Yes | Yes | No | Yes |
|
||||
| Amazon | Yes | Yes | Yes | Yes | Yes | Yes |
|
||||
| Apple | Yes | Yes | Yes | Yes | Unknown | Yes |
|
||||
| ByteDance | Yes | Yes | Yes | Yes | No | Yes |
|
||||
| Dropbox | No | Yes | Yes | Yes | Yes | Yes |
|
||||
| Facebook/Meta | Yes | No | Yes | No | Yes | Yes |
|
||||
| Google | Yes | Yes | Yes | Yes | Yes | Yes |
|
||||
| LinkedIn | Yes | Yes | Yes | Yes | Unknown | Yes |
|
||||
| Lyft | No | No | Yes | Yes | Yes | Yes |
|
||||
| Microsoft | Yes | Yes | Yes | Yes | Yes | Yes |
|
||||
| Twitter | Yes | Yes | Yes | Yes | Yes | Yes |
|
||||
| Uber | Unknown | Unknown | Yes | Yes | Unknown | Yes |
|
||||
|
||||
**Question Type Legend**
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: Guide to preparing for quiz-style front end interview questions —
|
|||
|
||||
Quiz questions, also known as trivia questions, are short close-ended questions meant to test your understanding of the domain. Each question shouldn't take more than a minute or two to answer, however, further discussions can be spawned from your answers. Hence it's important to have good understanding of the concepts behind the answers you give and not blindly memorize and regurgitating.
|
||||
|
||||
## Exemplos
|
||||
## Examples
|
||||
|
||||
- [Explain what the CSS box model is.](/questions/quiz/explain-your-understanding-of-the-box-model-and-how-you-would-tell-the-browser-in-css-to-render-your-layout-in-different-box-models)
|
||||
- [What is CSS selector specificity?](/questions/quiz/what-is-css-selector-specificity-and-how-does-it-work)
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ It is common for people to make the mistake of not providing enough details abou
|
|||
Here's a non-exhaustive list of front end-related technical achievements that are suitable to be mentioned:
|
||||
|
||||
- **Product work**: Elaborate on the features built within a product.
|
||||
- **Performance**: Performance improvements made and the resulting gains in percentage. Ex. page load size, page load time, Lighthouse score improvements, etc.
|
||||
- **Performance**: Performance improvements made and the resulting gains in percentage. E.g. page load size, page load time, Lighthouse score improvements, etc.
|
||||
- **Testing**: Number of tests written, how many critical flows they cover, % increase in test coverage.
|
||||
- **SEO**: % or numerical reduction in SEO errors/warnings. This metric is easy to obtain if the company uses SEO tools like Ahrefs and Semrush.
|
||||
- **Accessibility (a11y)**: Number of a11y errors fixed, number of flows that were improved to meet WCAG AA/AAA level conformance, number of components where a11y improved.
|
||||
|
|
@ -95,6 +95,6 @@ The front end domain advances pretty fast with new JavaScript frameworks and CSS
|
|||
|
||||
Open source contributions, especially non-trivial changes to complex code bases are seen as a sign of technical competency. Even better if you have created or are a maintainer of open source projects.
|
||||
|
||||
## Resumo
|
||||
## Summary
|
||||
|
||||
While [Tech Interview Handbook's general Software Engineer resume tips](https://www.techinterviewhandbook.org/resume/) are mostly sufficient for Front End Engineers, the tips above will help you to elevate your Front End Engineer resume and bring it to the next level.
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ description: 提高你的前端开发者/网页开发者的简历，以获得面
|
|||
|
||||
像React这样的库对其他相关技术选择产生了很大影响，而像Underscore/Lodash这样的库与架构无关，可以轻易地被替换掉。 优先考虑前者，省略小型/实用库，这些库易于替换。
|
||||
|
||||
### 3. 广为人知或快速 gaining popularity
|
||||
### 3. 广为人知或迅速走红
|
||||
|
||||
这表明你跟上了现代前端生态系统的发展。 公司也可能正在考虑迁移到该技术，如果您在该技术方面有经验，这是一个加分项。
|
||||
|
||||
|
|
|
|||
|
|
@ -18,4 +18,4 @@ GreatFrontEnd包括许多前端系统设计案例研究和真实世界的例子
|
|||
- [新闻动态（例如Facebook）](/questions/system-design/news-feed-facebook)
|
||||
- [自动完成组件](/questions/system-design/autocomplete)
|
||||
- [电子商务网站（例如亚马逊）](/questions/system-design/e-commerce-amazon)
|
||||
- [图像轮播](/questions/system-design/image-carousel)
|
||||
- [图片轮播](/questions/system-design/image-carousel)
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ React迫使你把UI写成包含其自身逻辑和外观的组件。 React组件
|
|||
|
||||
```js
|
||||
function Slider({ min, max }) {
|
||||
// Use the props to render a customized component.
|
||||
// 使用 props 来呈现自定义组件。
|
||||
return <div>...</div>;
|
||||
}
|
||||
|
||||
|
|
@ -71,9 +71,9 @@ import { createRoot } from 'react-dom/client';
|
|||
import Slider from './Slider';
|
||||
|
||||
const domNode = document.getElementById('#gfe-slider');
|
||||
// React will manage the DOM within this element.
|
||||
// React 将管理此元素内的 DOM。
|
||||
const root = createRoot(domNode);
|
||||
// Display the Slider component within the element.
|
||||
// 在元素内显示 Slider 组件。
|
||||
root.render(<Slider max={50} min={10} />);
|
||||
```
|
||||
|
||||
|
|
@ -360,7 +360,7 @@ function Slider({ value, label }) {
|
|||
|
||||
### 避免用某种语言对标签进行硬编码
|
||||
|
||||
一些UI组件内有标签字符串（例如，图像轮播有上一个/下一个按钮的标签）。 如果能让这些标签字符串成为组件props/options的一部分，允许自定义这些标签字符串就更好了。
|
||||
一些UI组件内有标签字符串（例如，图片轮播有上一个/下一个按钮的标签）。 如果能让这些标签字符串成为组件props/options的一部分，允许自定义这些标签字符串就更好了。
|
||||
|
||||
### 从右到左的语言
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Is your CSS written in a scalable and easy-to-understand manner?
|
|||
- **Avoid `#id` selectors in components**: When building UI components meant to be reused (e.g. buttons, tabs, menus, modals, etc), avoid using `#id` selectors in the HTML as `id`s are meant to be globally unique but you can have multiple instances of the component.
|
||||
- **Organize your CSS**: Read about how to [organize your CSS in big projects](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Organizing) and how to have a [Scalable and Modular Architecture for CSS](http://smacss.com/).
|
||||
|
||||
## Experiência de Usuário
|
||||
## User Experience
|
||||
|
||||
Does your UI provide a great user experience?
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ Does your UI provide a great user experience?
|
|||
- `<img>` tags have a similar `object-fit` property with `contain` and `cover` values.
|
||||
- **Optimistic updates**: Advanced technique where the success state is reflected even though the network request is still pending. If the request fails, revert the UI changes and show an error message.
|
||||
|
||||
## Rede
|
||||
## Network
|
||||
|
||||
Does your UI handle the unpredictable nature of network requests and conditions?
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ Does your UI handle the unpredictable nature of network requests and conditions?
|
|||
- **Request timeouts**: You might want to artificially show that the request has failed (timed out) if the request doesn't receive a response after a stipulated duration.
|
||||
- **Optimistic updates**: Advanced technique where the success state is reflected even though the network request is still pending. If the request fails, revert the UI changes and show an error message.
|
||||
|
||||
## Acessibilidade (a11y)
|
||||
## Accessibility (a11y)
|
||||
|
||||
Handling accessibility in UI is a huge plus and in some cases a requirement for senior engineers.
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ There's probably not enough time to handle all edge cases scenarios in your code
|
|||
- Truncate the excess content and show an ellipsis. The `word-break` CSS property will come in handy useful.
|
||||
- Limit the content to the first X characters/words and hide the excess content behind a "Show More" button.
|
||||
|
||||
## Desempenho
|
||||
## Performance
|
||||
|
||||
- **Throttle/debounce**: Throttle and debounce are rate limiting techniques to prevent unnecessary operations. This technique can be used for operations which aren't super time-sensitive like network requests and scroll/resizing event callbacks.
|
||||
- **Caching**: The results of duplicate computations / network requests can be cached in browser memory/storage and not repeated.
|
||||
|
|
@ -145,7 +145,7 @@ There's probably not enough time to handle all edge cases scenarios in your code
|
|||
- **Prefetch/preload data**: Reduce network latency by prefetching/preloading data right before it is needed so that updates appear instantly.
|
||||
- **Too many items in a list**: Refer to the point under "Edge Cases" above.
|
||||
|
||||
## Segurança
|
||||
## Security
|
||||
|
||||
- **Cross-site Scripting (XSS)**: Avoid assigning to [`Element.innerHTML`](https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML) or React's `dangerouslySetInnerHTML` when rendering contents into the DOM if it comes from users to prevent cross-site scripting, assign to [`Node.textContent`](https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent) or use the experimental[`Element.setHTML()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML) method instead. Refer to [OWASP's XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
|
||||
- **Output encoding for "URL Contexts"**: If user-supplied input can be used in URL query parameters, use `encodeURIComponent` to prevent unintended values from becoming part of the URL (e.g. extra query parameters).
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ description: 在前端/网络开发人员面试时，改善你必须建立的用
|
|||
- **确定UI中所需的最小状态**: 状态越小，代码的可读性和理解能力就越强 -> 减少错误的可能性。
|
||||
- 识别必要状态和派生状态。 派生状态是可以从必要状态计算出的状态。
|
||||
- **将呈现代码与数据管理代码分开**: 将UI作为数据的功能并将代码分为两组（呈现代码和数据管理代码），以获得更好的可读性。 如果使用诸如React之类的JavaScript框架，则一般强制执行此操作。
|
||||
- **对于复杂的状态交互，请使用状态-减少器模式**: 如果问题需要许多状态字段，并且某些操作需要同时更改多个字段，请使用[减少器来汇总状态更新逻辑]（https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer））。 由Redux首先推广，状态-减少器模式鼓励您确定UI的状态、可执行的操作以及如何将操作与状态结合以导出下一个状态。 如果您使用React，则可以通过[`useReducer`React挂钩]实现此模式（https://reactjs.org/docs/hooks-reference.html#usereducer）。 Redux通常过于适用于面试，而`useReducer`应该足够。
|
||||
- **对于复杂的状态交互，请使用状态-减少器模式**: 如果问题需要许多状态字段，并且某些操作需要同时更改多个字段，请使用[减少器来汇总状态更新逻辑](https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer)。 由Redux首先推广，状态-减少器模式鼓励您确定UI的状态、可执行的操作以及如何将操作与状态结合以导出下一个状态。 如果您使用React，则可以通过[`useReducer` React hook](https://reactjs.org/docs/hooks-reference.html#usereducer)实现此模式。 Redux通常过于适用于面试，而`useReducer`应该足够。
|
||||
|
||||
React的文档["管理状态"](https://beta.reactjs.org/learn/managing-state)是有关如何正确设计和使用组件状态的杰出资源。 提到的一些想法与React无关，可以适用于任何UI框架。
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ React的文档["管理状态"](https://beta.reactjs.org/learn/managing-state)是
|
|||
- **链接标签和输入**: 使用`id`和`for`链接`<label>`中的`<input>`以防止用户意外点击文本。
|
||||
- **在表单中包装输入**: 将`<input>`包装在`<form>`中，以便单击按钮和按Enter将提交表单。 如果使用Ajax进行网络请求，则记得添加`event.preventDefault()`。
|
||||
- **输入应具有适当的类型**: `<input>`应具有适当的类型，例如电子邮件、密码、数字等。
|
||||
- **利用本机HTML表单验证**: 在可能的情况下，结合使用“required”属性和其他属性，如“pattern”、“min”、“max”等，以使用本机HTML表单验证。
|
||||
- **利用本机HTML表单验证**: 在可能的情况下，结合使用`required`属性和其他属性，如`pattern`、`min`、`max`等，以使用本机HTML表单验证。
|
||||
|
||||
## CSS/样式
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ React的文档["管理状态"](https://beta.reactjs.org/learn/managing-state)是
|
|||
|
||||
- **编写Vanilla CSS**: 学会在没有processor的情况下编写CSS，如[Sass](https://sass-lang.com/)和[Less](https://lesscss.org/)。 并不是所有环境都允许使用处理器，而且面试问题可能很小，不会真正受益于CSS预处理器提供的功能。 CSS处理器最有用的功能是使用变量，这可以通过CSS自定义属性（变量）本机提供。
|
||||
- **采用CSS命名约定**: 在编写类时考虑采用CSS命名方法论，例如[块元素修饰符](https://getbem.com)。
|
||||
- **在组件中避免使用“＃id”选择器**: 当构建可重用的UI组件（例如按钮、选项卡、菜单、模态框等）时，请避免在HTML中使用“＃id”选择器，因为“ id”是全局唯一的，但是您可以多个组件实例。
|
||||
- **在组件中避免使用`#id`选择器**: 当构建可重用的UI组件（例如按钮、选项卡、菜单、模态框等）时，请避免在HTML中使用`#id`选择器，因为`id`是全局唯一的，但是您可以多个组件实例。
|
||||
- **组织您的CSS**: 阅读有关[在大型项目中组织CSS](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Organizing)和如何具有[可扩展和模块化的CSS架构](http://smacss.com/)的文章。
|
||||
|
||||
## 用户体验
|
||||
|
|
@ -77,8 +77,8 @@ React的文档["管理状态"](https://beta.reactjs.org/learn/managing-state)是
|
|||
- CSS媒体查询可用于在移动设备上显示不同的布局。
|
||||
- 使交互元素（如按钮）足够大，以便按下（建议至少为44 x 44 px），并且间距足够宽。
|
||||
- **错误状态**: 及时清晰地反映错误-表单验证错误、网络请求错误等。
|
||||
- **处理不同尺寸的图像**: 使您的UI适用于呈现所有大小/维度的图像并保留原始纵横比的情况。
|
||||
- 使用CSS`background-image`和`background-position: contain`，以使图像适合在您定义的区域内。 如果可以将图像剪切（例如渐变背景），请使用`background-position: cover`。
|
||||
- **处理不同尺寸的图片**: 使您的UI适用于呈现所有大小/维度的图片并保留原始纵横比的情况。
|
||||
- 使用CSS`background-image`和`background-position: contain`，以使图片适合在您定义的区域内。 如果可以将图片剪切（例如渐变背景），请使用`background-position: cover`。
|
||||
- `<img>`标记具有类似的`object-fit`属性和`contain`和`cover`值。
|
||||
- **乐观更新**: 高级技术，即使在网络请求仍在进行时也能反映出成功状态。 如果请求失败，请恢复UI更改并显示错误消息。
|
||||
|
||||
|
|
@ -114,16 +114,16 @@ React的文档["管理状态"](https://beta.reactjs.org/learn/managing-state)是
|
|||
- 为不使用自定义HTML标记构建的元素添加正确的`aria-role`。
|
||||
- 使用`aria-label`来描述其中没有文本显示的元素（例如仅图标的按钮）。
|
||||
- 通过`aria-describedby`/`aria-errormessage`将错误消息元素链接到负责它们的元素。
|
||||
- **图像“alt”文本**:为`<img>`元素添加`alt`属性，以便屏幕阅读器可以描述图像。
|
||||
- **图片“alt”文本**:为`<img>`元素添加`alt`属性，以便屏幕阅读器可以描述图片。
|
||||
- **键盘交互**
|
||||
- 将`tabindex`属性添加到要通过键盘制表符聚焦的元素。
|
||||
- 元素可以通过键盘触发。
|
||||
- 检查焦点顺序是否合理。
|
||||
- **视觉问题**
|
||||
- **颜色对比度**: 文本/图像与背景之间的足够颜色对比度。
|
||||
- **颜色对比度**: 文本/图片与背景之间的足够颜色对比度。
|
||||
- **元素大小**: 字体大小，交互元素大小应足够大，适合其预期的媒介。
|
||||
|
||||
Google的[web.dev]有一个[免费的深入课程]，其中详细介绍了可访问性的内容（https://web.dev/learn/accessibility/），我们强烈推荐。
|
||||
Google的[web.dev]有一个[免费的深入课程](https://web.dev/learn/accessibility/)，其中详细介绍了可访问性的内容，我们强烈推荐。
|
||||
|
||||
## 边缘情况
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ Google的[web.dev]有一个[免费的深入课程]，其中详细介绍了可访
|
|||
|
||||
## 安全
|
||||
|
||||
- **跨站点脚本（XSS）**: 在渲染内容时，请避免分配给[`Element.innerHTML`](https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML)或React的`dangerouslySetInnerHTML`，因为它来自用户会导致跨站点脚本，应将其分配给[`Node.textContent`](https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent)或使用实验性的[`Element.setHTML()`]方法代替（https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML）。 请参考[OWASP的XSS预防备忘单](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
|
||||
- **跨站点脚本（XSS）**: 在渲染内容时，请避免分配给[`Element.innerHTML`](https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML)或React的`dangerouslySetInnerHTML`，因为它来自用户会导致跨站点脚本，应将其分配给[`Node.textContent`](https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent) 或使用实验性的[`Element.setHTML()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML) 方法代替。 请参考[OWASP的XSS预防备忘单](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
|
||||
- **“URL上下文”的输出编码**: 如果用户提供的输入可能用于URL查询参数，请使用`encodeURIComponent`来防止意外的值成为URL的一部分（例如额外的查询参数）。
|
||||
- **跨站点请求伪造**: 请参见[OWASP的XSS预防备忘单](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)。
|
||||
|
||||
|
|
@ -155,6 +155,6 @@ Google的[web.dev]有一个[免费的深入课程]，其中详细介绍了可访
|
|||
|
||||
您的UI能够处理多种语言吗？ 添加支持更多语言有多容易？
|
||||
|
||||
- **避免硬编码特定语言的标签**: 一些UI组件中具有标签字符串（例如，图像轮播具有上一个/下一个按钮的标签）。 允许使用这些标签字符串进行自定义，使它们成为组件的props/options的一部分，这很好。
|
||||
- **避免硬编码特定语言的标签**: 一些UI组件中具有标签字符串（例如，图片轮播具有上一个/下一个按钮的标签）。 允许使用这些标签字符串进行自定义，使它们成为组件的props/options的一部分，这很好。
|
||||
- **UI可以呈现长字符串**: 参见上面有关呈现长字符串的部分。
|
||||
- **从右到左的语言**: 某些语言（例如，阿拉伯语、希伯来语） 使用[CSS逻辑属性](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties)来使你的布局适用于不同的[书写模式](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Writing_Modes)。
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ User interface coding interviews will involve candidates writing HTML, CSS and J
|
|||
|
||||
The user interfaces that candidates are asked to code can range from really small UI components to more complex client-facing products like small apps and games.
|
||||
|
||||
## Exemplos
|
||||
## Examples
|
||||
|
||||
### User Interface Components/Widgets/Layouts
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ description: 准备前端/网络开发人员面试中的用户界面问题的指
|
|||
|
||||
### 用户界面组件/小部件/布局
|
||||
|
||||
- 用户界面组件/小部件/布局组件：[手风琴](/questions/user-interface/accordion)、[选项卡](/questions/user-interface/tabs)、[星级评分小部件](/questions/user-interface/star-rating)、[推特](/questions/user-interface/tweet)、图像轮播。
|
||||
- 用户界面组件/小部件/布局组件：[手风琴](/questions/user-interface/accordion)、[选项卡](/questions/user-interface/tabs)、[星级评分小部件](/questions/user-interface/star-rating)、[推特](/questions/user-interface/tweet)、图片轮播。
|
||||
- 小部件：[数字时钟](/questions/user-interface/digital-clock)、[模拟时钟](/questions/user-interface/analog-clock)。
|
||||
- 页面部分：[注册表单](/questions/user-interface/signup-form)、[圣杯](/questions/user-interface/holy-grail)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: 描述cookie、 `sessionStorage` 和 `localStorage` 之间的差异。
|
|||
|
||||
LocalStorage 对于存储用户以后需要访问的数据很有用，例如离线数据，因为它把数据存储在浏览器和系统中。 即使用户关闭和重新打开浏览器，这些数据也将持续存在，并可被其他网站访问。
|
||||
|
||||
SessionStorage 是提高你的网络应用程序性能的一个好方法。 它在浏览器上本地存储数据，但特定于（并且只能由）各自的网站/浏览器标签访问，并且只有当用户在网站/标签上时才能使用。 由于限制性的访问，这是一个更安全的存储方法，并且由于减少了服务器和客户端之间的数据传输，促进了更好的网站性能。
|
||||
SessionStorage 是提高你的Web 应用程序性能的一个好方法。 它在浏览器上本地存储数据，但特定于（并且只能由）各自的网站/浏览器标签访问，并且只有当用户在网站/标签上时才能使用。 由于限制性的访问，这是一个更安全的存储方法，并且由于减少了服务器和客户端之间的数据传输，促进了更好的网站性能。
|
||||
|
||||
对于存储不应长期保存的数据，如会话ID，Cookies是一个不错的选择。 Cookies允许你设置一个过期时间，届时它将被删除。 与其他两种存储方法相比，Cookies只能是较小尺寸的数据。
|
||||
|
||||
|
|
|
|||
|
|
@ -41,9 +41,9 @@ title: 在设计或开发多语言站点时你必须注意什么事？
|
|||
|
||||
日历日期有时以不同的方式呈现。 例如： 美国的“May 31, 2012” vs. 欧洲部分地区的"31 May 2012"。
|
||||
|
||||
## 不在图像中放置文本
|
||||
## 不在图片中放置文本
|
||||
|
||||
将文本放在位图中（如png、gif、jpg等）并不是一种可扩展的方法。 在图像中放置文字仍然是一种常用的方式，可以在任何计算机上显示优雅、非系统字体。 不过，为了支持图像文本翻译成其他语言，需要为每种语言创建单独的图像，这不是设计人员的灵活工作流程。
|
||||
将文本放在位图中（如png、gif、jpg等）并不是一种可扩展的方法。 在图片中放置文字仍然是一种常用的方式，可以在任何计算机上显示优雅、非系统字体。 不过，为了支持图片文本翻译成其他语言，需要为每种语言创建单独的图片，这不是设计人员的灵活工作流程。
|
||||
|
||||
## 要注意色彩的感知方式
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,6 @@
|
|||
title: Document `load` 事件和 `DOMContentLoaded` 事件之间的区别？
|
||||
---
|
||||
|
||||
当初始的 HTML 文档被完全加载并解析时，`DOMContentLoaded` 事件将被触发。 无需等待样式表、图像和子帧来完成加载。
|
||||
当初始的 HTML 文档被完全加载并解析时，`DOMContentLoaded` 事件将被触发。 无需等待样式表、图片和子帧来完成加载。
|
||||
|
||||
`window` 上的 `load` 事件只在 DOM 和所有依赖的资源和资产加载后才能触发。
|
||||
|
|
|
|||
|
|
@ -2,6 +2,6 @@
|
|||
title: 尽可能详细地解释Ajax
|
||||
---
|
||||
|
||||
Ajax (异步 JavaScript 和 XML) 是一套网络开发技术，在客户端使用许多网络技术创建异步网络应用程序。 使用 Ajax， Web 应用程序可以将数据异步地发送到服务器（后端）并从服务器上检索，而不干扰现有页面的显示和行为。 通过将数据交换层与表现层解耦，Ajax允许网页，以及扩展的网页应用程序，动态地改变内容，而不需要重新加载整个页面。 实际上，现代实现通常使用JSON而不是XML，因为JSON是JavaScript的原生优势。
|
||||
Ajax (异步 JavaScript 和 XML) 是一套网络开发技术，在客户端使用许多网络技术创建异步Web 应用程序。 使用 Ajax， Web 应用程序可以将数据异步地发送到服务器（后端）并从服务器上检索，而不干扰现有页面的显示和行为。 通过将数据交换层与表现层解耦，Ajax允许网页，以及扩展的Web 应用程序，动态地改变内容，而不需要重新加载整个页面。 实际上，现代实现通常使用JSON而不是XML，因为JSON是JavaScript的原生优势。
|
||||
|
||||
`XMLHttpRequest` API或如今的 `fetch` API经常用于异步通信。
|
||||
|
|
|
|||
|
|
@ -1,21 +1,21 @@
|
|||
---
|
||||
title: 解释CSS 图像精灵（雪碧图），以及您如何在页面或网站上实现它们。
|
||||
title: 解释CSS 图片精灵（雪碧图），以及您如何在页面或网站上实现它们。
|
||||
---
|
||||
|
||||
CSS 图像精灵将多个图像合并为一个更大的图像文件，并使用 CSS `background-image`, `background-position` 和 `background-size` 来选择更大图像的特定部分作为所需图像。
|
||||
CSS 图片精灵将多个图片合并为一个更大的图片文件，并使用 CSS `background-image`, `background-position` 和 `background-size` 来选择更大图片的特定部分作为所需图片。
|
||||
|
||||
它曾经是用于图标的一种常用技术(例如，Gmail使用图像精灵作为其所有图像)。
|
||||
它曾经是用于图标的一种常用技术(例如，Gmail使用图片精灵作为其所有图片)。
|
||||
|
||||
## 优点
|
||||
|
||||
- 减少多个图像的 HTTP 请求数量 (每张spritesheet 只需要一个请求)。 但是使用 HTTP2 加载多个图像已不再是一个问题。
|
||||
- 预先下载在需要之前不会下载的资产，如只会出现在 `:hover` 伪状态上的图像。 闪烁不会被看到。
|
||||
- 减少多个图片的 HTTP 请求数量 (每张spritesheet 只需要一个请求)。 但是使用 HTTP2 加载多个图片已不再是一个问题。
|
||||
- 预先下载在需要之前不会下载的资产，如只会出现在 `:hover` 伪状态上的图片。 闪烁不会被看到。
|
||||
|
||||
## 实现方式
|
||||
|
||||
1. 使用图像精灵生成器将多个图像包装成一个图像并生成相应的 CSS
|
||||
2. 每个图像都有一个对应的 CSS 类，定义了 `background-image` 和 `background-position` 属性。
|
||||
3. 要使用此图像，请将相应的类添加到您的元素中。
|
||||
1. 使用图片精灵生成器将多个图片包装成一个图片并生成相应的 CSS
|
||||
2. 每个图片都有一个对应的 CSS 类，定义了 `background-image` 和 `background-position` 属性。
|
||||
3. 要使用此图片，请将相应的类添加到您的元素中。
|
||||
|
||||
生成的样式表看起来可能像这样：
|
||||
|
||||
|
|
@ -45,4 +45,4 @@ CSS 图像精灵将多个图像合并为一个更大的图像文件，并使用
|
|||
|
||||
## 参考资料
|
||||
|
||||
- [在 CSS 中实现图像精灵 - CSS | MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/Implementing_image_sprites_in_CSS)
|
||||
- [在 CSS 中实现图片精灵 - CSS | MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/Implementing_image_sprites_in_CSS)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 解释一个单页应用程序是什么以及如何优化SEO
|
||||
---
|
||||
|
||||
当代的网络开发者指出他们构建的产品是网页应用，而不是网站。 虽然这两个词之间没有严格区别，但网络应用往往具有高度的互动性和动态， 允许用户执行操作并收到对其操作的响应。 通常情况下，浏览器从服务器接收HTML并渲染它。 当用户导航到另一个URL时，需要全页刷新，服务器将新的 HTML 发送到新页面。 这被称为服务器端渲染。
|
||||
当代的网络开发者指出他们构建的产品是Web 应用，而不是网站。 虽然这两个词之间没有严格区别，但Web 应用往往具有高度的互动性和动态， 允许用户执行操作并收到对其操作的响应。 通常情况下，浏览器从服务器接收HTML并渲染它。 当用户导航到另一个URL时，需要全页刷新，服务器将新的 HTML 发送到新页面。 这被称为服务器端渲染。
|
||||
|
||||
然而，在现代SPA中，则使用客户端渲染。 浏览器从服务器加载初始页面，以及整个应用程序所需的脚本(框架、库、应用代码) 和样式表。 当用户导航到其他页面时，不会触发页面刷新。 页面的 URL 通过[HTML5 History API](https://developer.mozilla.org/en-US/docs/Web/API/History_API)更新。 新页面所需的新数据，通常使用 JSON 格式，由浏览器通过 [AJAX](https://developer.mozilla.org/en-US/docs/AJAX/Getting_Start) 向服务器检索. SPA 然后通过JavaScript动态地更新页面数据，它已经在初始页面加载中下载好了。 此模型类似于本地移动应用的工作方式。
|
||||
|
||||
|
|
|
|||
|
|
@ -7,9 +7,9 @@ subtitle: 如果是这样，你是在什么时候使用的，使用了什么技
|
|||
|
||||
浏览器默认根据设备分辨率渲染DOM元素，但图片除外。
|
||||
|
||||
为了有最佳视网膜显示的精彩图形，我们需要尽可能使用高分辨率图像。 然而，使用最高分辨率图像将会对性能产生影响，因为更多的字节需要在网络上发送。
|
||||
为了有最佳视网膜显示的精彩图形，我们需要尽可能使用高分辨率图片。 然而，使用最高分辨率图片将会对性能产生影响，因为更多的字节需要在网络上发送。
|
||||
|
||||
为了克服这个问题，我们可以使用HTML5中指定的响应式图像。 它需要在浏览器中提供同一图像的不同分辨率文件，并让它决定哪个图像是最佳的图像， 使用 html 属性 `srcset` 和可选的 `sizes` ，比如：
|
||||
为了克服这个问题，我们可以使用HTML5中指定的响应式图片。 它需要在浏览器中提供同一图片的不同分辨率文件，并让它决定哪个图片是最佳的图片， 使用 html 属性 `srcset` 和可选的 `sizes` ，比如：
|
||||
|
||||
```html
|
||||
<div responsive-background-image>
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: 响应设计与自适应设计有何不同？
|
|||
|
||||
响应式设计和自适应设计都试图在不同的设备上优化用户体验，针对不同的视口尺寸、分辨率、使用环境、控制机制等进行调整。
|
||||
|
||||
响应式设计以灵活性原则为基础――一个能够在任何设备上看起来都很好的流畅的网站。 响应式网站使用媒体查询、灵活的网格和响应性图像来创造一个基于多种因素的弹性和变化的用户体验。 就像一个球在成长或缩小以适应几个不同的环。
|
||||
响应式设计以灵活性原则为基础――一个能够在任何设备上看起来都很好的流畅的网站。 响应式网站使用媒体查询、灵活的网格和响应性图片来创造一个基于多种因素的弹性和变化的用户体验。 就像一个球在成长或缩小以适应几个不同的环。
|
||||
|
||||
自适应设计更像是渐进式增强的现代定义。 自适应设计不是一个灵活的设计，而是检测设备和其他特征，然后根据一组预定的视口尺寸和其他特征提供适当的特征和布局。 站点检测所使用的设备类型，并为该设备提供预设布局。 你有几个不同尺寸的球，而不是一个球来穿过几个不同尺寸的环，而是有几个不同的球来使用，这取决于环的大小。
|
||||
|
||||
|
|
|
|||
|
|
@ -6,12 +6,12 @@ title: 什么是渐进式渲染？
|
|||
|
||||
在没有宽带互联网的时代，它曾经更加普遍，但在现代发展中，它仍然被使用，因为移动数据连接正变得越来越流行（而且不可靠）！这就是为什么它被认为是最受欢迎的！
|
||||
|
||||
## 懒加载图像
|
||||
## 懒加载图片
|
||||
|
||||
页面上的图像没有一次性全部加载。 只有当用户滚动到/靠近显示图像的页面部分时才加载图像。
|
||||
页面上的图片没有一次性全部加载。 只有当用户滚动到/靠近显示图片的页面部分时才加载图片。
|
||||
|
||||
- `<img loading="lazy">`是指示浏览器推迟加载屏幕外图像直到用户滚动附近的现代方法。
|
||||
- 使用 JavaScript 监听滚动位置，并在图像即将进入屏幕时加载图像(通过将图像坐标与滚动位置进行比较)。
|
||||
- 使用 JavaScript 监听滚动位置，并在图片即将进入屏幕时加载图片(通过将图片坐标与滚动位置进行比较)。
|
||||
|
||||
## 优先考虑可见内容（或正面渲染）。
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,6 @@ title: 你为什么要使用 `load` 事件？
|
|||
subtitle: 此事件是否有缺点？ 您是否知道任何替代方法，以及为什么要使用这些方法？
|
||||
---
|
||||
|
||||
`load`事件在文件加载过程结束时触发。 此刻，文档中的所有对象都在 DOM中，所有图像、脚本、链接和子框架都已完成加载。
|
||||
`load`事件在文件加载过程结束时触发。 此刻，文档中的所有对象都在 DOM中，所有图片、脚本、链接和子框架都已完成加载。
|
||||
|
||||
DOM 事件 `DOMContentLoaded` 将在 DOM 构建页面后触发，但不要等待其他资源完成加载。 在某些情况下，当你不需要在初始化前加载整个页面时，这是首选。
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: 为什么你会在图像标签中使用 `srcset` 属性？
|
||||
title: 为什么你会在图片标签中使用 `srcset` 属性？
|
||||
subtitle: 解释一下浏览器在评估这个属性的内容时的过程。
|
||||
---
|
||||
|
||||
当你想根据用户的设备显示宽度向他们提供不同的图片时，你会使用`srcset`属性--向有视网膜显示的设备提供更高质量的图片，增强用户体验，而向低端设备提供低分辨率的图片，提高性能，减少数据浪费（因为提供更大的图片不会有任何可见的差别）。 例如：`<img srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 2000w" src="..." alt="">` 指示浏览器根据客户端的分辨率显示大小、中等或大的 `.jpg` 图像。 第一个值是图像名称，第二个值是图像宽度像素。 对于宽度为320px的设备，计算如下：
|
||||
当你想根据用户的设备显示宽度向他们提供不同的图片时，你会使用`srcset`属性--向有视网膜显示的设备提供更高质量的图片，增强用户体验，而向低端设备提供低分辨率的图片，提高性能，减少数据浪费（因为提供更大的图片不会有任何可见的差别）。 例如：`<img srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 2000w" src="..." alt="">` 指示浏览器根据客户端的分辨率显示大小、中等或大的 `.jpg` 图片。 第一个值是图片名称，第二个值是图片宽度像素。 对于宽度为320px的设备，计算如下：
|
||||
|
||||
- 500 / 320 = 1.5625
|
||||
- 1000 / 320 = 3.125
|
||||
|
|
@ -11,6 +11,6 @@ subtitle: 解释一下浏览器在评估这个属性的内容时的过程。
|
|||
|
||||
如果客户端的分辨率是1x，1.5625是最接近的，`500w`对应的`small.jpg`将被浏览器选中。
|
||||
|
||||
如果分辨率是视网膜（2x），浏览器将使用高于最小分辨率的最接近的分辨率。 它不会选择500w(1.5625)，因为它大于1，图像看起来可能很差。 然后，浏览器将选择结果比率接近2的图像，即1000w（3.125）。
|
||||
如果分辨率是视网膜（2x），浏览器将使用高于最小分辨率的最接近的分辨率。 它不会选择500w(1.5625)，因为它大于1，图片看起来可能很差。 然后，浏览器将选择结果比率接近2的图片，即1000w（3.125）。
|
||||
|
||||
`srcset`解决的问题是，你想为窄屏幕设备提供较小的图像文件，因为它们不像桌面显示器那样需要巨大的图像--也可以选择你想为高分辨率/低分辨率屏幕提供不同分辨率的图像。
|
||||
`srcset`解决的问题是，你想为窄屏幕设备提供较小的图片文件，因为它们不像桌面显示器那样需要巨大的图片--也可以选择你想为高分辨率/低分辨率屏幕提供不同分辨率的图片。
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ seo_title: Guia rápido para entrevistas de design de sistema front-end
|
|||
|
||||
- Responder imediatamente à pergunta sem primeiro fazer perguntas e obter requisitos.
|
||||
- Abordar a pergunta de maneira desestruturada, indo em várias direções e deixando de abordar áreas importantes.
|
||||
- Insisting on only one solution or the best solution without realizing that each solution has tradeoffs.
|
||||
- Insistir em apenas uma solução ou na melhor solução sem perceber que cada solução tem compensações.
|
||||
- Permanecer em silêncio o tempo todo e apenas pensar em suas próprias ideias.
|
||||
- Entrar em uma toca de coelho e gastar muito tempo em áreas não importantes.
|
||||
- Utilizar buzzwords sem conseguir explicá-los.
|
||||
|
|
|
|||
|
|
@ -1,104 +1,102 @@
|
|||
---
|
||||
title: Front End System Design Interview Evaluation Axes
|
||||
description: Specific behaviors and signals interviewers look out for in front end system design interviews.
|
||||
seo_title: Evaluation Axes for Front End System Design from Ex-interviewers
|
||||
seo_description: Find out how interviewers at Google, Amazon, Meta, Microsoft and other tech companies evaluate you for front end system design interviews
|
||||
title: 前端系统设计面试评估轴
|
||||
description: 面试官在前端系统设计面试中注意的特定行为和信号。
|
||||
seo_title: 前端系统设计的评估轴（来自前面试官）
|
||||
seo_description: 了解谷歌、亚马逊、Meta、微软和其他科技公司的面试官如何在前端系统设计面试中对您进行评估。
|
||||
---
|
||||
|
||||
During interviews, interviewers look out for signals displayed by candidates before making an overall hiring and leveling recommendation. The more desired behaviors the candidate displays, the higher the likelihood the interviewer will recommend a "Hire" decision. The more detailed and mature the answers are, the higher the leveling recommendation.
|
||||
在面试过程中，面试官会观察应聘者所表现出的信号，然后做出整体的录用和评级建议。 候选人表现出的期望行为越多，面试官建议 "录用 "的可能性就越大。 答案越详细、越成熟，推荐等级就越高。
|
||||
|
||||
This section lists some of the behaviors that candidates should display. Bear them in mind as you are answering the system design question and demonstrate them confidently during the interview.
|
||||
本节列出了候选人应表现出的一些行为。 在回答系统设计问题时，请牢记这些点，并在面试时自信地展示出来。
|
||||
|
||||
## Problem Exploration
|
||||
## 问题探讨
|
||||
|
||||
- Demonstrated thorough understanding of the problem.
|
||||
- Explored the requirements sufficiently by asking relevant clarifying questions to minimize ambiguities.
|
||||
- Gathered functional and non-functional requirements of the problem.
|
||||
- Defined the scope of the problem.
|
||||
- Identified the important aspects of the problem to focus on and address.
|
||||
- 显示出对问题的透彻理解。
|
||||
- 通过提出相关的澄清性问题，对需求进行充分的探讨，以最大限度地减少歧义。
|
||||
- 收集问题的功能性和非功能性需求。
|
||||
- 确定问题的范围。
|
||||
- 确定需要关注和解决的问题的重要方面。
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Requirements Exploration
|
||||
<strong className="font-medium">相关框架部分:</strong>
|
||||
需求探索
|
||||
</div>
|
||||
|
||||
## Architecture
|
||||
## 架构
|
||||
|
||||
- Developed an architecture that solved the entire problem sufficiently.
|
||||
- Broke down the problem into smaller independent parts of suitable granularity.
|
||||
- Identified components of the system and defined their responsibilities clearly.
|
||||
- Articulated how these components will work together and defined/described the API between these components.
|
||||
- Developed an architecture that can be put into practice.
|
||||
- Developed an architecture with scalability and reusability in mind, one that can be extended to support future requirements.
|
||||
- 开发出一种能够充分解决整个问题的架构。
|
||||
- 将问题分解成适当粒度的独立小部分。
|
||||
- 确定系统的组成部分并明确其职责。
|
||||
- 阐明这些组件将如何协同工作，并定义/描述这些组件之间的API。
|
||||
- 开发可付诸实施的架构。
|
||||
- 开发的架构具有可扩展性和可重用性，可扩展以支持未来需求。
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture/High-level Design, Data Model, Interface Definition
|
||||
<strong className="font-medium">相关框架部分:</strong>
|
||||
架构/高层设计、数据模型、接口定义
|
||||
</div>
|
||||
|
||||
## Technical Proficiency
|
||||
## 技术能力
|
||||
|
||||
- Demonstrated technical knowledge and proficiency of front end fundamentals, common technologies and APIs.
|
||||
- Able to dive into specific front end domain areas where relevant to the problem.
|
||||
- Identified areas which need to be paid special attention to and addressed them by proposing solutions and analyzing their tradeoffs.
|
||||
- 熟练掌握前端基础知识、常用技术和API。
|
||||
- 能够深入到与问题相关的特定前端领域。
|
||||
- 确定需要特别关注的领域，并通过提出解决方案和分析其利弊得失来解决这些问题。
|
||||
|
||||
_Front end domain areas include Performance, Networking, HTML/CSS, Accessibility, Internationalization, Security, Scalability, etc._
|
||||
前端领域包括性能、网络、HTML/CSS、可访问性、国际化、安全性、可扩展性等。
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture/High-level Design, Optimizations and Deep Dive
|
||||
<strong className="font-medium">相关框架部分:</strong>
|
||||
架构/高层设计、优化和深入研究
|
||||
</div>
|
||||
|
||||
## Exploration and Tradeoffs
|
||||
## 探索与权衡
|
||||
|
||||
- Offered various possible solutions to the problems at hand and explained the pros and cons of each solution.
|
||||
- The "problem" here doesn't necessarily refer to the given system design question.
|
||||
- While solving the given question, there would be smaller problems to solve/questions to answer and each small problem/question can have various solutions and choices to make.
|
||||
- Explained the suitability of the solutions given the context and requirements and provided recommendations for the context of the question.
|
||||
- Do not insist there is only one possible solution. Good questions usually have a few possible solutions where the suitability of each depends on the context.
|
||||
- Even if the other solutions are clearly and obviously bad, do still mention them and briefly explain why they are bad.
|
||||
- 针对当前问题提出各种可能的解决方案，并解释每种解决方案的利弊。
|
||||
- 这里的 "问题" 并不一定是指给定的系统设计问题。
|
||||
- 在解决给定的问题时，会有更小的问题需要解决/回答，每个小问题都有不同的解决方案和选择。
|
||||
- 根据背景和要求解释了解决方案的适用性，并针对问题背景提出了建议。
|
||||
- 不要坚持只有一种可能的解决方案。 好的问题通常有几种可能的解决方案，每种解决方案是否合适取决于具体情况。
|
||||
- 即使其他解决方案明显不好，也要提及并简要解释为什么不好。
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Requirements Exploration, Data Model, Interface Definition, Optimizations and Deep
|
||||
Dive
|
||||
<strong className="font-medium">相关框架部分:</strong>
|
||||
需求探索、数据模型、接口定义、优化和深入研究
|
||||
</div>
|
||||
|
||||
## Product and UX Sense
|
||||
## 产品和用户体验意识
|
||||
|
||||
Relevant framework sections: **Optimizations and Deep Dive**
|
||||
相关框架章节：**优化和深入研究**
|
||||
|
||||
- Proposed a robust solution that lays the foundation of a good product.
|
||||
- Considered user experience when answering: loading states, performance (perceived or actual), mobile friendliness, keyboard friendliness, etc.
|
||||
- Considered error cases and suggested ways to handle them.
|
||||
- 提出了一个强大的解决方案，为良好的产品奠定了基础。
|
||||
- 回答时考虑用户体验：加载状态、性能（感知或实际）、移动友好性、键盘友好性等。
|
||||
- 考虑错误案例并建议处理方法。
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Optimizations and Deep Dive
|
||||
<strong className="font-medium">相关框架部分:</strong>
|
||||
优化和深入研究
|
||||
</div>
|
||||
|
||||
## Communication and Collaboration
|
||||
## 沟通与合作
|
||||
|
||||
- Conveyed their thoughts and ideas clearly and concisely.
|
||||
- Explained complex concepts with ease.
|
||||
- Engaged the interviewer during the session, asks good questions and seeks opinions where relevant.
|
||||
- Open to feedback from the interviewer and incorporates the feedback to refine their solutions.
|
||||
- 简明扼要地表达自己的想法和观点。
|
||||
- 轻松解释复杂概念。
|
||||
- 在会议期间与面试官互动，提出好的问题并在相关情况下征求意见。
|
||||
- 乐于接受面试官的反馈意见，并根据反馈意见完善自己的解决方案。
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture/High-level Design, Data Model, Interface Definition, Optimizations
|
||||
and Deep Dive
|
||||
<strong className="font-medium">相关框架部分:</strong>
|
||||
架构/高层设计、数据模型、接口定义、优化和深入研究
|
||||
</div>
|
||||
|
||||
## Summary
|
||||
## 总结
|
||||
|
||||
Here's a table summarizing how the evaluation axes can be mapped to the various sections of the **RADIO framework**: Requirements Exploration, Architecture/High-level Design, Data Model, Interface Definition, Optimizations and Deep Dive.
|
||||
下面的表格总结了如何将评估轴映射到**RADIO框架**的各个部分：需求探索（Requirements Exploration）、架构/高层设计（Architecture/High-level Design）、数据模型（Data Model）、接口定义（Interface Definition）、优化和深度挖掘（Optimizations and Deep Dive）。
|
||||
|
||||
| Axis | R | A | D | I | O |
|
||||
| ------------------------------- | :-: | :-: | :-: | :-: | :-: |
|
||||
| Problem Exploration | ✅ | - | - | - | - |
|
||||
| Architecture | - | ✅ | ✅ | ✅ | - |
|
||||
| Technical Proficiency | - | ✅ | - | - | ✅ |
|
||||
| Exploration and Tradeoffs | - | ✅ | ✅ | ✅ | ✅ |
|
||||
| Product and UX Sense | - | - | - | - | ✅ |
|
||||
| Communication and Collaboration | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| 轴 | R | A | D | I | O |
|
||||
| ---------------------------- | :-: | :-: | :-: | :-: | :-: |
|
||||
| 问题探讨 | ✅ | - | - | - | - |
|
||||
| 架构 | - | ✅ | ✅ | ✅ | - |
|
||||
| 技术能力 | - | ✅ | - | - | ✅ |
|
||||
| 探索与权衡 | - | ✅ | ✅ | ✅ | ✅ |
|
||||
| 产品和用户体验意识 | - | - | - | - | ✅ |
|
||||
| 沟通与合作 | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ Recomenda-se que você registre os requisitos acordados em algum lugar para pode
|
|||
|
||||
**Duração recomendada**: Aproximadamente 20% da sessão.
|
||||
|
||||
With the requirements in mind, we can move on to the architecture design proper. Sua próxima tarefa é criar uma arquitetura de produto/sistema identificando os principais componentes do produto, como os componentes interagem entre si e como estão relacionados. Lembre-se de focar na **arquitetura do lado do cliente**, não no backend.
|
||||
Com os requisitos em mente, podemos passar para o projeto de arquitetura propriamente dito. Sua próxima tarefa é criar uma arquitetura de produto/sistema identificando os principais componentes do produto, como os componentes interagem entre si e como estão relacionados. Lembre-se de focar na **arquitetura do lado do cliente**, não no backend.
|
||||
|
||||
Diagramas são seus amigos nesse caso. Cada componente pode ser representado usando um retângulo, e o design de alto nível geralmente acaba parecendo alguns retângulos conectados por setas para demonstrar o fluxo de dados. Também é possível ter componentes dentro de componentes. Nesse caso, desenhe o componente pai usando retângulos maiores, já que eles precisam abrigar vários subcomponentes.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,185 +1,185 @@
|
|||
---
|
||||
title: The RADIO Framework
|
||||
description: Approach your front end system design interviews in a structured fashion. A good structure is half the battle won.
|
||||
seo_title: RADIO Framework for System Design | Apply to Any Front End System Design Interview
|
||||
seo_description: Apply the RADIO Framework to Front End System Design Interviews to guide yourself in a structured manner. A good structure is half the battle won.
|
||||
title: RADIO框架
|
||||
description: 以结构化的方式进行前端系统设计面试。 良好的结构是成功的一半。
|
||||
seo_title: 系统设计的RADIO框架｜适用于任何前端系统设计面试
|
||||
seo_description: 在前端系统设计面试中应用RADIO框架，以结构化的方式指导自己。 良好的结构是成功的一半。
|
||||
---
|
||||
|
||||
A good beginning is half the battle won. By using the **RADIO framework** to answer front end system design questions, you will already be much closer to acing your interview.
|
||||
良好的开端是成功的一半。 通过使用**RADIO框架**回答前端系统设计问题，您已经离面试成功更近了一步。
|
||||
|
||||
In the context of front end system design interviews, the systems you are asked to design tend to be products, so we'll refer to the system as "product" from here on. Start by understanding the **R**equirements, defining the high level **A**rchitecture and the **D**ata Model. Then define the **I**nterfaces between the components in the product and talk about any **O**ptimizations or dive deep into specific areas which require special attention.
|
||||
在前端系统设计面试中，您被要求设计的系统往往是产品，因此我们从这里开始将系统称为 "产品"。 首先了解**R**equirements（需求），定义高层**A**rchitecture（架构）和**D**ata Model（数据模型）。 然后定义产品组件之间的**I**nterfaces（接口），并讨论任何**O**ptimizations or dive deep（优化或深入）到需要特别关注的特定领域。
|
||||
|
||||
## What is RADIO about?
|
||||
## RADIO是什么？
|
||||
|
||||
1. **需求探索**：通过提出一些澄清问题，深入了解问题，并确定范围。
|
||||
2. **架构/高层设计**：确定产品的关键组件及其相互关系。
|
||||
3. **数据模型**：描述各种数据实体、它们所包含的字段以及它们属于哪个组件。
|
||||
4. **Interface Definition (API)**: Define the interface (API) between components in the product, functionality of each API, their parameters and responses.
|
||||
5. **优化和深度挖掘**：讨论在构建产品时可能存在的优化机会和特定的感兴趣的领域。
|
||||
1. **Requirements Exploration 需求探索**：全面了解问题，通过提出一些明确的问题来确定问题的范围。
|
||||
2. **Architecture/High-level Design 架构/高级设计**：确定产品的关键组件以及它们之间的关系。
|
||||
3. **Data Model 数据模型**：描述各种数据实体、它们包含的字段以及它们属于哪个组件。
|
||||
4. **Interface Definition (API) 接口定义**：定义产品组件之间的接口（API）、每个API的功能、参数和响应。
|
||||
5. **Optimizations and Deep Dive 优化和深入**：讨论在构建产品时可能的优化机会和感兴趣的特定领域。
|
||||
|
||||
## Requirements Exploration
|
||||
## 需求探索
|
||||
|
||||
**Objective**: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions.
|
||||
**目标**：全面了解问题，并通过提出一些明确的问题来确定问题的范围。
|
||||
|
||||
**Recommended Duration**: Not more than 15% of the session.
|
||||
**建议持续时间**：不超过会议时间的15%。
|
||||
|
||||
System design interview questions are open-ended in nature and are usually vague and under-specified on purpose. **You are required to dig deeper and clarify ambiguities in the problem by asking useful questions.** Treat your interviewer as a product manager you are working with on a new project, ask enough questions so that you know what problems you are trying to solve and what you need to build. In reality, some problems can be solved without any engineering at all!
|
||||
系统设计面试问题的性质是开放式的，通常是模糊的，没有明确的目的。 **您需要深入挖掘问题，并通过提出有用的问题来澄清问题中的模糊之处。**将您的面试官视为与您合作开展新项目的产品经理，提出足够多的问题，以便您了解您要解决的问题以及您需要构建的内容。 实际上，有些问题根本不需要任何工程技术就可以解决！
|
||||
|
||||
No two system design interview experiences are the same even though you can be asked the same question. Interviewers have different backgrounds and might prioritize different aspects of the system. Take this chance to find out what they are most interested in and plan your answers accordingly.
|
||||
尽管您可能会被问到相同的问题，但没有两次系统设计面试经历是相同的。 面试官的背景不同，可能会优先考虑系统的不同方面。 借此机会了解他们最感兴趣的内容，并据此计划您的回答。
|
||||
|
||||
Some general questions you should get answers to before moving on to the next part of the interview:
|
||||
在进入面试的下一环节之前，您应该回答一些一般性问题：
|
||||
|
||||
### What are the main use cases we should be focusing on?
|
||||
### 我们应该关注哪些主要用例？
|
||||
|
||||
Imagine you were asked to "Design Facebook". Facebook is a huge platform, there's news feed, profiles, friends, groups, stories, and more. Which parts of Facebook should you focus on? The interviewer has the answer in mind but wants you to find out by asking questions. Typically you should focus on the most unique aspects of the product, the features which define it. For Facebook, it would be the news feed, pagination of the feed, and creating new posts. For YouTube, it would be the video-watching experience. The important areas for other type of products be found in the [types of questions](/system-design/types-of-questions).
|
||||
想象一下，您被要求 "设计Facebook"。 Facebook是一个庞大的平台，有信息流、个人资料、好友、群组、故事等。 您应该关注Facebook的哪些部分？ 面试官心中已经有了答案，但希望您通过提问来找出答案。 通常情况下，您应将重点放在产品最独特的方面，即产品的特征上。 对于Facebook而言，这将是信息流、信息流分页和创建新帖子。 对于YouTube来说，这将是视频观看体验。 其他类型产品的重要区域请参见[问题类型](/system-design/types-of-questions)。
|
||||
|
||||
For the rest of this page, we'll be using "Design Facebook" as the problem and apply the framework to it.
|
||||
在本页的其余部分，我们将使用 "设计Facebook "作为问题，并将框架应用于该问题。
|
||||
|
||||
Let's assume you didn't clarify which parts of the product to focus on, assumed you should talk about the befriending flow and started talking about it. In the best case, good interviewers will steer you back in the direction the question was meant to proceed, but they will make a mental note that you didn't clarify the question. In the worst case, inexperienced interviewers will let you keep talking and politely try to find an opportunity to correct you, but you would have already wasted some precious minutes discussing an unimportant topic.
|
||||
假设您没有明确产品的重点，就认为应该谈论结交流程，并开始谈论它。 在最好的情况下，优秀的面试官会引导您回到问题本来的方向，但他们会在心里记下您没有澄清问题。 在最坏的情况下，没有经验的面试官会让您继续说下去，并礼貌地试图找机会纠正您，但您已经浪费了宝贵的几分钟来讨论一个不重要的话题。
|
||||
|
||||
### What are the functional requirements and non-functional requirements?
|
||||
### 什么是功能性需求和非功能性需求？
|
||||
|
||||
Firstly, what are functional and non-functional requirements?
|
||||
首先，什么是功能性需求和非功能性需求？
|
||||
|
||||
- **Functional requirements**: Basic requirements of the product such that the product cannot function without them. This is usually whether a user can complete the core flows correctly.
|
||||
- **Non-functional requirements**: Requirements that are viewed as improvements to the product, but not strictly required for the product to be usable, i.e. the product can still be used without these. These include performance (how fast the page loads, how fast the interaction takes), scalability (how many items can be present on the page), good user experience, etc.
|
||||
- **功能要求**：产品的基本要求，没有这些要求产品就无法运行。 这通常是指用户能否正确完成核心流程。
|
||||
- **非功能性需求**：被视为产品改进的需求，但不是产品可用性的严格要求，即没有这些需求产品仍然可以使用。 其中包括性能（页面加载速度、交互速度）、可扩展性（页面上可显示多少项目）、良好的用户体验等。
|
||||
|
||||
There are two ways you can get the answer to this question:
|
||||
您可以通过两种方式获得这个问题的答案：
|
||||
|
||||
1. Take the initiative to list out what you think are the requirements and get feedback and alignment from the interviewer (Preferred).
|
||||
2. Ask the interviewer directly. However, most of the time they'd want you to define them. Even if they give you an answer, it won't be too detailed.
|
||||
1. 主动列出您认为的要求，并获得面试官的反馈和调整（首选）。
|
||||
2. 直接询问面试官。 然而，在大多数情况下，他们希望您对其进行定义。 即使他们给了您答案，也不会太详细。
|
||||
|
||||
At the very minimum, your design has to meet the functional requirements. After meeting all the function requirements, move on to talk about how to fulfill the non-functional requirements.
|
||||
最起码，您的设计必须满足功能要求。 在满足所有功能需求后，继续讨论如何满足非功能需求。
|
||||
|
||||
### What are the core features to focus on and which are good-to-have?
|
||||
### 哪些是需要关注的核心功能？
|
||||
|
||||
Even after you know the functional requirements, there can still be a ton of small features that make up the large feature. For example, when creating new Facebook posts, what kind of post formats should be supported? Besides the usual text-based posts, should the user be able to upload photos, upload videos, create polls, check in to a location, etc.
|
||||
即使您知道了功能需求，仍可能有大量的小功能组成了大功能。 例如，在创建新的Facebook帖子时，应支持何种帖子格式？ 除了常见的基于文本的帖子外，用户是否还可以上传照片、上传视频、创建投票、到某个地点签到等。
|
||||
|
||||
You should clarify the core features beforehand and design for them before moving on to the extra features.
|
||||
您应事先明确核心功能并进行设计，然后再进行额外功能的设计。
|
||||
|
||||
### Other questions:
|
||||
### 其他问题
|
||||
|
||||
- What devices/platforms (desktop/tablet/mobile) need to be supported?
|
||||
- Is offline support necessary?
|
||||
- Who are the main users of the product?
|
||||
- What are the performance requirements, if any? (Performance requirements typically fall under non-functional requirements.)
|
||||
- 需要支持哪些设备/平台（桌面/平板/移动）？
|
||||
- 是否需要离线支持？
|
||||
- 产品的主要用户是谁？
|
||||
- 如果有，性能要求是什么？ (性能需求通常属于非功能性需求）。
|
||||
|
||||
The list above should give you a good starting list of questions but it is not an exhaustive list! Different problems will require you to ask domain-specific questions, which we will talk about in the case studies.
|
||||
上述问题清单应能为您提供一个很好的问题起点，但并非详尽无遗！ 不同的问题将要求您提出特定领域的问题，我们将在案例研究中讨论这些问题。
|
||||
|
||||
You are recommended to write down the agreed requirements somewhere so that you can refer to them throughout the interview and ensure that you've covered them.
|
||||
建议您将商定的要求写在某个地方，以便在整个面试过程中参考，并确保您已经涵盖了这些要求。
|
||||
|
||||
* * *
|
||||
|
||||
## Architecture/High-level Design
|
||||
## 架构/高级设计
|
||||
|
||||
**Objective**: Identify the key components of the product and how they are related to each other.
|
||||
**目标**：识别产品的关键部件以及它们之间的关系。
|
||||
|
||||
**Recommended Duration**: Roughly 20% of the session.
|
||||
**建议持续时间**：约占会议的20%。
|
||||
|
||||
With the requirements in mind, we can move on to the architecture design proper. Your next task is to come up with a product/system architecture by identifying the key components of the product, how the components interact with each other, and how they are related. Remember to focus on the **client-side architecture**, not the back end.
|
||||
有了这些需求，我们就可以进行架构设计了。 您的下一项任务是通过确定产品的关键组件、这些组件之间的相互作用以及它们之间的关系，提出产品/系统架构。 切记要关注**客户端架构**，而不是后端。
|
||||
|
||||
Diagrams are your friends here. Each component can be represented using a rectangle and your high-level design usually ends up looking like a few rectangular boxes with arrows between them to demonstrate the flow of data. It is also possible to have components within components, in that case, draw the parent using bigger rectangles since they need to fit multiple subcomponents.
|
||||
图表是您的朋友。 每个组件都可以用一个矩形表示，您的高层设计通常最终看起来像几个矩形框，它们之间用箭头表示数据流。 也可以在组件中包含组件，在这种情况下，使用更大的矩形绘制父组件，因为它们需要适合多个子组件。
|
||||
|
||||
Examples of components/modules which are commonly found in a high-level front end design:
|
||||
高级前端设计中常见的组件/模块示例：
|
||||
|
||||
- **Server**: In front end system design interviews, we can treat the server as a black box and assume it exposes some APIs you can call via HTTP/WebSockets.
|
||||
- **View**: This represents what the user sees, and it usually contains smaller subviews within it. Can contain client-side only state.
|
||||
- **Controller**: The module which responds to user interactions and processes the data from the store/model in a format the view expects. This module is not always needed if the application is small and there's not much passing of data between modules.
|
||||
- **Model/Client Store**: Where the data lives. Stores contain data which will be presented to the user via views and stores tend to be app-wide for an interview context. In reality, you can have multiple stores within an application and stores can contain other stores.
|
||||
- **服务器**：在前端系统设计面试中，我们可以把服务器当作一个黑盒子，假设它暴露了一些API，您可以通过HTTP/WebSockets调用。
|
||||
- **视图**：表示用户看到的内容，通常包含更小的子视图。 可以只包含客户端状态。
|
||||
- **控制器**：响应用户交互的模块，以视图期望的格式处理来自存储/模型的数据。 如果应用程序较小，且模块间数据传递不多，则不一定需要该模块。
|
||||
- **模型/客户存储**：数据存放的地方。 存储包含的数据将通过视图呈现给用户，存储往往是整个应用程序的采访背景。 实际上，您可以在应用程序中拥有多个存储空间，并且存储空间可以包含其他存储空间。
|
||||
|
||||
Other things to consider when defining the responsibilities of components:
|
||||
定义组件责任时需要考虑的其他事项：
|
||||
|
||||
- **Separation of concerns**: Components are meant to be modular and serve to encapsulate a set of functionality and data. Consider the purpose/functionality of each component, what data it should contain and how it can service the rest of the system (what it can do for the other components).
|
||||
- **Where computation should occur**: If some amount of computation is needed (e.g. filtering of results given a search term, calculating the total amount for a cart), should the work be done on the server or the client? There are tradeoffs to each approach and the decision is both question-dependent and context-dependent.
|
||||
- **关注点分离**：组件是模块化的，用于封装一系列功能和数据。 考虑每个组件的目的/功能，它应包含哪些数据，以及它如何为系统的其他部分提供服务（它能为其他组件做什么）。
|
||||
- **计算应在何处进行**：如果需要进行一定量的计算（例如过滤搜索结果，计算购物车的总金额），这些工作应该在服务器还是客户端完成？ 每种方法都有其优缺点，决策既取决于问题，也取决于环境。
|
||||
|
||||
It is important to realize that not every common component mentioned above will be relevant and needed for every question, it depends on the product.
|
||||
重要的是要认识到，并非上述每个常见组件都与每个问题相关，也并非每个问题都需要，这取决于产品。
|
||||
|
||||
After drawing out the architecture diagram, verbally describe the responsibilities of each component (box in the diagram).
|
||||
画出架构图后，口头描述每个组件（图中方框）的职责。
|
||||
|
||||
### Architecture Example
|
||||
### 架构示例
|
||||
|
||||
Here's an example architecture diagram for the [News Feed](/questions/system-design/news-feed-facebook) question drawn using Excalidraw.
|
||||
下面是使用Excalidraw绘制的[信息流](/questions/system-design/news-feed-facebook)问题的架构图示例。
|
||||
|
||||
|
||||
|
||||
|
||||
#### Component Responsibilities
|
||||
#### 组件责任
|
||||
|
||||
- **Server**: Serves feed data and provides a HTTP API for new feed posts to be created.
|
||||
- **Controller**: Controls the flow of data within the application and makes network requests to the server.
|
||||
- **Client Store**: Stores data needed across the whole application. In the context of a news feed, most of the data in the store will be server-originated data needed by the feed UI.
|
||||
- **Feed UI**: Contains a list of feed posts and the UI for composing new posts.
|
||||
- **Feed Post**: Presents the data for a feed post and contains buttons to interact with the post (like/react/share/comment).
|
||||
- **Post Composer**: UI for users to create new feed posts.
|
||||
- **服务器**：为Feed数据提供服务，并为创建新的Feed帖子提供HTTP API。
|
||||
- **控制器**：控制应用程序中的数据流，并向服务器发出网络请求。
|
||||
- **客户存储**：存储整个应用程序所需的数据。 在新闻提要中，存储中的大部分数据都是新闻提要用户界面所需的服务器端数据。
|
||||
- **信息流用户界面**：包含信息流帖子列表和撰写新帖子的用户界面。
|
||||
- **信息流帖子**：提供信息流帖子的数据，包含与帖子互动的按钮（喜欢/反应/分享/评论）。
|
||||
- **发布器**: 提供给用户创建新的动态的用户界面。
|
||||
|
||||
Common free drawing tools that you might be asked to use include [diagrams.net](https://app.diagrams.net/) and [Excalidraw](https://excalidraw.com/). It'd be a good idea to familiarize yourself with these tools beforehand.
|
||||
常见的免费绘图工具包括[diagrams.net](https://app.diagrams.net/)和[Excalidraw](https://excalidraw.com/)。 最好事先熟悉一下这些工具。
|
||||
|
||||
* * *
|
||||
|
||||
## Data Model
|
||||
## 数据模型
|
||||
|
||||
**Objective**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
**目标**：描述各种数据实体、它们包含的字段以及它们属于哪个组件。
|
||||
|
||||
**Recommended Duration**: Roughly 10% of the session.
|
||||
**建议持续时间**：约占会议时间的10%。
|
||||
|
||||
We now have to think about what data fields are present in the client. There are two kinds of data on client applications:
|
||||
现在，我们必须考虑客户端中存在哪些数据字段。 客户端应用程序有两种数据：
|
||||
|
||||
### Server-originated Data
|
||||
### 服务器端数据
|
||||
|
||||
Data that originates from the server, usually from a database and meant to be seen by multiple people or accessed from multiple different devices. Common examples include user data (name, profile picture) and user-generated data (feed posts, comments).
|
||||
源自服务器的数据，通常来自数据库，可供多人查看或从多个不同设备访问。 常见的例子包括用户数据（姓名、个人头像）和用户生成的数据（动态帖子、评论）。
|
||||
|
||||
### Client-only Data
|
||||
### 仅客户端的数据
|
||||
|
||||
Client-only data, also commonly known as state, is data that only needs to live on the client and does not have to be sent to the server for writing into the database. Client data can be further broken down into two:
|
||||
客户端专用数据，通常也称为状态，是只需保存在客户端而无需发送到服务器写入数据库的数据。 客户数据可进一步细分为两种：
|
||||
|
||||
- **Data to be persisted**: Usually user input such as data entered into form fields. These data usually has to be sent to the server and saved into a database for it to be useful.
|
||||
- **Ephemeral data**: Temporary state that lasts for a short time. Common examples include form validation state, the current tab, whether a section is expanded, etc. It's usually acceptable to lose these data when the browser tab is closed.
|
||||
- **需要持久化的数据**：通常是用户输入，如输入到表单域中的数据。 这些数据通常必须发送到服务器并保存到数据库中才有用。
|
||||
- **短暂数据**：持续时间很短的临时状态。 常见的例子包括表单验证状态、当前选项卡、部分是否展开等。 关闭浏览器标签页时丢失这些数据通常是可以接受的。
|
||||
|
||||
When listing the data fields, it'd be useful to identify what kind of data that field is, whether it's server-originated data or client-only data.
|
||||
在列出数据字段时，最好能确定该字段是哪种数据，是服务器端数据还是客户端数据。
|
||||
|
||||
### Data Model Example
|
||||
### 数据模型示例
|
||||
|
||||
Here's a basic example of data model for the various entities using the [News Feed](/questions/system-design/news-feed-facebook) question.
|
||||
这是一个使用[信息流](/questions/system-design/news-feed-facebook)问题的各个实体数据模型的基本例子。
|
||||
|
||||
| Source | Entity | Belongs To | Fields |
|
||||
| ------------------- | --------- | ---------------- | -------------------------------------------------------------------------- |
|
||||
| Server | `Post` | Feed Post | `id`, `created_time`, `content`, `image`, `author` (a `User`), `reactions` |
|
||||
| Server | `Feed` | Feed UI | `posts` (list of `Post`s), `pagination` (pagination metadata) |
|
||||
| Server | `User` | Client Store | `id`, `name`, `profile_photo_url` |
|
||||
| User input (client) | `NewPost` | Feed Composer UI | `message`, `image` |
|
||||
| 来源 | 实体 | 属于 | 字段 |
|
||||
| --------- | --------- | ------- | -------------------------------------------------------------------------- |
|
||||
| 服务端 | `Post` | 信息流帖子 | `id`, `created_time`, `content`, `image`, `author` (a `User`), `reactions` |
|
||||
| 服务端 | `Feed` | 信息流UI | `posts`（`Post` 列表），`pagination `（分页元数据） |
|
||||
| 服务端 | `User` | 客户端存储 | `id`, `name`, `profile_photo_url` |
|
||||
| 用户输入（客户端） | `NewPost` | 帖子编辑器UI | `message`, `image` |
|
||||
|
||||
Depending on how far you progress along in the question and how the requirements have evolved and grown during the interview, you might need to add more fields. It's a dynamic and iterative process.
|
||||
根据你在问题中的进展以及要求在面试过程中的演变和增长，你可能需要添加更多字段。 这是一个动态和迭代的过程。
|
||||
|
||||
You might want to write these fields near the components which owns them in your architecture diagram.
|
||||
你可能想把这些字段写在你的架构图中拥有它们的组件附近。
|
||||
|
||||
* * *
|
||||
|
||||
## Interface Definition (API)
|
||||
## 接口定义 (API)
|
||||
|
||||
**Objective**: Define the interface between components in the product, functionality of the various APIs, their parameters and responses.
|
||||
**目标**：定义产品组件之间的接口、各种API的功能、参数和响应。
|
||||
|
||||
**Recommended Duration**: Roughly 15% of the session.
|
||||
**建议持续时间**：约占会议时间的15%。
|
||||
|
||||
With the components and data within each components, we can move on to discuss the interface (APIs) between the components. API is an overloaded term and generally refer to the protocol which software components communicate and request/send data between components. Client and server communicate via network layer APIs (HTTP/WebSockets). Client components generally communicate via functions in the browser runtime. All APIs have three things in common whether they are between the server and the client or between client components:
|
||||
有了组件和每个组件内的数据，我们就可以继续讨论组件之间的接口（API）了。 API是一个重载的术语，通常指软件组件之间通信和请求/发送数据的协议。 客户端和服务器通过网络层API（HTTP/WebSockets）进行通信。 客户端组件通常通过浏览器运行时的函数进行通信。 无论是在服务器和客户端之间，还是在客户端组件之间，所有的API都有三个共同点：
|
||||
|
||||
| Parts of an API | Server-Client | Client-Client |
|
||||
| ---------------------- | ------------------------------------ | --------------------- |
|
||||
| Name and functionality | HTTP path | JavaScript function |
|
||||
| Parameters | HTTP GET query and POST parameters | Function parameters |
|
||||
| Return Value | HTTP response, typically JSON format | Function return value |
|
||||
| API的组成部分 | 服务器-客户端 | 客户端-客户端 |
|
||||
| -------- | -------------------- | ------------- |
|
||||
| 名称和功能 | HTTP 路径 | JavaScript 函数 |
|
||||
| 参数 | HTTP GET 查询和 POST 参数 | 函数参数 |
|
||||
| 返回值 | HTTP 响应，一般为 JSON 格式 | 函数返回值 |
|
||||
|
||||
### Server-Client API Example
|
||||
### 服务器-客户端API示例
|
||||
|
||||
Using the [News Feed](/questions/system-design/news-feed-facebook) example yet again, we have a server API that allows the client to fetch the latest feed posts.
|
||||
再次以[信息流](/questions/system-design/news-feed-facebook)为例，我们有一个服务器 API，允许客户机获取最新的动态帖子。
|
||||
|
||||
| Field | Value |
|
||||
| ----------- | ------------------------------------ |
|
||||
| HTTP Method | `GET` |
|
||||
| Path | `/feed` |
|
||||
| 描述 | Fetches the feed results for a user. |
|
||||
| 字段 | 值 |
|
||||
| --------- | ------------------------------------ |
|
||||
| HTTP 方法 | `GET` |
|
||||
| 路径 | `/feed` |
|
||||
| 描述 | 为用户获取信息流结果。 |
|
||||
|
||||
#### Parameters
|
||||
#### 参数
|
||||
|
||||
A feed response is a paginated list so the API expects pagination parameters.
|
||||
一个信息流响应是一个带有分页的列表，因此API预期分页参数。
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -188,7 +188,7 @@ A feed response is a paginated list so the API expects pagination parameters.
|
|||
}
|
||||
```
|
||||
|
||||
#### Response
|
||||
#### 响应
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -216,49 +216,49 @@ A feed response is a paginated list so the API expects pagination parameters.
|
|||
}
|
||||
```
|
||||
|
||||
### Client-Client API Example
|
||||
### 客户端-客户端API示例
|
||||
|
||||
The client-client API can be written in a similar fashion as the server-client API, main difference being they are JavaScript functions, or events that are being listened to. The most important parts to describe are the functionality of the API, the parameters and the return/response value.
|
||||
客户端-客户端API的编写方式与服务器-客户端API类似，主要区别在于它们是JavaScript函数，或者是被监听的事件。 需要描述的最重要部分是API的功能、参数和返回/响应值。
|
||||
|
||||
### API for UI Component System Design
|
||||
### 用于UI组件系统设计的API
|
||||
|
||||
If you're asked to design a UI component, for the "Interface" section, discuss about the customization options for the component, similar to the props for React components.
|
||||
如果你被要求设计一个UI组件，在 "界面 "部分，讨论组件的自定义选项，类似于React组件的道具。
|
||||
|
||||
* * *
|
||||
|
||||
## Optimizations and Deep Dive
|
||||
## 优化和深入研究
|
||||
|
||||
**Objective**: Discuss about possible optimization opportunities and specific areas of interest when building the product.
|
||||
**目标**：讨论在构建产品时可能的优化机会和感兴趣的具体领域。
|
||||
|
||||
**Recommended Duration**: Roughly 40% of the session.
|
||||
**建议持续时间**：约占会议的40%。
|
||||
|
||||
There's no fixed way to go about the optimization and deep dive section and you are free to focus on different areas of the product. There will not be sufficient time to cover every area, so select how you want to spend your time carefully according to these guidelines:
|
||||
优化和深入研究部分没有固定的方法，您可以自由地关注产品的不同领域。 我们不会有足够的时间来涵盖每一个领域，因此请根据这些指导原则谨慎选择您希望花费的时间：
|
||||
|
||||
- **Focus on the important areas of the product.** For e-commerce websites, performance is crucial and you'd want to spend the bulk of your time diving into the various performance optimizations that can be done. For collaborative editors, the complexity is in how to handle race conditions and concurrent modifications, so you'd want to focus on explaining that.
|
||||
- **Focus on your strengths.** Showcase your domain knowledge. If you are well-versed in accessibility, talk about the various accessibility pitfalls that can occur in the product and how to address them. Impress the interviewer with your knowledge. If you are a performance guru, explain the various performance optimization opportunities that can provide a buttery smooth user experience.
|
||||
- **关注产品的重要领域** 对于电子商务网站，性能至关重要，您应该花大量时间深入了解可以进行的各种性能优化。 对于协作编辑器，复杂性在于如何处理竞赛条件和并发修改，因此您需要重点解释这一点。
|
||||
- **专注于您的优势**展示您的领域知识。 如果您精通无障碍性，请谈谈产品中可能出现的各种无障碍性隐患以及如何解决这些问题。 用您的知识打动面试官。 如果您是性能专家，请解释各种性能优化机会，以提供流畅的用户体验。
|
||||
|
||||
### General Optimization/Deep Dive Areas
|
||||
### 一般优化/深潜领域
|
||||
|
||||
Here's a list of topics you can talk about for this section. Bear in mind that the importance of a topic depends on the question and some topics are entirely irrelevant to certain questions (possible but unlikely).
|
||||
以下是您在本节中可以谈论的话题列表。 请注意，题目的重要性取决于问题，有些题目与某些问题完全无关（有可能，但可能性不大）。
|
||||
|
||||
- Performance
|
||||
- User Experience
|
||||
- Network
|
||||
- Accessibility (a11y)
|
||||
- Multilingual Support
|
||||
- Multi-device Support
|
||||
- Security
|
||||
- 性能
|
||||
- 用户体验
|
||||
- 网络
|
||||
- 可访问性（a11y）
|
||||
- 多语言支持
|
||||
- 多设备支持
|
||||
- 安全
|
||||
|
||||
Refer to our [Best Practices for Building User Interfaces Guide](/front-end-interview-guidebook/user-interface-questions-cheatsheet) for details on each topic.
|
||||
有关每个主题的详细信息，请参阅我们的[构建用户界面的最佳实践指南](/front-end-interview-guidebook/user-interface-questions-cheatsheet)。
|
||||
|
||||
* * *
|
||||
|
||||
## Summary
|
||||
## 总结
|
||||
|
||||
| Step | Objective | Recommended Duration |
|
||||
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | -------------------- |
|
||||
| Requirements Exploration | Understand the problem thoroughly and determine the scope by asking a number of clarifying questions. | \<15% |
|
||||
| Architecture/High-level Design | Identify the key components of the product and how they are related to each other. | ~20% |
|
||||
| Data Model | Describe the various data entities, the fields they contain and which component(s) they belong to. | ~10% |
|
||||
| Interface Definition | Define the interface (API) between components in the product, functionality of each APIs, their parameters and responses. | ~15% |
|
||||
| Optimizations and Deep Dive | Discuss about possible optimization opportunities and specific areas of interest when building the product. | ~40% |
|
||||
| 步骤 | 目标 | 推荐时长 |
|
||||
| ------- | ------------------------------------ | ----- |
|
||||
| 需求探索 | 通过提出一些明确的问题来全面了解问题并确定其范围。 | \<15% |
|
||||
| 架构/高级设计 | 识别产品的关键部件以及它们之间的关系。 | ~20% |
|
||||
| 数据模型 | 描述各种数据实体、它们包含的字段以及它们属于哪个组件。 | ~10% |
|
||||
| 接口定义 | 定义产品的组件之间的接口 (API)，每个 API 的功能、参数和响应。 | ~15% |
|
||||
| 优化和深入研究 | 讨论在构建产品时可能的优化机会和感兴趣的具体领域。 | ~40% |
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Nas entrevistas tradicionais de design de sistemas para Engenheiros de Software,
|
|||
| Coletar requisitos | Obrigatório | Obrigatório |
|
||||
| Arquitetura/design de alto nível | Serviços em nuvem distribuídos | Aplicação/Componente |
|
||||
| Estimativa rápida | Obrigatório | Não obrigatório |
|
||||
| Components of the system | Serviços em nuvem (por exemplo, balanceador de carga, servidor de aplicação, banco de dados, armazenamento de arquivos, caches, filas de mensagens, CDN) | Módulos de aplicação (Modelo, Visualização, Controlador) |
|
||||
| Componentes do sistema | Serviços em nuvem (por exemplo, balanceador de carga, servidor de aplicação, banco de dados, armazenamento de arquivos, caches, filas de mensagens, CDN) | Módulos de aplicação (Modelo, Visualização, Controlador) |
|
||||
| Modelo de dados | Esquema SQL | Estado da aplicação |
|
||||
| Tipo de APIs entre os componentes | Rede (qualquer protocolo) | Rede (HTTP, WebSocket), funções JavaScript |
|
||||
| Áreas de foco | Escalabilidade, Confiabilidade, Disponibilidade | Desempenho, Experiência do Usuário, Acessibilidade, Internacionalização |
|
||||
|
|
|
|||
|
|
@ -1,46 +1,46 @@
|
|||
---
|
||||
title: Introduction to Front End System Design
|
||||
description: Learn useful techniques and how to approach the top front end system design questions, written by ex-interviewers at FAANG.
|
||||
seo_title: Front End System Design Guide | Concepts, Techniques and Questions
|
||||
title: 前端系统设计简介
|
||||
description: 学习有用的技巧以及如何处理前端系统设计的首要问题，由FAANG的前面试官撰写。
|
||||
seo_title: 前端系统设计指南｜概念、技术和问题
|
||||
---
|
||||
|
||||
Unlike coding and quiz questions, system design interviews are open-ended style interviews where there are no right answers. You're given a vague problem or scenario and you're expected to work with the interviewer to answer the question by coming up with a suitable software design on a whiteboard, or some collaborative drawing app if it's a virtual interview. It is similar to the process at certain companies where engineers write technical design documents to outline the possible approaches to a project they are working on, explain technical decisions and discuss tradeoffs with coworkers except that you have to do it within 30-60 minutes.
|
||||
与编码和问答题不同，系统设计面试是开放式面试，没有正确答案。 面试官会给您一个模糊的问题或场景，您需要与面试官合作，在白板上（如果是虚拟面试，则使用一些协作绘图应用程序）设计出合适的软件来回答问题。 这类似于某些公司的流程，即工程师撰写技术设计文件，概述他们正在进行的项目的可能方法，解释技术决策，并与同事讨论取舍，但您必须在30-60分钟内完成。
|
||||
|
||||
System design interviews are usually given to candidates who have some number of years of working experience (aka non-fresh grads) and your performance in the system design interview has significant influence on the job level you will be offered. Most of the time, failing the system design interview will result in an overall rejection. It's really important to ace your system design interviews!
|
||||
系统设计面试通常是给有一定年限工作经验的应聘者（又称非应届毕业生），您在系统设计面试中的表现对您将获得的职位级别有重要影响。 在大多数情况下，系统设计面试失败将导致整体被拒。 通过系统设计面试非常重要！
|
||||
|
||||
However, given the open-ended nature of system design interviews, it is much harder to practice for it as compared to coding interviews. Many candidates also don't have real life experience building various systems and it's hard to draw from experience when answering system design interview questions. Also, there are very few resources available for front end system design. Most existing system design resources are targeted at general Software Engineers and hence focus on distributed systems.
|
||||
然而，鉴于系统设计面试的开放性，与编码面试相比，系统设计面试的练习难度要大得多。 许多应聘者也没有构建各种系统的实际经验，因此在回答系统设计面试问题时很难从经验中吸取教训。 此外，用于前端系统设计的资源非常少。 大多数现有的系统设计资源都是针对普通软件工程师的，因此侧重于分布式系统。
|
||||
|
||||
GreatFrontEnd's system design resources are perhaps the most comprehensive you can find and will help you handle front end system design interviews with ease!
|
||||
GreatFrontEnd的系统设计资源也许是您能找到的最全面的资源，将帮助您轻松应对前端系统设计面试！
|
||||
|
||||
## Front End vs Back End System Design
|
||||
## 前端与后端系统设计
|
||||
|
||||
In traditional Software Engineer system design interviews, candidates will be asked to describe the architecture of a distributed system, usually involving web servers, load balancers, caches, databases, microservices, task queues, etc. For Front End Engineers, system design interviews are slightly different, there's more emphasis on what goes on in the client and API design between the client and the server, as opposed to what goes on in the back end.
|
||||
在传统的软件工程师系统设计面试中，应聘者会被要求描述分布式系统的架构，通常涉及Web服务器、负载均衡器、缓存、数据库、微服务、任务队列等。 对于前端工程师来说，系统设计面试略有不同，与后端相比，面试更注重客户端以及客户端与服务器之间的API设计。
|
||||
|
||||
| Aspect | Back End | Front End |
|
||||
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- |
|
||||
| Gather requirements | Required | Required |
|
||||
| Architecture/High-level design | Distributed cloud services | Application/Component |
|
||||
| Back-of-the-envelope estimation | Required | Not required |
|
||||
| Components of the system | Cloud services (e.g. Load balancer, Application server, Database, File storage, Caches, Message queues, CDN) | Application modules (Model, View, Controller) |
|
||||
| Data Model | SQL Schema | Application state |
|
||||
| Type of APIs between components | Network (Any protocol) | Network (HTTP, WebSocket), JavaScript functions |
|
||||
| Focus areas | Scalability, Reliability, Availability | Performance, User Experience, Accessibility, Internationalization |
|
||||
| Less important (Can treat as a black box) | 客户端 | Server |
|
||||
| 方面 | 后端 | 前端 |
|
||||
| ------------- | --------------------------------------- | ------------------------------- |
|
||||
| 收集需求 | 需要 | 需要 |
|
||||
| 架构/高级设计 | 分布式云服务 | 应用/组件 |
|
||||
| 事后估算 | 需要 | 不需要 |
|
||||
| 系统组成 | 云服务（例如负载平衡器、应用服务器、数据库、文件存储、缓存、消息队列、CDN） | 应用模块（模型、视图、控制器） |
|
||||
| 数据模型 | SQL Schema | 应用状态 |
|
||||
| 组件之间的API类型 | 网络（任何协议） | 网络（HTTP、WebSocket）、JavaScript函数 |
|
||||
| 关注领域 | 可扩展性、可靠性和可用性 | 性能、用户体验、可访问性、国际化 |
|
||||
| 不太重要（可作为黑盒处理） | 客户端 | 服务端 |
|
||||
|
||||
_Read more on the differences between Front End and Back End System Design Interviews on [Zhenghao's blog](https://www.zhenghao.io/posts/system-design-interviews)._
|
||||
在郑浩的博客上阅读有关前端和后端系统设计面试之间的区别的更多内容。
|
||||
|
||||
For example, a classic question is to ask about designing a Twitter feed UI which can be asked during both back end and front end system interviews.
|
||||
例如，在后端和前端系统面试中都可能被问到的一个典型问题是关于设计 Twitter 动态 UI 的问题。
|
||||
|
||||
- **Back end**: Capacity estimation, designing the database schemas, how to ensure the services can scale with the traffic, how to generate a user's Twitter feed?
|
||||
- **Front end**: How do you implement the interactions with a tweet, how to implement pagination in the feed, and how users can create new tweets?
|
||||
- **后端**：容量估算，设计数据库模式，如何确保服务能够随着流量扩展，如何生成用户的Twitter信息流？
|
||||
- **前端**：你如何实现与推文的交互，如何在动态中实现分页，以及用户如何创建新推文？
|
||||
|
||||
As you can see, the focus of front end system design interviews can be very different from back end and answering them well requires a different approach.
|
||||
正如您所看到的，前端系统设计面试的重点可能与后端截然不同，要回答好这些问题需要采用不同的方法。
|
||||
|
||||
## What you will learn in this guide
|
||||
## 您将在本指南中学到什么
|
||||
|
||||
Our Front End System Design guide is structured into two parts, you will first gain a deeper understanding system design interviews are about, then dive into some front end system design case studies using the RADIO framework.
|
||||
我们的前端系统设计指南分为两部分，首先您将深入了解系统设计面试的内容，然后使用RADIO框架深入研究一些前端系统设计案例。
|
||||
|
||||
- [Types of Front End System Design questions and examples](/system-design/types-of-questions)
|
||||
- [Framework for answering Front End System Design questions](/system-design/framework)
|
||||
- [How you are being evaluated and what interviewers are looking out for](/system-design/evaluation-axes)
|
||||
- [Common mistakes to avoid](/system-design/common-mistakes)
|
||||
- [前端系统设计问题类型和示例](/system-design/types-of-questions)
|
||||
- [回答前端系统设计问题的框架](/system-design/framework)
|
||||
- [如何对您进行评估以及面试官会注意什么](/system-design/evaluation-axes)
|
||||
- [应避免的常见错误](/system-design/common-mistakes)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Types of Front End System Design Questions
|
||||
title: Tipos de perguntas de design de sistema front-end
|
||||
description: Formatos de perguntas que você pode esperar em uma entrevista de design de sistema de front end.
|
||||
seo_title: Tipos de perguntas em entrevistas de design de sistema de front end
|
||||
seo_description: Aprenda os dois tipos de perguntas de design de sistema de front end e como abordá-las de forma diferente.
|
||||
|
|
@ -11,7 +11,7 @@ Existem dois tipos principais de perguntas de design de sistema de front end: (1
|
|||
|
||||
Conforme mencionado acima, projetar aplicações para entrevistas de design de sistema de front end será semelhante às entrevistas gerais de design de sistema de Engenharia de Software e, de fato, as perguntas são muito parecidas. No entanto, em vez de falar sobre sistemas distribuídos, você deve se concentrar no lado do cliente e discutir sobre a arquitetura da aplicação e os detalhes de implementação no lado do cliente.
|
||||
|
||||
Nos dias de hoje, muitos sites são interativos e aplicativos ricos que podem realizar virtualmente o que muitos aplicativos de desktop são capazes. Se você já usou o Gmail, Facebook, YouTube ou Google Calendar na web, você já utilizou um aplicativo web. Os aplicativos web geralmente são dinâmicos e as navegações em um aplicativo web geralmente não exigem uma atualização completa da página. Em vez disso, eles usam JavaScript para buscar dados remotos para a próxima página e alterar dinamicamente o conteúdo e o URL. Como os aplicativos web são softwares complexos que envolvem vários módulos, as arquiteturas comuns de aplicativos que aprendemos nas aulas de Engenharia de Software, como o Model-View-Controller (MVC) e o Model-View-ViewModel (MVVM), também são aplicáveis na construção de aplicativos web. React is one of the most popular JavaScript libraries by Facebook to build interactive web applications and many React web apps adopt a unidirectional Flux/Redux-based architecture.
|
||||
Nos dias de hoje, muitos sites são interativos e aplicativos ricos que podem realizar virtualmente o que muitos aplicativos de desktop são capazes. Se você já usou o Gmail, Facebook, YouTube ou Google Calendar na web, você já utilizou um aplicativo web. Os aplicativos web geralmente são dinâmicos e as navegações em um aplicativo web geralmente não exigem uma atualização completa da página. Em vez disso, eles usam JavaScript para buscar dados remotos para a próxima página e alterar dinamicamente o conteúdo e o URL. Como os aplicativos web são softwares complexos que envolvem vários módulos, as arquiteturas comuns de aplicativos que aprendemos nas aulas de Engenharia de Software, como o Model-View-Controller (MVC) e o Model-View-ViewModel (MVVM), também são aplicáveis na construção de aplicativos web. O React é uma das bibliotecas JavaScript mais populares do Facebook para criar aplicativos da Web interativos e muitos aplicativos da Web do React adotam uma arquitetura baseada em Flux/Redux unidirecional.
|
||||
|
||||
Diferentes aplicativos têm seus próprios aspectos únicos e pontos de discussão. É imperativo que você se concentre nas partes que são únicas para o aplicativo e não gaste muito tempo falando sobre coisas gerais que são aplicáveis a todas as perguntas. Primeiramente, projete a arquitetura de alto nível, identifique os componentes no sistema e a API entre os componentes. Em seguida, aprofunde-se em algumas áreas que são interessantes para o problema e discuta como implementá-las ou otimizá-las.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ Você pode ter que escrever um pequeno trecho de código para um ou mais dos seg
|
|||
|
||||
### Personalização do tema
|
||||
|
||||
Certamente será esperado que você projete uma forma para os usuários do componente (desenvolvedores) personalizarem a aparência do componente. Consulte [Seção de Princípios de API de Design de Componentes UI do Front Enend Guidebook](/front-end-interview-guidebook/user-interface-components-api-design-principles) para uma visão geral e comparação das diferentes abordagens.
|
||||
Certamente será esperado que você projete uma forma para os usuários do componente (desenvolvedores) personalizarem a aparência do componente. Consulte [Seção de Princípios de API no Design de Componentes de UI do Front End Guidebook](/front-end-interview-guidebook/user-interface-components-api-design-principles) para uma visão geral e comparação das diferentes abordagens.
|
||||
|
||||
### Exemplos
|
||||
|
||||
|
|
|
|||
|
|
@ -1,55 +1,55 @@
|
|||
---
|
||||
title: Types of Front End System Design Questions
|
||||
description: Question formats you can expect in a front end system design interview.
|
||||
seo_title: Types of Questions in Front End System Design Interviews
|
||||
seo_description: Learn the two types of front end system design questions and how to tackle them differently.
|
||||
title: 前端系统设计问题类型
|
||||
description: 前端系统设计面试的提问形式。
|
||||
seo_title: 前端系统设计面试中的问题类型
|
||||
seo_description: 了解两种类型的前端系统设计问题，以及如何以不同的方式解决这些问题。
|
||||
---
|
||||
|
||||
There are two main kinds of front end system design questions: (1) Applications and (2) UI components.
|
||||
前端系统设计问题主要有两种：(1)应用和(2)用户界面组件。
|
||||
|
||||
## Applications
|
||||
## 应用
|
||||
|
||||
As mentioned above, designing applications for front end system design interviews will feel similar to general Software Engineering system design interviews, and in fact, the questions are highly similar. However, instead of talking about distributed systems, you should focus on the client side of things and talk about application architecture and client-side implementation details.
|
||||
如上所述，为前端系统设计面试设计应用软件与一般的软件工程系统设计面试感觉类似，事实上，问题也高度相似。 然而，与其谈论分布式系统，不如关注客户端，讨论应用架构和客户端实现细节。
|
||||
|
||||
In this day and age, many websites are interactive and rich applications that can do virtually what many desktop applications can. If you've used Gmail, Facebook, YouTube, Google Calender on the web, you'd have used a web app. Web apps tend to be dynamic and navigations in a web app usually don't require a full page refresh and instead use JavaScript to fetch remote data for the next page and dynamically change the contents and URL. Since web apps are complex software involving multiple modules, the common application architectures we learnt in Software Engineering classes like Model-view-controller (MVC), Model-view-viewmodel (MVVM) are also applicable when building web apps. React is one of the most popular JavaScript libraries by Facebook to build interactive web applications and many React web apps adopt a unidirectional Flux/Redux-based architecture.
|
||||
在当今时代，许多网站都是交互式的丰富应用程序，几乎可以实现许多桌面应用程序所能实现的功能。 如果您在网页上使用 Gmail、Facebook、YouTube、Google Calender，您已经使用了Web 应用程序。 Web 应用往往是动态的，Web 应用中的导航通常不需要刷新整个页面，而是使用JavaScript获取下一页的远程数据，并动态更改内容和URL。 由于Web 应用是涉及多个模块的复杂软件，我们在软件工程课程中学到的常见应用架构，如模型-视图-控制器（MVC）、模型-视图-视图模型（MVVM），在构建Web 应用时也同样适用。 React是Facebook最流行的JavaScript库之一，用于构建交互式Web应用程序，许多React Web应用程序采用基于Flux/Redux的单向架构。
|
||||
|
||||
Different applications have their own unique aspects and talking points. It's imperative that you focus on the parts that are unique to the application and not spend too much time talking about general stuff that are applicable to all questions. Firstly, design the high-level architecture, identify the components in the system, and the API between the components. Then dive into a few areas that are interesting to the problem and how to implement or optimize them.
|
||||
不同的应用有其独特的方面和谈话要点。 您必须将重点放在申请材料的独特之处，而不要花太多时间谈论适用于所有问题的一般性内容。 首先，设计高层架构，确定系统中的组件以及组件之间的API。 然后深入研究与问题相关的几个方面，以及如何实施或优化这些方面。
|
||||
|
||||
### Examples
|
||||
### 实例
|
||||
|
||||
Here's a list of application questions commonly asked during front end system design interviews and the areas you should focus on:
|
||||
以下是前端系统设计面试中常见的应用问题列表，以及您应重点关注的领域：
|
||||
|
||||
| Application | Examples | Important Areas |
|
||||
| --------------------------------------------------------------------- | ------------------------------------------------- | -------------------------------------------------------------------- |
|
||||
| [News Feed](/questions/system-design/news-feed-facebook) | Facebook, Twitter | Feed interactions, Feed pagination approaches, Message/post composer |
|
||||
| [Messaging/Chat](/questions/system-design/chat-application-messenger) | Messenger, Slack, Discord | Message syncing, Real-time chat, Messages list, Chat list |
|
||||
| [E-commerce Marketplaces](/questions/system-design/e-commerce-amazon) | Amazon, eBay | Product listing pages, Product detail pages, Cart, Checkout |
|
||||
| [Photo Sharing](/questions/system-design/photo-sharing-instagram) | Instagram, Flickr, Google Photos | Photos browsing, Photos editing, Photos uploading |
|
||||
| [Travel Booking](/questions/system-design/travel-booking-airbnb) | Airbnb, Skyscanner | Search UI, Search results, Booking UI |
|
||||
| [Email Client](/questions/system-design/email-client-outlook) | Outlook, Apple Mail, Gmail | Mailbox syncing, Mailbox UI, Email composer, |
|
||||
| Video Streaming | YouTube, Netflix, TikTok | Video player, Video streaming, Video detail page, Recommended videos |
|
||||
| Collaborative Apps | Google Docs, Google Sheets, Google Slides, Notion | Real-time collaboration, State syncing |
|
||||
| Drawing | Figma, Lucidchart | Rendering approach, Client state/data model |
|
||||
| Maps | Google/Apple Maps, Foursquare City Guide | Map rendering, Displaying locations |
|
||||
| File Storage | Google Drive, Dropbox | File uploading, File downloading, File explorer |
|
||||
| Video Conferencing | Zoom, Google Meet | Video streaming, Various viewing modes |
|
||||
| Ridesharing | Uber, Lyft | Trip booking, Driver location |
|
||||
| Music Streaming | Spotify, Apple Music | Music player UI, Playlists UI |
|
||||
| Games | Tetris, Snake | Game state, Game loop, Game logic |
|
||||
| 应用 | 示例 | 重要领域 |
|
||||
| ------------------------------------------------------------ | -------------------------------- | ------------------------ |
|
||||
| [信息流](/questions/system-design/news-feed-facebook) | Facebook, Twitter | 按钮交互， 动态内容分页方法， 消息/帖子编辑器 |
|
||||
| [消息/聊天](/questions/system-design/chat-application-messenger) | Messenger, Slack, Discord | 消息同步、实时聊天、消息列表、聊天列表 |
|
||||
| [电子商务市场](/questions/system-design/e-commerce-amazon) | Amazon, eBay | 产品列表页, 产品详情页, 购物车, 结账 |
|
||||
| [照片共享](/questions/system-design/photo-sharing-instagram) | Instagram, Flickr, Google Photos | 照片浏览，照片编辑，照片上传 |
|
||||
| [旅行预订](/questions/system-design/travel-booking-airbnb) | Airbnb, Skyscanner | 搜索用户界面, 搜索结果, 预订用户界面 |
|
||||
| [电子邮件客户端](/questions/system-design/email-client-outlook) | Outlook, Apple Mail, Gmail | 邮箱同步、邮箱UI、邮件编辑器、 |
|
||||
| 视频流媒体 | YouTube, Netflix, TikTok | 视频播放器, 视频流, 视频详情页, 推荐视频 |
|
||||
| 协作应用 | 谷歌文档，谷歌表单，谷歌幻灯片，Notion | 实时协作，状态同步 |
|
||||
| 作图 | Figma, Lucidchart | 渲染方法，客户端状态/数据模型 |
|
||||
| 地图 | 谷歌/苹果地图，Foursquare City Guide | 地图渲染，显示位置 |
|
||||
| 文件存储 | Google Drive, Dropbox | 文件上传，文件下载，文件浏览器 |
|
||||
| 视频会议 | Zoom, Google Meet | 视频流，多种观看模式 |
|
||||
| 拼车服务 | Uber, Lyft | 行程预订, 司机位置 |
|
||||
| 音乐流媒体 | Spotify, Apple Music | 音乐播放器用户界面，播放列表用户界面 |
|
||||
| 游戏 | Tetris, Snake | 游戏状态, 游戏循环, 游戏逻辑 |
|
||||
|
||||
## UI Components
|
||||
## 用户界面组件
|
||||
|
||||
In modern front end development, it is common to use component libraries to build applications. Some popular component libraries you might have used before include jQuery UI (how old school!), Bootstrap, Material UI, Chakra UI, etc.
|
||||
在现代前端开发中，通常使用组件库来构建应用程序。 一些流行的组件库您可能已经使用过，包括jQuery UI（多么老派！）、Bootstrap、Material UI、Chakra UI等。
|
||||
|
||||
It is an expectation of Front End Engineers to be able to build the various UI components needed by an application. Some UI components can be easy to build (e.g. text, button, badge, etc), while others can be much more complex (autocomplete, dropdown, modal, etc). Most of the time, if you are asked to design a UI component, it would be from the latter category.
|
||||
前端工程师需要能够构建应用程序所需的各种用户界面组件。 有些用户界面组件很容易构建（例如文本、按钮、徽章等），而其他组件则可能要复杂得多（自动完成、下拉、模态等）。 大多数情况下，如果您被要求设计一个用户界面组件，它将属于后一类。
|
||||
|
||||
Firstly determine the subcomponents of the component (e.g. for an image carousel, there's the image, the pagination buttons, thumbnails), define the external-facing API of the component (what options/props the component should accept), describe the internal component state, API between the subcomponents (if relevant), then dive into optimizations and considerations for performance, accessibility, user experience, security, etc where relevant.
|
||||
首先确定组件的子组件（例如，对于一个图片传送带，有图片、分页按钮、缩略图），定义组件的对外API（组件应该接受哪些选项/道具），描述组件的内部状态、子组件之间的API（如果相关），然后深入到性能、可访问性、用户体验、安全性等相关的优化和考虑。
|
||||
|
||||
You might have to write a small amount code for one or more of the following purposes:
|
||||
您可能需要为以下一个或多个目的编写少量代码：
|
||||
|
||||
1. Describe the component hierarchy.
|
||||
2. Describe the shape of the component state.
|
||||
3. Explain some non-trivial logic within the component.
|
||||
1. 描述组件层次结构。
|
||||
2. 描述组件状态的形状。
|
||||
3. 解释一些组件中的非平凡逻辑。
|
||||
|
||||
```jsx
|
||||
<ImageCarousel
|
||||
|
|
@ -62,23 +62,23 @@ You might have to write a small amount code for one or more of the following pur
|
|||
</ImageCarousel>
|
||||
```
|
||||
|
||||
### Customizing Theming
|
||||
### 自定义主题
|
||||
|
||||
You will most certainly be expected to design a way for users of the component (developers) to customize the component appearance. Refer to [Front End Interview Guidebook's UI Components API Design Principles Section](/front-end-interview-guidebook/user-interface-components-api-design-principles) for an overview and comparison of the different approaches.
|
||||
您肯定需要为组件的用户（开发人员）设计一种自定义组件外观的方法。 请参阅[前端面试指导手册的用户界面组件API设计原则部分](/front-end-interview-guidebook/user-interface-components-api-design-principles)，了解不同方法的概述和比较。
|
||||
|
||||
### Examples
|
||||
### 示例
|
||||
|
||||
Examples of UI components asked during front end system design interviews:
|
||||
在前端系统设计访谈中提出的用户界面组件示例：
|
||||
|
||||
- Design an [autocomplete component](/questions/system-design/autocomplete)
|
||||
- Design a [dropdown menu component](/questions/system-design/dropdown-menu)
|
||||
- Design an [embeddable poll widget](/questions/system-design/poll-widget)
|
||||
- Design an [image carousel](/questions/system-design/image-carousel)
|
||||
- Design a [modal component](/questions/system-design/modal-dialog)
|
||||
- Design a data table with sorting and pagination
|
||||
- Design a datepicker
|
||||
- Design a multiselect component
|
||||
- 设计一个[自动完成组件](/questions/system-design/autocomplete)
|
||||
- 设计一个[下拉菜单组件](/questions/system-design/dropdown-menu)
|
||||
- 设计一个[可嵌入的投票小部件](/questions/system-design/poll-widget)
|
||||
- 设计一个[图片轮播](/questions/system-design/image-carousel)
|
||||
- 设计一个[模态组件](/questions/system-design/modal-dialog)
|
||||
- 设计一个带排序和分页功能的数据表
|
||||
- 设计一个日期选择器
|
||||
- 设计一个多选组件
|
||||
|
||||
## What to do during interviews?
|
||||
## 面试时该做什么？
|
||||
|
||||
Now that you have an understanding of the kind of questions you can be asked during Front End System Design interviews, how do you go about answering them? We came up with the [RADIO framework](/system-design/framework), an easy-to-remember structured approach that you can use to ace system design interview questions.
|
||||
既然您已经了解了前端系统设计面试中可能会问到的问题类型，那么该如何回答这些问题呢？ 我们提出了[RADIO框架](/system-design/framework)，这是一种易于记忆的结构化方法，您可以用它来应对系统设计面试问题。
|
||||
|
|
|
|||
Loading…
Reference in New Issue