What is the difference between a good programmer and a general programmer ?, What is the difference between programmers and programmers?
Among the programmers I have seen in ordinary times, I think they can be divided into five categories based on their encoding capabilities:
1. Beibei type
The Beibei contestants are the legendary "Code copywriters" who have little idea about implementing functions. What they do is to copy fragments from the code written by the Internet or other team members, put it in the project. If the expected result is displayed in the running project, the task is completed.
Such people only change the code, but do not write the code. Most of them are not interested in programming, but they just want to make a living.
2. Newbie
When the product has functional requirements, due to limited experience, programmers do not fully know how to implement this function. They need to solve the problem by learning and searching for materials.
In this case, the programmer's main goal in the coding process is to "complete the function", so it is difficult to think about boundary conditions, performance, readability, scalability, coding specifications, and other issues, therefore, there may be many code bugs and the stability is not high. It often takes one month to develop, but it takes several months to change the bug.
3. Learning Type
This type of programmer has a better understanding of the language in the field, and can have clear implementation ideas for general functions. When providing requirements, you can use your own ideas, in addition, boundary conditions and performance issues are considered to some extent. But that's all. They have little consideration for readability and scalability, and have no project-level concerns. They mainly want to practice or learn by implementing code.
The biggest performance of such programmers is that they like to "Create Code". Even if there is a ready-made implementation, they also want to implement one set by themselves to achieve the goal of "learning. They do not like to reuse others' code. When they see that others in the project implement similar functions, they will use the excuse of "different requirements" to implement a new set of functions on their own. Such people are generally interested in technology and hope to learn through projects.
From the perspective of projects, the biggest trouble with this approach is that the development cycle may be long (compared to the direct use of ready-made implementations), and it will expand the project code and affect future maintenance. However, this type of programmers may become the norm of tomorrow if they are interested.
4. Implementation type
This type of programmers generally have rich experience. Because they write too much, they no longer pursue "creating code" for learning, at the same time, I am familiar with many third-party frameworks or tools that may be involved in the field. When I receive the product requirements, I am very familiar with the function implementation solution, so they can quickly implement the requirements, in addition, the boundary and performance are considered to a certain extent. Because of its ability to quickly implement the demand function, it is often evaluated by the Team as "awesome ". However, they generally only stay at the "complete function" level, with less consideration for code readability, scalability, and coding specifications, there is little overall understanding of the project (such as controlling project expansion, convenient deployment, and other architecture-level things ).
The biggest performance of such programmers is that they like "Development Projects" but do not like "maintenance projects ". The biggest problem with the code they produce is that it is difficult to maintain the code, and may be confused when I look back at my code in the last few months. Therefore, even the code you write is still unwilling to maintain, and it will suffer later.
Because of the lack of interface design, when the demand changes, it is found that there are too many things to be changed in the code, and then complained about the changes in the demand, but rarely think of it as a code problem. After a long period of change and maintenance, such a project will eventually become difficult to maintain (usually because the response time of the demand change is getting longer and longer) or even unable to maintain, and eventually it will be half-dead, or be pushed back.
5. Architecture
Such programmers are more experienced than implementation programmers, and are familiar with related frameworks and tools. They no longer pursue "complete functions", "stability", and "performance, A better code and a more reasonable architecture are the goals.
This type of programmer code design is mostly based on a detailed understanding of the needs and a prediction of demand changes-good scalability; Code details are also considered as much boundary, performance-stable and efficient; code naming and comments are all right-the readability is high; at the same time, they will constantly refactor and subtract the Code during the development process-to ensure the sustainable development of the project; and so on;
However, due to a large number of considerations, from the perspective of the "Implementation function" stage alone, the completion speed may not be faster than the "Implementation type. Only in the middle and late stages of the project will the advantages be gradually reflected
I have never seen any better programmers!