转载

前端困境：个人篇

对于我而言，在这方面的困扰并不大——毕竟《我的职业是前端工程师》，而我的本质上还是工程师。也因此，我有诸多的额外知识领域：

Serverless。
后端。
IoT。
原生移动应用开发。
混合移动应用开发。

笑，所以在写 Serverless 相关文章的时候，我总是自豪地说：『后端不就是 CRUD 吗？』。在使用 Python 编写我的博客（ https://www.phodal.com ），我得考虑并发、缓存、数据备份 blabla，但是有了 Serverless 之后，我编写个函数即可。在有了企业级的 Serverless/FaaS 服务之后，后端便是 CRUD，笑。

然而并非很有的前端工程师，都准备好应对危机的到来，尤其是那些非科班出身的程序员——他/她们会在未来遇到更大的挑战。因为他/她的知识领域，在某种程度上限制了往其它方向发展的可能性。

前端困境

后端嘛，嗯，日常就是 CRUD。前端嘛，嗯，日常就是画画页面。所以，为了提升我的前端能力，我开始学学画画（手动滑稽~）：

回到日常的开发上，你是不是发现你遇到如下的问题：

觉得每天在写业务代码，没有成就感？
尽管功能很简单，但是很重复，却无能为力？
项目的代码质量，一塌糊涂，却不了了之？
想提升却找不到提升的方向？
学了一堆屠龙之床，却找不到用的地方？
一遇到复杂的问题，是不是就无解发？

生活就是这么无奈。

这些问题，从某种情况上来说，是因为，我们高不成，低不就。日常的大部分工作里，用的都是普通的技术，也没有能力去尝试新的架构模式。而一旦，我们需要使用复杂的架构时，却没有足够的经验和尝试的勇气。

而这样的事情，在我们的日常工作中却在不断地重复中。

我们陷入了技术的困境。

所以，我们都在尝试寻找一些解决方案。

解决方案

应对这些挑战，我先总结一下，我的相关经验。

技术抽象业务

写业务代码是无味的，无趣的，无乐可言的。不想写业务代码，那是不可能的。抽象业务，便是应对于乏味生活的一种乐趣。对应的也有几种方式：

领域特定语言。这是我在 2018 年尝试过的一个解决方案，应对于某一类千篇一律的前端页面来说，它是一种颇为有效的方式。Builder 形式的内部 DSL，JSON 形式的数据 DSL，自定义数据格式的外部 DSL，都是一些不错的方案。
Clean Architecture。整洁架构，是我们正在尝试的一种方案。它为将我们带来业务代码与 UI 抽象的一种可能性，降低分层之间的偶合，并提升系统之间的复用率。
代码生成。它非常棒，当你每天需要 Copy/Paste 重复代码时，优先考虑使用复用和组件化，随后便是编写模板，再通过代码生成，如 Angular 里的 Schematics。
DDD 与六边模型。领域（业务）驱动设计是针对于业务的抽象化实施，它也成为了我在前端的一个新的试验——只是目前缺乏一个新的场景。

如果你有业务上的折磨，试试这些方案。

引入新思想

引入入新的思想，而引入非新的设计。

我们引入 Rx.js，不是引入 Rx.js 这个框架，而是引入响应式编程的思想。
我们引入 Redux，不是引入 Redux 这个框架，而是引入状态管理的思想。
我们引入 Ramda.js，不是引入 Ramda.js 这个框架，而是引入函数式编程的思想。
……

思想永远比技术重要——当你尝试说服一个人时，你要说的是：『学习它的思想，而不是某某框架』。

当然了，如果你说的是：『为了引入新的技术』，那么我只能祝你好运了。

熟悉后端

一个有经验的前端，要有置疑后端 API 设计合理性的能力和勇气。应对的最好方式就是，有一定的后端能力。

RESTful API 设计。不懂 API 设计，那可要命了，你只能随后端不断改接口了。一个优秀的前端工程师，那可是要
后端架构。我们并不需要深入后端技术的原理，NoSQL 数据库、SQL 数据库、缓存数据库、搜索引擎、消息队列等，都要有一个基本的印象。至少，可以看懂后端的架构图，并画出后端的架构图。
开发后端应用。能写那就是最好的，那还需要后端做什么？

一个优秀的前端工程师，那是全能干工程师。