How does a front-end that only writes back-end admin have to improve itself?

I have been writing backend administration for five years. Every time before the interview will have a headache, because the page written in addition to the form is a form. I've complained and agonized and regretted it, but standing at the present point in time and looking back, I realize that there are a lot of things that could have been done better, hence this article.

This article first appeared on/post/7360528073631318027

Writing Elegant Code

An interview question

About two years ago, when I interviewed with Mission, the interviewer asked me to write a code question on time unit conversion. I forget the exact topic.

I haven't done the original topic, but the business code code I wrote has a similar unit conversion in it, where the backend returns a number in units ofkbAnd I'm going to show intoKB，MB and other forms. Probably write a tool function (I forget exactly how, but the function is a bit more complex than that):

function formatSizeUnits(kb) {
    let units = ['KB', 'MB', 'GB', 'TB', 'PB'];
    let unitIndex = 0;

    while (kb >= 1024 && unitIndex <  - 1) {
        kb /= 1024;
        unitIndex++;
    }

    return `${(2)} ${units[unitIndex]}`;
}

And before that, is a back-end students to write the code (that said, the background management system front-end manpower is not enough back-end to help write seems to be a routine operation, the back-end always think that writing the front-end is simple, and I can only say that you guys that the code is written, it is difficult to say ......), as follows:

function formatSizeUnits(kb) {
    var result = '';

    if (kb < 1024) {
        result = kb + ' KB';
    } else if (kb < 1024 * 1024) {
        result = (kb / 1024).toFixed(2) + ' MB';
    } else if (kb < 1024 * 1024 * 1024) {
        result = (kb / 1024 / 1024).toFixed(2) + ' GB';
    } else {
        result = (kb / 1024 / 1024 / 1024).toFixed(2) + ' TB';
    }

    return result;
}

Although the function is the same, but I wrote in the interview when I wrote the above code got the interviewer's praise, and therefore very smooth through the interview. And if I wrote the following look, I guess it will not have this effect.

How to improve code quality

If you want to improve the code quality, the most ideal is to rely on code review, but in fact this thing does not exist in most companies. Secondly, you can only look at the code written by the big guys, but first of all, the backend management is not very difficult and there are few big guys, and secondly, there are often only one or two people in charge of a backend management system.

Luckily, there are now various AI tools that make it very easy to optimize your code.

Same question as above. Check out the answer from GPT.

// Q: Write a utility function that converts the units of a file size, plus comments
// Answer: Here is a JavaScript utility function that accepts the file size, the initial unit, the target unit, and the number of decimal places, and then returns the file size in the target unit.

/**
 * Converts the file size from one unit to another.
 *
 * @param {number} size The file size.
 * @param {string} fromUnit Initial unit ('B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB').
 * @param {string} toUnit Target unit ('B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB').
 * @param {number} [decimalPoint=2] The number of decimal places to retain for the result, defaults to 2.
 * @return {string} The size of the converted file with units.
 */
function convertFileSize(size, fromUnit, toUnit, decimalPoint = 2) {
  // Define the conversion between units and bytes
  const units = ['B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB']; // Get the initial and target units.
  // Get the indexes of the initial and target units
  const fromIndex = (fromUnit).
  const toIndex = (toUnit);

  // Throw an error if the unit is not in the list
  if (fromIndex === -1 || toIndex === -1) {
    throw new Error('Invalid units'); }
  }

  // Calculate the conversion factor between the initial units and the target units.
  const exponent = toIndex - fromIndex; // Calculate the conversion factor between initial and target units.
  // Calculate the result size
  const resultSize = size / (1024, exponent); // Calculate the result size.

  // Return the formatted result
  return parseFloat((decimalPoint)) + ' ' + toUnit; }
}

// The example uses
(convertFileSize(1, 'GB', 'MB')); // output: 1024.00 MB
(convertFileSize(1, 'MB', 'KB')); // Output: 1024.00 KB
(convertFileSize(1, 'KB', 'B')); // Output: 1024.00 B
(convertFileSize(1, 'MB', 'GB', 5)); // Output: 0.00098 GB

What else can I say, all I can say is NB! (Upon tips from the comment section, this code may be problematic, and it is recommended that when using AI tools, the focus is on borrowing ideas, and caution is needed when using the code directly~)

Every time I write a large piece of logic, I'm now in the habit of taking it to AI to see if there's a better way to implement it, or what design patterns to use, and AI is a very low-cost and efficient tool for improving the quality of code.

Learning to encapsulate

A feature is used several times, why not package it as a component? A component is used in several projects, why not write a separate npm package? Why don't you write a separate npm package for a component that is used in several projects? Why don't you write a separate npm package for a component that is used in several projects?

You say, there's no time, there's no need, it's faster to copy and paste instead.

