This problem should be relatively easy to encounter on the one to three year front end:

Now more and more feel writing business code boring, feeling is a porter. The technology stack is mainly vue + elementUI/React. Front-end work has been going on for over a year and a half. I suddenly wanted to learn front-end basics in March this year. I learned about you on Zhihu and applied for your class. Although the thief 6, who writes business code with a framework, has been recognized by others, in fact, I know that I only know how to write business code, but do not know the technical principle. It’s been a bit of a backlash the last few months, so I just want to learn some front-end basics. The bad thing is that the company 996 now gives me less free time. Recently, the company’s affairs are just handled as it is. I watch your videos and write some blogs in my spare time, which I think is quite good. I will stay in Shanghai for the next few years, and my goal in the future is technical management. Now I find the collision between business and learning. I am in conflict with business and want to learn more about front-end basic things. Should I focus on business or technology in my daily work?

Indeed, you’ve gone from being a novice to a “pro” who can handle the company’s work schedule.

I just feel like I’m repeating myself day after day.

I’ve been there, too. Let me tell you what I did about it.

There is no pure business code

Dividing code into “business code” and “technical code” is a simple dichotomy. But that may not be the case. A third type of code in my experience is “business technical code.”

In layman’s terms, this code is the wheel built for the company’s business.

For example, if you use jQuery all you need to do is filter tables, pagination, rotation, form validation, etc. Doesn’t this kind of work look boring?

For this kind of work, I expect a front-end growth path to look something like this:

  1. The first class is dealing with work. You do this by searching, looking up Stackoverflow, copying and pasting, etc. The code looks a bit spaghetti, but it works.
  2. The second stage is abstract classification. At this stage, you find that the requirements the company gives you are regular, there are only a few patterns for form filtering, there are only a few rules for form validation, so you write a summary of the article, or you fix the code into a template, so that the company comes back with the same requirements, you can do it very quickly.
  3. The third stage is to build the wheel. After phase 2 code has been validated by business requirements and you are confident of its quality, you can split the code into business wheels and share those wheels with your front-end and back-end colleagues so that their requirements can be completed quickly and well.
  4. The fourth stage is optimization. You need to provide documentation for these wheels, test cases, and if you have a large company, a “roll-out plan.”

That’s a great path to follow, because that’s the path I set for myself at Ali, and that’s how I’ve followed it.

You may not have the concept of the third stage of the “business wheel,” so let me give you an example.

Before I joined the team, they did paging through a number of steps, including

  1. Copy HTML structure
  2. JS initialization
  3. The back-end interface is negotiated
  4. CSS adjustment

When I make a wheel, it looks like this:

<div data-role="pager" data-total-page="10" data-page="3" 
     data-auto-page data-theme="taobao"></div>
Copy the code

The user only needs to provide the total number of pages, the current number of pages, and the name of the subject. The parameters of the backend interface have been unified into a URL plus page=? No further negotiation is required, the user clicks on a number in the pager and gets two results:

  • If there is a data-auto-page field, it automatically changes the current page? Page = XXX parameters
  • If there is no data-Auto-Page field, the ‘Pagechange’ event is triggered. This is a ‘business wheel’, a wheel tailored to the business of the company.

In doing so, you need to summarize requirements, analyze user (developer) habits, and refer to the great wheels on GitHub.

I made many, many similar wheels and shared them with all my colleagues. This can improve skills, and a sense of achievement, why not.

Refuse to work overtime regularly

If you are 996 years old, and do not listen to dissuasion, no repentance, I think you can

  1. Increase your productivity by using the business wheels above so you have some extra time
  2. Use the extra time to learn new technologies on the market
  3. Send in your resume and find a team that’s not 996

I haven’t met 996, but I have met teams of weeks and weeks.

I would always recommend leaving if the company makes it a norm, but I don’t recommend leaving when you suck, I recommend leaving when you do a good job.

One is to tell people I didn’t leave because I couldn’t.

Second, give yourself a satisfactory answer sheet, so that you will be more confident.

conclusion

In short, don’t put yourself in a vicious circle (overtime — bad code — more overtime — worse code), but in a virtuous circle (overtime — more productivity — less overtime — more productivity).

Some people say that I don’t have time to learn how to build the business wheel.

I said: How can you change jobs without study time? At most, a similar company.

I hope it helps.