Summary of common problems programmers make in team development, pay attention to!

Hello everyone, I am fishskin, still remember my brother little abba?

Earlier, I exposed this front-end beginner’s first attempt at back-end code: the front-end guy wrote the first backend and crashed!

After this article came out, more people got to know little Abba and thought he was an interesting programming little hot chicken. But little abba is a proud and ambitious child, do not want to have a joke in front of everyone. So, this guy is not convinced, come to me again, want to work with me on a new project.

Well, to develop a new feature, let’s bring abba along. And this time, he’s in charge of the whole thing!

Unexpectedly, little Abba still completed the development quickly, cheerfully submitted the code, dragged me to review.

However, when I looked at the code he had written, I realized that things were not so simple.

Little Abba is so awesome, some novice programmers in the team development of common problems, this product did not avoid a single, all on the thunder.

So I decided to expose him again, and summed up his problems, hoping that everyone should take warning.

💣 team develops minefields

The pattern of small

There are many “dead” values in the code written by abba. For example, the IP address of the same machine is used in several places:

/ / file 1
getConnectByIp("8.8.8.8");

/ / file 2
getLinkByIp("8.8.8.8");

/ / file 3
return {
  ip: "8.8.8.8"
}
Copy the code

When I asked him why he wrote this, his answer was predictable: to save trouble

It’s the same as copying and pasting. It’s nice to paste the same code multiple times, but what if you need to change it later? You want to get rid of all the pasted code one by one?

It’s fine if you write all the code by yourself, and you probably remember all the duplicate code, but what about a team?

Let’s say colleague A writes A piece of code, and both colleague B and colleague C copy his code:

But then colleague A found his code was buggy! So only code A was modified, but code B and code C still had bugs.

After all, people like to copy code, especially in large teams, and you never know how many people have copied your code! There’s a Bug that never dies.

Therefore, from the perspective of scalability and maintainability, try to write less “dead” code and write less duplicate code. You can separate duplicate values into independent variables, constants or configuration files, encapsulate duplicate code into components, and write documentation and comments to guide others to use. General code repeat 3 times, you can consider abstraction, don’t be lazy, or the future worse.

Too much ego

A dependency library named day.js is introduced to calculate the number of days between the specified date and the current date.

As a matter of fact, the project already has a date-handling library, moment.js, which can easily implement the above functions. There is no need to re-introduce a similar date-handling library.

When I asked abba why he wanted to introduce a new library, his answer was predictable: I’m familiar with it!

You might think that there is nothing wrong with introducing duplicate libraries to a project, but for a team project, there are many problems if everyone introduces duplicate libraries because of their own habits:

  1. Dependency conflicts: Colleague A introduces the Log4j logging library and colleague B introduces the Logback logging library, and the project may not run.
  2. Project weight: everyone introduces their own familiar library, the whole project will snowball, and want to split or remove a part, maybe the snowball will break.

To give another exaggerated example, three front-end developers of different technology stacks work together on a project, resulting in a three-way situation in which three frameworks appear on the same project:

You can imagine how difficult it is to maintain a project like this.

Therefore, the architect is still very important in the team, and it is best to set rules for the project in advance: the project will use this framework for me! Use this library for date processing! Log all use that library!

This is a matter of technology selection, considering business adaptability, team member learning costs, etc.

However, be careful to introduce new dependencies into the project, and don’t break new ground just because you disagree! It is best to scan the project’s current dependencies carefully first. If there is one that can meet the needs, isn’t it beautiful to use it directly? Really want to introduce new dependency, also had better discuss with your partner, in case what conflict can not be good ~

impatient

I read the features written by abba and was surprised to find that he had misunderstood the requirements at all!

I asked him to turn a screw, and he built me a car?

/ / expected
luoSi = ningLuosi();
/ / o little bar
car = buildCar();
Copy the code

Don’t even know what to do, can’t wait to directly handwritten code, this is a big no-no, typical efforts do not please.