Then you're completely missing the point. Doing so isn't necessarily to get the job done faster, but it can give you more to talk about during your year-end debriefing (you're not bragging about writing a scaffolding even if you've written a hundred forms forms), and if you don't know how to write it you can ask the AI.

And when you actually start packaging components and start writing tool libraries, you realize that you really need to think more than before.

Focus on business

Does it matter for front-end business?

Compared to the back-end, the front-end generally doesn't pay much attention to the business. Even if something goes wrong most of the problems are on the back end.

But in my experience of job hunting, businessVery important!

If you're doing very technical work, like if you're doing low-code, you can talk about the technical difficulties for an hour in an interview. But you're just a crappy writing backend admin, you have nothing to say. This is when understanding the business becomes your highlight.

an interview

Or take the real interview scene as an example, when my ex-colleagues pushed me bytes, but also I interviewed N times in the dream factory, just that group to do business and I stayed before the group to do exactly the same.

• Coworker: "Doing the same thing as we did before, you can just go through the motions, I've complimented you in front of the front-end team leader!"
• Me: "Okay!"

Wait for the interview:

• Front end ld: "Do you know xxx? (business term)"
• Me: "I ......"
• Front end ld: "What about xxxx? (business term)"
• Me: "No ......"
• Front end ld: "What about xxxxxx? (business term)"
• Me: "Build ......"

Then I hung up ..................

How to understand the business

1. Every time you take a request, understand the context of the request and take the initiative to understand it

   We write a form briefly and simply to show the data, but what does the data in the form mean? For example, I've written a kafka management platform before, which has tabular forms that involve whatcluster controller topic broker partition...... I really don't understand it at all, and regret that I didn't have the patience to find out for several years.

2. Every time you do a requirement, you need to understand the results

   In some cases, the team managing the backend may not have a PM at all, so you also need to understand with the business side, how many people use this feature after it's been done, and has it become more efficient? What is the data like?

3. Understand the requirements and take the initiative to optimize

   The product is going to show a thousand pieces of data, you have to think about whether you want to paginate or not, whether it will be stuck if you don't paginate, whether you want to go on a virtual table or not?

   The product is going to be a draggable form, and you have to think about whether or not it needs to be dragged and whether or not it needs to be configured.

   In fact, very often, the product's thinking may be limited to the implementation of competing products, while the front-end can give TA more options. When communicating with the product, you are not only communicating the implementation of the page, but also understand the business better.

Follow Source

When it comes to source code, Vue, React, these are basically a must-ask every time, and there are too many summaries from the big boys I won't go into.

Other than that, I think you should be asked in every interview, what's the highlight of the project you wrote, what's the difficult project, what would you say? Oh, it's all forms, all implemented in Element UI, nothing difficult. Then I guess that's the end of your interview.

So what does that say, that's all there is to backend management, huh?

If you use Element UI you can say what custom Element UI form components have been written, what is the principle of Element UI form source code, how to communicate? If you use Axios, you can tell us how Axios works and how its interceptor is implemented. If you use the editor diff, do you know what the diff algorithm is? With ECharts, do you know what it draws on? With husky, how does husky work? With Vite, why is it fast? How is it packaged? Have you ever written a plug-in?

Some of you may think I'm off base.In fact each of the above questions is something I've actually been asked in interviewsThe first thing you need to do is to understand the principles of each tool and each library. Of course, if all to understand, certainly unrealistic, each person's energy is limited, it is impossible to each use of each tool each library to understand the principle, but as long as there are one or two you have gone to understand.Then you can guide the interviewer to ask in the interview, and learn to show the points that you are good at。

As for how to read the source code? I didn't know before, but now ...... Why not ask the amazing ChatGPT?

Tell us how interceptors are implemented in the Axios source code?

Axios' interceptor implementation is based on the core principle of Axios that an Axios instance is an object containing a stack of request and response interceptors. When a request is made or a response is received, Axios traverses these interceptors and executes the request interceptors in the order they are added and the response interceptors in the reverse order.

In the Axios source code, interceptors are managed through an AxiosInterceptorManager instance, which maintains an array of interceptors. Each interceptor is an array containingfulfilled respond in singingrejected object of the function. These two functions correspond to the cases of successful interceptor processing and interceptor processing errors, respectively.

The following is a simplified version of the Axios interceptor manager, showing the core implementation idea:

class InterceptorManager {
  constructor() {
     = []; // Array for storing interceptors
  }

  use(fulfilled, rejected) {
    ({
      fulfilled: fulfilled,
      rejected: rejected
    });
    return - 1; // Returns the interceptor'sID
  }

  eject(id) {
    if ([id]) {
      [id] = null; // Remove Interceptor
    }
  }

  forEach(fn) {
    ((h) => {
      if (h !== null) {
        fn(h);
      }
    });
  }
}

