前端困境
在前端日常的开发上,你是不是发现你遇到如下的问题:
觉得每天在写业务代码,没有成就感?
尽管功能很简单,但是很重复,却无能为力?
项目的代码质量,一塌糊涂,却不了了之?
想提升却找不到提升的方向?
学了一堆屠龙之床,却找不到用的地方?
一遇到复杂的问题,是不是就无解发?
活就是这么无奈。
这些问题,从某种情况上来说,是因为,我们高不成,低不就。日常的大部分工作里,用的都是普通的技术,也没有能力去尝试新的架构模式。而一旦,我们需要使用复杂的架构时,却没有足够的经验和尝试的勇气。
而这样的事情,在我们的日常工作中却在不断地重复中。
我们陷入了技术的困境。
所以,我们都在尝试寻找一些解决方案。
解决方案
应对这些挑战,我先总结一下,我的相关经验。
技术抽象业务
写业务代码是无味的,无趣的,无乐可言的。不想写业务代码,那是不可能的。抽象业务,便是应对于乏味生活的一种乐趣。对应的也有几种方式:
领域特定语言。这是我在 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 数据库、缓存数据库、搜索引擎、消息队列等,都要有一个基本的印象。至少,可以看懂后端的架构图,并画出后端的架构图。
开发后端应用。能写那就是最好的,那还需要后端做什么?
一个优秀的前端工程师,那是全能干工程师。
加深技术储备
想成为一个优秀的工程师,就应该在学会可能用到的相关技术。
软件架构。在上一篇文章中,我介绍了一系列的架构书籍。对于一个程序员来说,我们需要对架构模式、架构风格、架构图等要有深入的研究。
构建系统。构建系统指的不单单是 Webpack 这部分内容,而是软件从源码到线上的所有过程。
版本管理。事实上,我发现大部分的工程师,在这方面都做得很糟糕。
DevOps。前端部署很简单,但是 Web 应用部署很复杂。
深入前端
前端,总是会遇到用时方恨少的时候。
应用性能。采集、分析、统计与优化
框架原理。无需多言。
前端特定架构。诸如于微前端架构系列,哈哈。
浏览器运行机制。诸如于从输入 URL 到打开网页发生了什么,这种
调试技能。对于我来说,这也是一个需要加强的技能——我使用 Console.log 的频率比调试再高,因为 Console.log 又快又方便。
技术广度
作为一个程序员,除了 Web 前端之外,其它的领域我们也要有所涉猎。除了与前端技术相关的:
跨平台应用开发。
Node.js 后端应用。
Electron/NW.js 桌面应用。
云原生技术。
Serverless
等.等..等...
效能提升
关注于更高维度的系统时,就会开始追求开发效率。
工程化。工程化意味着很多东西,像工程师一样思考。思考如何复用,如何大规模地开发前端应用——组件库、脚手架、代码生成等。
基础设施完善。通用基础库等
设计系统。
DesignOps。设计系统源于 UX,而 Design Ops 则由开发人员和设人员一起完成
- 点赞
- 收藏
- 关注作者
评论(0)