当前位置:网站首页>Programmer's 4 ability levels and 8 work bad habits, certainly have you

Programmer's 4 ability levels and 8 work bad habits, certainly have you

2021-05-04 15:21:08 liangchen001

Preface

In my more than ten years of front-line development career , I'm familiar with programmers who write code , What is a programmer's ability level , Just look at how he writes the code , in my opinion , Programmers can basically be divided into 4 It's an ability level : Linear level 、 Logic level 、 Architecture level and engineering level .

Programmers often have some bad habits in the process of writing code , Including myself, I stumbled all the way , Yes 8 A bad habit is very common , Today, let's talk about , Let's see if you have this habit !

One 、 The programmer's 4 It's an ability level

1. Linear level

The thinking of linear programmers is simple , Writing programs is like building a house , One brick at a time , But he didn't know what the back would look like , It's probably bigger and bigger , The following code organization 、 Management and so on will be more and more chaotic , In the end, it is troublesome to modify and maintain many programs .
 Insert picture description here

2. Logic level

For logic level programmers , We have mastered the theoretical basis of some algorithms , And have a clear grasp of the logic of the business world , Can write some good modules and functions , And the logic is tight ,bug Less of such a state .

3. Architecture level

For architecture level programmers , Because in addition to the understanding and grasp of the program language itself , We should also have a clear grasp and understanding of the business logic to be solved in the real world .

Only in this way can the software be structured and layered , And then guide the rest of the team to achieve the same goal .
 Insert picture description here

4. Engineering level

For engineering programmers , Because the software development itself is not just the development itself , There are many other elements of project management in it .

For example, the plan just mentioned 、 organization 、 Management and control , If there are some guidelines and principles for project management , Then for a software engineering process management, there will be a " The hills are small " The state of .

Two 、 It's common for programmers to 8 A bad habit

According to previous work experience , I think these bad habits of programmers are the biggest obstacle to the progress of programmers .

1. Self -

Well, first of all, the programmer is a brain worker , That's a very important characteristic of him , It's very self .

Most of the time, when writing code , Basically, I'm not willing to listen to other people's opinions and suggestions .
 Insert picture description here

2. closed

Some programmers are very closed , That is to say, it is not open enough .

If you interact with other programs with an open and communicative attitude , So the mutual promotion effect will be very obvious .

3. inertia

Some experienced programmers have some inertia in their work , Often say " How I used to do this "、“ I used to do this , I just don't think you're doing it right now ”…
In fact, this inertia , It's also a big problem that hinders communication .
 Insert picture description here

4. Communication barriers

This is a more obvious kind of bad habit , Because programmers face computers all day 、 Just interact with machines , So when you talk to other product managers and other testers and so on, some of these people , There will be obvious communication barriers .

5. Have one's view of the important overshadowed by the trivial

This is the biggest problem , That is to say, programmers are often blinded by one leaf , Just see the work in front of you .

For example, when there are some team development tasks , It's all about yourself . So for some requests from others , In particular, some interactive and complex network interfaces are often subconsciously rejected when they are developed .

6. The workload estimate is optimistic

And the most important question , That is to say, the workload estimation is often missed .

For example, when you get a demand , good , I can finish the result in a week , When it's really realized , Find that it takes two to three weeks or more to accomplish this task .
 Insert picture description here

7. Refuse to change

For changes in requirements , The programmer's mentality is very rebellious .

When I was writing something , Found that the requirements have changed , There's an obstacle mentality that refuses to change .

But the premise of rejecting change should be objective first 、 Reasonable analysis and judgment , Finally, give the answer . In fact, it should carefully weigh whether this change will affect my current software system and architecture ? How much is the increase in my workload ? It takes a good estimate to decide whether to make this change .
 Insert picture description here

8. Refactoring denied

The last and most important question , That is to say, many times we refuse to refactor , Because this refactoring is sometimes difficult to choose from .

For example, I often think , Oh, this software architecture I originally wrote , In the whole implementation process that follows , It's going to get bigger and bigger , And informatics 、 When new demands come in , It's hard for me to maintain such a good architecture . Well, it's often tangled , Do I restructure or do I follow the original path ?

Whether or not to reconstruct is actually based on my reality . For example, I wrote an Android game a few months ago , I'm always in this state of mind , I'm also struggling with whether to reconstruct or not ? Later, when I clenched my teeth and closed my eyes, I reconstructed .

In the case of refactoring , It may take some time in the early stage , But I can guarantee the realization of the goal of this software in the later stage , And have a clear 、 Complete architecture and Architecture , And it will reach such a state that is easy to maintain later .
 Insert picture description here

The bad work habits mentioned above , It's the nature of most programmers , We need to improve slowly in our work , First of all, we need to realize that this is a bad habit , Consciously and constantly correct yourself , Use a good attitude to avoid these problems .

 

 

 Insert picture description here

版权声明
本文为[liangchen001]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/05/20210504151853569E.html

随机推荐