In the enterprise, as a developer, we often have friendly communication with the product manager. Only when the requirements are thoroughly understood can we design the scheme, and only when the scheme is well designed can we write the code. In the whole process, we must confirm clearly with the demand side repeatedly!

I decided to give Abba one more chance, and this time it took a few days for him to submit the code, and I saw that he really had turned the screw, but…

There was already a wrench in the project for him to screw, and this guy built his own wrench?

function ningLuosi() {
	// Expected: one line of code
  useBanShou();
  // skip 1000 lines of code
  const tool = buildBanShou();
  xxxxxxx
}
Copy the code

This is also a common problem for novices. They write handwritten code without looking at the project documentation. As a result, there are already wheels and simple writing methods are not needed.

Blind confidence

I feel small abba has a line of code to write a problem, so the local run, indeed found a Bug, the page directly crashed!

I called the kid over and said, “Have you finished writing the code test yet?” Do you think it’s functional?

He a face confidently answer: did not measure, this function is not add delete change check, can have what problem?

So I showed him the Bug, and he blushed and was speechless.

It’s tempting to think that experienced programmers write faster, but in fact, the more experienced they are, the more careful they are and the more they test their code after they write it, rather than blindly trusting their experience and intuition. The test should not be just a quick check of your own, but should cover all normal, especially abnormal conditions. After all, users are not obedient, and you can’t imagine what these guys can do in your system!

Manufacturing excrement mountain

Small abba’s code is very clean and refreshing, a file thousands of lines of code, the same annotations are not, I called him over to tell me about their code, he actually hesitating to say!

One line of comment is not enough, the code is also written crooked, does not follow the code specification, if everyone is a small abba, huge mountain of shit is just around the corner.

public static void main( String[] args) {
 System.out
    .println("i" 
+ "am" 
          + "shuai");
     }
Copy the code

mischiefs

Read through the small abba code, in addition to the above problems, I also found a lot of small mistakes.

So I asked him: After you write code, how many times do you read it through yourself?

Result this cargo unexpectedly shy extremely, stammering ground say: have no… No…

Oh, my gosh! How many other friends are like Little Abba, who wrote their code like a cloud and never looked at it again?

The code you have written must be read several times, as well as the exam paper, check again can find a lot of problems. And when you’re teaching yourself programming, no one’s forcing you to turn in your paper, right? It takes some time to develop good habits.

I now read the code at least three times after I write it: once after writing a sub-feature, once before testing it, and once before committing it. Even so, there have been bugs.

Besides, you don’t even want to see the code you’ve written, and you want others to look at your bad code when they review it, find problems and then call you back to fix it. Isn’t that a waste of other people’s time? Over time, who wants to see your code? Who wants to work with you?

In addition, even if someone else reviews your code for you, some problems can be difficult to spot, and if something goes wrong online, you’ll be the one to blame. No one can save your bugs except you.

perfunctory

Finally, this is the current situation of most students writing code that I mentioned in my previous special article: they are only satisfied with the running code and the function, and do not pay attention to details and do not optimize.

Like this code from Little Abba:

for(int i = 0; i < maxNum; i++) {
  doSomething1();
}
for(int i = 0; i < maxNum; i++) {
  doSomething2();
}
Copy the code

It is actually possible to merge two of the same loops:

for(int i = 0; i < maxNum; i++) {
  doSomething1();
  doSomething2();
}
Copy the code

Many students have been complaining that they add, delete, change and check all day, the project is not competitive. But the truth is, as you work on every project, there’s a lot of room for improvement. Dig deep, not through it.

Take a look at my programming habits: MY little stubbornness when writing code.

So, have you ever stepped on one of these mines? Team development can never be as random as writing code, I hope you keep these problems in mind, do a good programmer, reliable teammates.

So the question is, do you want to take Abba on a project? 🐶

Finally, I will send you the learning resources to help me get the offer from the big factory

Gone! Leave 6 terabytes of resources!

How DID I learn programming by myself from scratch and get the offer from Tencent, Byte and other big factories? You can read this article and no longer feel confused!

I learn computer four years, mutual encouragement!

Original is not easy, if you think the article is good, I hope to support ❤️