译者 ｜ Shalitha Suranga
译者者 ｜ 许志成
策画 ｜ 闫短蕊
Damazan ｜ 王磊
责任编辑起初发布于 Shalitha Suranga 博客，经原作许可由 InfoQ 英文站译者并撷取
那些专业技能不仅能协助你构筑出杰出的 Web 应用领域，还能对你生涯的提高有协助。
一般来说开发者都是为多种类型的应用软件工程项目展开合作开发组织工作。当今社会在如前所述云的应用软件工程项目中，更多的开发者是致力 Web 应用领域的合作开发。Web 应用领域的构架一般是由服务器端（API 服务）和应用领域程序（应用程序）两个互相可视化的部分组成。而他们都知道，应用领域程序主要是用以给使用者呈现出文本。
晚期的 Web 应用领域应用领域程序都是很高性能的，换句话说，在以前的 Web 应用领域应用领域程序中处理的销售业务方法论比较少。而那时，人们一直致力构筑譬如单网页应用领域（SPA）的富应用领域程序应用领域，在这样的富应用领域程序应用领域中，应用领域程序所包涵的销售业务方法论在数量和维数上都非但不逊于服务器端。
因此，在当代的 Web 应用领域合作开发行业中，就需要雇用更多的后端合作开发者来顺利完成应用领域程序的合作开发组织工作。当代的后端合作开发者绝大部分都是在譬如 React, Angular, Vue, Svelte 等构架上采用 JavaScript 或 TypeScript 展开合作开发组织工作。当然也有些开发者会采用构架近似于微后端商业模式的外部构架展开合作开发组织工作。
在我 10 十多年的 Web 应用领域合作开发组织工作中，我发现上面那些基本功有利于提高后端合作开发者的生涯。
一、在后端框架中利用 MVVM 商业模式
当今社会他们正处于透过采用使用者笔记本电脑的计算资源顺利完成 Web 应用领域销售业务方法论继续执行和可视化文本图形的黄金时代。在晚期 Web 应用领域中，合作开发者将大部份的销售业务方法论都放到服务器端继续执行，应用领域程序则只负责管理文本图形。但是那时更多的 Web 应用领域透过将 90% 左右的销售业务方法论放到应用领域程序继续执行来满足用户app应用领域等需求。
虽然当代的后端构架给合作开发者提供更多了各种各样的合作开发商业模式。但大部份非主流的构架都对采用 MVVM 商业模式展开编码提供更多了支持。比如：Angular 将 View 和 ViewModel 分立在 2 个分立文档中（两个 HTML 文档和两个 TS 文档），React 则将 View 和 ViewModel 以模块的形式嵌入在两个 JSX 文档中。
掌握常规 MVVM 商业模式的知识有利于你快速上手任何后端构架、编写出简洁的 UI 控制程序和可测试的代码。一些合作开发者可能会认为 React 既不是 MVVM 也不算 MVC，它只是两个用以操作 View 的库。然而，它却让合作开发者以 MVVM 的商业模式编写代码。因此掌握 MVVM 合作开发商业模式，有利于合作开发者判断哪些代码应该写在 View 中，哪些代码应该写在 Controller 中。
二、遵循一般可用性原则
一些在意使用者可用性的公司，会聘请 UI/UX 工程师参与到后端合作开发组织工作中，甚至有些公司还会成立 UX 团队，专门用于提高公司产品的可用性。一般来说，UI/UX 工程师的主要组织工作是原型设计、可用性测试、CSS 和 HTML 编写。然而，大多数公司的后端合作开发者也会在组织工作中采用 CSS 和 HTML。
因此，对于后端工程师而言，不管团队中是否有 UI/UX 工程师，掌握一些一般可行性原则，对其组织工作都是很有协助的。比如：你不再需要问 UI/UX 团队，两个确定按钮应该放到左边还是右边。一般可行性原则可以使他们的 Web 应用领域更加产品化，更加使用者友好，更加凸显为使用者考虑。
想象一下，每当你开始两个后端合作开发任务的时候，就需要考虑设计一致性、模块分类、元素排序、颜色、文本尺寸、文本样式、动画、响应设计等因素。然而，大多数应用领域的原型都没办法全部涵盖。因此，非常有必要花时间学习下一般可用性原则。
三、编写简洁的异步代码
采用 JavaScript 机可以写出同步代码也可以写出异步代码。众所周知，JS 是单线程的。因此上面这段代码就会让应用程序卡顿几秒。
for(let i = 0; i
所以他们需要高效利用 JavaScript 的线程机制。出于这个原因，绝大部分应用程序 API 的设计要么是如前所述事件机制要么是如前所述 promise 的异步机制。比如，当你采用 JS 创建两个 WebSocket 链接的时候，JavaScript 不会等待链接真正建立顺利完成，就像上面代码展示的那样：
let ws = new WebSocket(ws://localhost:80); // 创建ws链接
//ws.send(Hello) will fail // 如果这里继续执行消息发生，会失败掉，因为ws链接此时还未顺利完成
ws.addEventListener(open, () => {
ws.send(Hello) // works
});
因此他们需要订阅不同应用程序在不同时间继续执行的事件，这导致他们的 JS 代码变得非常复杂，所以要编写简洁的异步代码还是比较困难的。在处置应用程序事件的时候，部分初级工程师倾向于采用 setTimeout 函数的延迟继续执行来处置，而不采用合理的事件处置函数。这样就会导致在譬如应用程序、弱网、低端设备等不同应用领域程序上，相同的代码会出现各种各样非预期的行为。
所以，尽可能将事件的处置函数放到两个分立函数体内，避免采用随机延迟函数处置事件回调，在应用领域上下文退出的时及时清除事件处置函数，不要采用老的回调商业模式，采用 async/await 商业模式（如果非要采用，请采用 promise 转换下），避免在行内事件处置中添加销售业务方法论。
除此之外，经常练习编写简洁的代码是编写简洁的同步代码的秘诀，上面的文章阐述了每一开发者都可以写出简洁的代码。
应用软件工程项目的 5 个简洁代码实践：
https://betterprogramming.pub/5-clean-code-practices-for-every-software-project-479443b31c3c
四、熟悉应用程序 API 是 Web 应用领域合作开发的必要条件
老版本的应用程序提供更多了基本的 DOM 操作 API。后来，由于 JavaScript 的流行，W3C 引入了许多当代 Web API。因此那时他们可以透过采用应用领域程序存储、原生 HTTP 应用领域程序、语音合成、消息通知等 API 来构筑更加使用者友好的 Web 应用领域。与此同时，当代应用程序在 DOM 操作和图形上的支持上也比以前更加的智能和全面。
比如，以前他们并没有很好的方法来处置 DOM 元素尺寸变化的事件，而那时他们只需要采用 ResizeObserver API 就能顺利完成。在处置 RESTful 数据请求上，那时他们可以采用更高性能的 Fetch API 顺利完成，而不再需要采用老的如前所述 XHR 的第三方库（没错，Axios 也是如前所述 XHR 的）。
因此，在说“这个在使用者应用程序中是无法实现的”这句话之前，他们最好先查看下最新的应用程序 API。那时他们可以利用 WebAssembly API 在应用领域程序应用程序中运行一些高 CPU 消耗的任务。同时他们还可以利用 web workers 编写多线程的 JavaScript 操作。那时几乎没有人采用 IE11 访问当代的 web 应用了，所以在采用正式阶段（非试验阶段）的 web api 时，不必考虑再三。
五、理解后端的局限性
不知道你是否关注过慢而臃肿的 Web 应用领域程序？由于譬如冗余 UI 元素、静态资源未做 CDN 加速、沉重的第三方库或构架等原因，Web 应用领域一般来说会变的慢而臃肿。与此同时，如果你将大量的销售业务方法论放到应用领域程序继续执行，也会导致 Web 应用领域图形的比较慢。在不阻塞 JS 线程的情况下，将一些数据的排序和筛选放到客户端是没问题的，否则就需要将那些数据处置的操作放到服务器端或者数据库。
虽然 JavaScript 透过非阻塞操作提供更多了一种类似并行的机制，但两个应用程序实例在同一时间点是不能同时顺利完成 2 个 JavaScript 操作的，因此大量的数据操作会必然会让你的 Web 应用领域变的很慢。除此之外，过多的事件处置也会影响使 Web 应用领域变慢。所以需要确保事件处置的高效性，而且在应用领域上下文退出的时候，也要及时清理事件处置函数。
相对于如前所述云计算的后端服务，应用领域程序的资源是非常有限的。那时，人们依然在采用低端或中端的终端设备访问互联网。因此，一旦你在应用领域程序实现了比较重的功能时，就需要关注 Web 应用领域程序的内存占用描述文档。比如：上面的内存占用描述文档给出了 YouTube 在视频播放期间，其内存采用的信息。只需将上面的内存采用统计数据与您正在构筑的 Web 应用领域程序的内存采用情况展开比较即可。
原文链接：
https://www.infoq.cn/link?target=https%3A%2F%2Flevelup.gitconnected.com%2F5-skills-that-every-frontend-developer-should-improve-8b613752fa34
