First of all, I have five years of development experience in the actual development, but I have encountered some phenomena and some things in the development, so I feel compelled to ridicule, to see if everyone has the same doubts. Welcome to discuss!

Get straight to the joke

A rookie who hates iron

First of all, I also want to emphasize that I have been upgraded from small white all the way to fight monsters, but I have encountered a lot of small white that I feel very sad. I always thought that we were front end engineers, not a drawing board,

We should first be a qualified engineer.

When I hire people, I will look at a few points, but it doesn’t need to be very strict, you just need to know something about it.

  • The data structure
  • algorithm
  • Object memory model
  • JavaScript event mechanism
  • Inheritance and encapsulation
  • coupling
  • The HTTP protocol
  • VCS: SVN or Git (naming and shaking Git)
  • Ajax
  • Synchronous and asynchronous understanding

But even some simple questions, many students are confused and can not answer them.

For example, if you have an array [1,2,3,4,4,5,5,6,6,6,7], the length of the array is less than 100, the inside of the array is positive integers, the array is ordered, there are no null values in the array.

Such a simple array to duplicate, nearly half of the students can not answer

For example: What are Ajax and Axios, and how are they related?

This is obviously a puzzle, like the relationship between JavaScript and Java, but there are a lot of front-end can’t answer it.

Many students at this time certainly some people will say, it must be your company to recruit low wages, can recruit these poor skills

This is true, it is true that our wages are a little low (but I honestly say, even in this city, also to do the average development),

But WHAT I want to express is that we can obviously feel that there are too many rookies in the front end of 1-3 years, especially in non-computer related majors. Moreover, without a complete system of training, many people are just superficial and become VUE engineers.

Many Java students mock themselves as Spring engineers, but sadly, many front-end students don’t even realize they are Vue engineers.

A variety of project customization

The phrase is often heard:

In this project, the back-end interfaces are the same as before, but due to the client XXX, we need to change a new set of interfaces

After years of working, I was most afraid of this situation, for a number of possible reasons:

  1. The function originally in PC will be realized on wechat public account (re-developed).
  2. The user thinks the previous interface is too ugly, we need to implement a new interface this time.
  3. XX system before the XX function is very good, can you transplant?Seriously, I come from Java, and I know how much work it takes to migrate a new microservice from Java to the current service cluster

The back-end interface is poorly designed

I purposely used a bad word here, which I’ll explain later.

Example 1:

The front-end needs to load a user profile picture

Normal: When you open the home page and obtain the user information, there is a node in the returned JSON data, which stores the static resource path with the user picture. Load it to the corresponding position.

axios.get("/user/info").then(res= >{
    console.log(res.data.user.logo); 
})
Copy the code

Actual situation:

  1. You need to call interface A to get the user ID/system/info.
  2. You need to get A piece of information based on the user ID returned by interface A/user/info.
  3. You need to get the user’s picture path based on the information/logo.
axios.get("/system/info").then(res= >{
    axios.ge("/user/info").then(res= >{
        axios.get("/logo").then(res= >{
            console.log("Finally get the final image path."); })})})Copy the code

Experienced developers already realize what’s wrong with this

  1. Interface/interface mismatch: An interface’s information should not be requested at every function point, which reduces coupling but also introduces a large number of Ajax requests that affect performance (which involves data sink and single responsibility that the back end seeks).
  2. If the interface call chain is too long and the interaction times are too many, the final time will become too long. In addition, if there is a network error in the middle, the call chain is broken, and the common SPA in the front end will also bring the hidden danger of memory leakage.

Therefore, it is generally appropriate to obtain user information in one interface

I held a meeting to ask everyone what they thought, and it made me sad:

  1. Common Reactions to Java development:Do not modifyThere is no need to change; Reason: The interface has already been written, why to write a new interface, such maintenance will be troublesome.
  2. Front-end response:?? Why is the leader chasing after this small detail? We have a Promise, just write a few callback is enoughI know you're not afraid to get tired orz... But not being aware of the problem is the biggest problem

The above example, can be understood as unreasonable design, the following example is true: not aware of the problem, is the biggest problem.

Example 2:

There is a strange backend interface that is responsible for downloading Excel. In order to save work, Java developers have created such an interface:

@Controller
public class DownloadController {
    // Download interface
    @RequestMapping("/downloadExcel")
    public MultiFile downloadExcel(XXXX){
        returnXXX; }}Copy the code

The parameters received by downloadExcel are not the parameters for downloading files, but the contents of the files.

That is to say, you need to download the content of the file, you must first prepare a JSON, send to the back end, he can receive the JSON data, converted into an Excel download to you…

The problem with this is:

  1. Once the data load is very large, it will be very slow, very slow, and even the client crashes
  2. The data itself is queried from the back end, which consumes a lot of network bandwidth and server memory when it is downloaded to the back end.
  3. A large amount of data is transmitted by the outside world, which can be maliciously attacked (there are many specific attacks, which will not be described here).

Some students may ask, the front is paginated, that you want to download all how to do?

In fact, I was caught to see this interface, the first is because of a BUG reported: the user clicked a download all button (production environment, list data level of nearly one million), directly resulting in interface freeze, and paging is actually the backend directly returned all data, the front end to do client paging.

When I saw the interface design, I ran over to the developer and asked him why he did it. He said, “Our local environment test is fine.” Testing anywhere is good too! All the functions are finished, and there was no problem with the test at that time. It must be that the on-site implementation is not well deployed, so let him restart it

To this day, I have been wondering how this interface was designed, accepted and developed by the front end

The back endRisk of grafting

Risk grafting is a term I coined myself.

Due to our business, we often interconnect with third party systems, that is, call someone else’s interface to synchronize data.

Back-end Java development has been careful with third-party data, using MongoDB for databases, heavily using List

for data structures, and checkUtil for null and optional operations on GetXX(). That deserves a thumbs up!

But the back end does not carry out any data verification, the data are stored in the database, the front end in the query, it becomes a disaster.

  • Data fields are occasionally missing
  • Data types occasionally do not match
  • Data is occasionally empty

In a list

interface returned by an interface, the front end usually sees something like this:

[
{name:"jack",age:10,address:""},
{name:"jack"},
{name:"jack",age:null,address:null},
{name:"jack",age:18,address:["A"."B"]}]Copy the code

Just to give you an example, the number of fields can be 30+ or even 50+,

This kind of data structure, for Vue engineers, is a disaster, at least so far as I can see, any V-for will blow up, every now and then a Null exception will appear during the loop,

Of course, I know there are solutions for all of the above jokes, whether it’s data validation, input validation, or default values.

But: Remember what the title was?Risk of graftingThe loose data structure of the back end leads to the direct entry of dirty data into the library, which directly affects a lot of meaningless work.Or this work can be done on the front end and back end, now have to do the front end

The depth of the front end and uncomprehending requirements

The front end, to say the least, is to draw the interface, there is always someone to criticize:

  • Vscode editor is front-end, not easy at all
  • Low code platform enabling implementation, direct pull, is not simple
  • Front-end frameworks, Vue/ React/Angular, these wheels are not simple either

I quite agree with this point of view, whether it is the front end or the back end, as long as one goes to the mountain, to the end is the peak. But how many people stay at the foot and hillside… Isn’t their appeal and suffering worth mentioning?

A lot of the pain on the front end is that you can be a technologist, but you’ll never be the backbone of a team, always on the outside.

As a full-stack developer, my personal feeling is that once you have mastered the database, you have mastered the core of the whole system. This saying is true at all. In my days as a back-end developer, I have a very thorough understanding of the business, but when I move to the front end, I lose my grasp of the business.