When sending a request or receiving a response, Axios creates a promise chain and passes it through theforEach method in the interceptor to thefulfilled respond in singingrejected function is added to this chain. In this way, each interceptor can process the request or response and then pass the result to the next interceptor in the chain, or end the execution of the chain if something goes wrong.

(function unshiftRequestInterceptors(interceptor) {
  (, );
});

(function pushResponseInterceptors(interceptor) {
  (, );
});

In the full implementation of Axios, this interceptor mechanism is integrated into Axios' request sending and response handling flow. In this way, Axios can use an interceptor before sending a request and after receiving a response, but before a user-defined.then maybe.catch Insert custom logic before execution.

Please note that the code provided here is intended to illustrate the implementation of the Axios interceptor and is not a complete copy of the Axios source code. If you are interested in the details of Axios' interceptor implementation, we recommend checking out the source code in Axios' official GitHub repository.

Front-end infrastructure

When we work for a long time interview will inevitably encounter these problems, front-end engineering, front-end monitoring, workflow, deployment, performance and so on. In fact, we work in the vast majority of the time in the writing code, for these not all people have access to, but these and do not have anything to do with the business, is that we promote their own very good idea.

Technical Selection

Do you choose Vue or React for your tech stack, Vue2 or Vue3 for Vue, ElementUI or Ant Design for your component libraries, have you ever used a micro-front-end, Vite or Webpack for packaging? Vite or Webpack? How do you implement so many forms, and is there any expression configuration solution, such as Formily?

For a rookie like me, someone like me who only writes simple form tables, all this ...... doesn't matter ......

However, in order to prepare for the interview we need to understand the disadvantages of the unselected tech stack and the advantages of the selected tech stack (a bit of putting the cart before the horse... but the usual thing to do)

Vue You can say that it is simple, efficient and lightweight, and the interview will surely ask you why, and you will start talking about Vue's responsive system, dependency collection etc.

React you can say JSX, Hooks is very flexible, then you must consider how to compile JSX, Hooks implementation and so on.

Overall, for technology selection, which relies on our understanding of all the available options, making a choice may be easy, giving sound reasons still takes some effort.

development specification

This is an area that I wasn't asked much about during the interview, and we can configure it when we create the project under theESlint，stylelint， prettier， commitlint etc.

Front-end monitoring

After so many years of doing front-end, front-end monitoring I am ...... not doing it at all.

Front-end monitoring, simply put, is that we record some information in the front-end program and report it, usually error information, to facilitate us to find problems and solve them in time. In addition, there will also be performance monitoring, user behavior monitoring (buried points) and so on. I've heard some teams share front-end monitoring before, in order to clarify the responsibility for problems (and to facilitate dumping).

For implementation solutions, whether using third-party libraries or implementing your own, it is important to understand the principles of implementation.

For error monitoring, you can learn about Sentry, which works simply by using the cap (a poem)('unhandledrejection', ...) to catch synchronous and asynchronous errors, respectively, and then pass the error message and thesourceMap to locate the source code.

For performance monitoring, we can use the、PerformanceObserver and other APIs to collect page performance-related metrics, in addition to focusing on the response time of the interface.

Finally, once the information has been collected, it is important to consider options for reporting the data, such as using the Is it batch reporting, real-time reporting, or delayed reporting? The format of the reported data and so on.

CI/CD

Continuous Integration (Continuous Integration, CI) and Continuous Deployment (Continuous Deployment, CD), mainly including version control, code merge, build, single test, deployment and a series of front-end workflow.

Workflows for scenarios are Jenkins, Gitlab CI, etc. We can configure to automatically package and deploy when merging code, automatically build and release packages when committing code, etc.

I don't know much about this piece, but it feels like these tool level things are less about the principles and basically about the use. You still need to try it yourself to know the details. For example, in the Gitlab CI, thePipeline 、 Stage cap (a poem)Job What are they, how to configure them, how to configure different workflows in different environments, etc.?

Learn about technology developments

This one probably still relies more on information gathering skills, and while I personally find it annoying, it seems like a lot of leadership level interviews are very willing to ask.

For example, low code, which has been very popular in recent years, is asked by many interviewers. If you've used it, you'll be asked for details, and if you haven't used it, you'll be asked what your design ideas are.

There's also the recent two-year explosion of AI, or maybe the newest feature of Vue React, WebAssembly, and some new packaging tool, Vite Bun, or something, and Hongmeng Development ......

It's impossible to learn every new technology, but it's a good idea to find out more about it.

summarize

Having written all this, one might ask what you would do if you could go back in time.

Ah well, all I can say is that it's one thing to say it and another to do it, and the truth is that I don't really want to go back in time and roll it all over again, it's okay to dish it out, just be happy, it all works out for the best.