Chapter 2: programmer degree

The degree I want to talk about here is not the programmer's degree of anger, but the degree to complete each task that you need during project development.

Many concepts have the highest goal, but not necessarily the highest goal is the most appropriate. The most practical goal is to comprehensively consider the actual situation, which may include resources, time, cost, and efficiency. The world is multidimensional and full of contradictions. Programmers should learn to find a balance between various contradictions.

Encoding level

I think many companies will have their own coding specifications, which require that your file name, Function Definition, variable name, and code annotation be written in the prescribed format during the coding process. I wrote the coding standards of our company, but I cannot do it all myself.

As a company's rules and regulations, we may need a comprehensive and comprehensive consideration. As my personal requirements and understanding of programmer coding, Each programmer must have a basic coding standard in his mind, that is, the code you write must have your own style. In simple terms, there are two main points. One is self-written code, which can be understood by yourself in the future; the other is self-written code, which must have its own style. Many programmers can't even understand the code after a period of time or even a few days. First, the content cannot be understood, because there is no proper comment, second, you cannot figure out whether the code is self-written because the Code does not have its own style.

Programmers are individual groups, so I do not force everyone to be consistent, but everyone must have their own degree, which others can understand.

Degree of module Encapsulation

High Cohesion and low coupling are ideal targets of module encapsulation. But it is not necessarily the best solution. It is like the paradigm in database design. If the database is designed to the highest paradigm in practical applications, this database may not be applicable because the query efficiency may be greatly reduced. Adding redundancy appropriately often balances space and time. The encapsulation of modules is also the case. Do not blindly pursue High Cohesion and low coupling, leading to excessive encapsulation. This will increase the development time and cost. In fact, there is no need to overpackage a lot of content, and there is no possibility of expansion in the future.

I have a colleague who enjoys a good C ++ level and enjoys some module encapsulation. I especially like to use some open-source things and may feel a sense of accomplishment. Once, he was asked to write a data file processing module. The name of this data file has a certain format and meaning, such as including time information and data item identification information. This part of the module is relatively independent and involves a small amount of data files from the official data service. The probability of file name rules changing is very low. In this case, a configuration file can be written at most, so that the file name is adaptive and cannot be written to death. As a result, he directly introduced a regular expression, wrote hundreds of lines of code, and introduced a bunch of dynamic libraries and files. Worst of all, after leaving, he found that the regular expression he wrote was still incorrect when judging the names of some data files. It is difficult for others to take over because he introduced something that is not familiar to others.

Degree of Functional Design

In object-oriented design, we also need to consider the issue of degree, not the finer the granularity of the design, the better. Consider the requirements of each function and the possibility of future extension of the function. For functions that may be extended or have a large impact, you must retain a certain amount of extended space to maintain a certain degree of flexibility. When a user adds or changes a function, the development cost can be reduced to prevent the previous tasks from being abandoned. In this case, there is basically no possibility of expansion, and the impact is very small and relatively independent, it is also possible to ignore future extensions. Even if there is an emergency, the re-development cost will also be acceptable.

In short, it is necessary to master between time, progress, and cost. Only in this way can the user's functions be completed on time and the design can save costs.

There are still many levels that programmers need to master, such as testing and communication. I will not go into detail here. From the degree discussed above, you can also think about how to grasp this degree in other aspects. The world is multi-dimensional, and each dimension has its own ultimate. Maybe in one aspect, we will pursue this extreme, such as the aerospace algorithm. You cannot consider the moderate strategy. However, for projects developed by many programmers, it is often not necessary to pursue the ultimate in a certain dimension, but to maintain a balance between multiple dimensions. The ability to grasp this balance point can also represent a programmer's level.