It’s not a strategy—a little experience from someone who came from the front end

alt

Before I knew it, I had been working on the front end for three and a half years. I also have some personal opinions (with bias) in my continuous learning and summarization. Here's a plate:

Three misunderstandings of front-end learning:

1. Chase new

Many front-end er will always pay attention to the dynamics of new technologies and new frameworks. Once there is something new, immediately read the official documentation and get started. I feel as if I have learned some powerful martial arts cheats. In fact, there is not much improvement in this kind of self-growth.

For programmers, it is necessary to maintain this mentality at all times: "Technology is only a tool to solve problems, and the ability to learn and think is what a programmer should have."

Because the front-end technologies are many and complex, and most of them are tools. "To learn a skill, we must first understand what it can do? Do we really need it?"

2. Focus on one point

When I first started working on the front end, I was always used to focusing on a small functional point. Not to mention spending a lot of time, the growth of the front end can be said to be almost zero. For front-end novices, there is no need to dig deep into a small function point before forming a complete knowledge system, unless you have your own ideas or digging into this small piece can bring you great benefits. Otherwise, if you look back in two years, it will be a waste of time.

3. The base business code at work is useless

Many people will complain that the projects they work on have no technical content and they can't learn much. It is not. In the face of work without technical content, what we have to consider is how to make technical content. We can focus on but not limited to:

  • How to communicate with product managers to avoid detours
  • How can the process of a certain module be more reasonable
  • How can project code design be more reasonable and efficient
  • What are the valuable function points of the project, or some knowledge points derived from these function points

We can review and do Code Review for the projects we have done. The next time you encounter a similar project, how can you step on the pit less and how can you complete the development faster. In short, optimize all points that can be optimized, and take "improving efficiency and self-improvement" as the fundamental purpose of building business code.

A shortcut to front-end learning

1. Build a knowledge system

最好是从零搭一个项目模板。如果是 webpack 应该包括 webpack + react/vue + less/sass + babel + eslint/prettier + husky + lint-staged + commitlint
从头实施一遍,这些基本上就能对前端工程化(css 预编译 + js 降级 + 代码规范化 + 构建/打包)了解个大概。

当然你也可以再加入 typeScript、Jest 等其他一些东西。这取决于你自己是否需要。如果你能够自己整一遍,基本上前端开发阶段需要具备的能力就差不多了。

关于部署,稍微看一些 nginx 相关视频、技术博客,自己手动实施一遍就明白了。当然,你也可以把 nginx 装在 docker 上。

做完这些,你再回头看看。是不是感觉对前端理解的比较深了呢?

2. 刷面试题

刷面试题一方面可以应付面试,另一方面能够促使你了解一些框架的底层原理。面试题刷多了,很大几率你是想了解一下某些框架的源码的。

3. 技术博客、公众号等文字媒体

技术博客一方面可以作为自己的技术笔记,另一方面还可以给自己的简历加分。何乐而不为呢?

至于技术博客的内容就更随意了。可以是以前没有接触到的某块业务的解决方案,也可以是新学的技术,还可以是对项目的复盘或者自己工作的一些心得、体会等等。

4. github

前端知识多且杂,有个比较好的记忆方法是 把你遇到的比较重要的知识点集成到一个项目中去。这个项目不一定多实用,但它能容纳你的核心知识点。

这样你就有了一个自己的开源并一直维护的项目。

另外,github 上的资源很丰富,无论是面试题、技术文章还是源码解析,统统都有。什么,你打不开 github?问问身边的朋友有什么好用的翻墙工具。花一点钱就能解决的问题,为什么不呢?

5. 定目标并定期回顾

定目标最好加上时效,避免自己偷懒。每周回顾一次,看自己有没有离目标更近一些。比如:

  1. 一周内搭建一个自己的项目模板
  2. 一个月刷完 100 道前端面试题
  3. 半年吃透 React 源码,并输出几篇相关技术博客
  4. 每周一篇技术博客

This article is published by mdnice multi-platform

Guess you like

Origin blog.csdn.net/ppppppppppsd/article/details/128704359