Ten commandments of programming for programmers_PHP tutorial

1.- DRY: Don't repeat yourself.
DRY is the simplest rule and the easiest to understand. But it may also be the most difficult to apply (because to do this, we need to make considerable efforts in generic design, which is not an easy task). It means that when we find some similar code in two or more places, we need to abstract their commonalities to form a unique new method, and change the code in the existing places to make them use some Call this new method with the appropriate parameters.

DRY This rule may be the most common rule in programming. So far, no programmer should have any objection to this rule. However, we can find that some programs forget this rule when writing unit tests: Let us imagine that when you change several interfaces of a class, if you do not use DRY, then those who pass a call The unit test procedures of the interface of the system class need to be changed manually. For example: If the many test cases of your unit test do not use a standard common method of constructing a class, but each test case constructs an instance of the class by itself, then when the constructor of the class is changed, you need to modify it. How many test cases are there? This is the consequences of not using the DRY rule.

2.- Short methods.
At least, we have the following three good reasons for programmers to write short methods.

The code will become easier to read.
Code will become easier to reuse (short methods can reduce the degree of coupling between codes)
Code will become easier to test.
3.- Good naming conventions
Using good unified naming conventions can make your program easier to read and maintain when naming a class, a function, or a variable Once we reach the point where we can "read the text literally", we can have fewer documents and less communication. The article "Some things about naming design in programming" can give you some tips.

4.- Give each class the correct responsibility
One class, one responsibility. For such rules, you can refer to the SOLID rules of the class. But what we emphasize here is not a single responsibility, but a correct responsibility. If you have a class called Customer, we should not let this class have a sales method. We can only let this class have methods that are most directly related to Customer.

5.- Organize the code
There are two levels of organizing the code.

Physical layer organization: No matter what kind of directory, package or namespace structure you use, you need to organize your classes in a standard way, which can be convenient Find. This is a physical code organization.
Logical layer organization: The so-called logical layer mainly means that if we connect and organize two classes or methods with different functions through a certain specification. The main concern here is the interface between program modules. This is the architecture of program modules that we often see.
6.- Create a large number of unit tests
Unit testing is the place closest to BUG, ​​and it is also the place with the lowest cost to modify BUG. It is also the place that determines the success or failure of the quality of the entire software. Therefore, whenever possible, you should write more and better unit test cases, so that when you make corresponding code changes in the future, you can easily know whether your code changes affect other units.

7.- Refactor your code frequently
Software development is a continuous process of discovery so that your code can keep up with the latest changes in actual requirements. Therefore, we need to frequently refactor our code to keep up with such changes. Of course, refactoring is risky, not all refactorings are successful, and not we can refactor the code at any time. The following are two prerequisites for refactoring your code to avoid introducing more bugs or making already bad code worse.

There are tons of unit tests to test. As mentioned before, refactoring requires a large number of unit tests for assurance and testing.
Don’t make every refactoring big, use bits and pieces of small refactorings instead of big refactorings. There are too many times when we start planning to refactor 2000 lines of code, and after 3 hours, we give up the plan and revert the code to the original version. Therefore, what we recommend is that refactoring is best accumulated from bit by bit.
8.- Program comments are evil
This one must be full of controversy. Most programmers think that program comments are very good. Yes, that’s right, program comments are in In theory it's very good. However, in actual programming, the comments written by programmers are very poor (the programmer's expression ability is very problematic), which has led to program comments becoming the embodiment of all evil, and also caused us to have trouble reading the program. Most of the time, we don't read the comments but read the code directly.So, here, we are not encouraging not to write comments, but - if your comments are not good enough, then you might as well spend more important time refactoring your code to make your code More readable, clearer, and better than comments.

9.- Focus on the interface, not the implementation
This is the most classic rule. The interface focuses on "What" is the abstraction, and the implementation focuses on "How" is the details. The interface is equivalent to a contract, and the actual details are equivalent to the operation and implementation of this contract. Operations can be very flexible, but contracts need to be relatively stable and unchanging. If an interface is not designed well and requires frequent changes, then we can imagine the consequences in this generation. This will definitely be a very costly thing. Therefore, in software development and debugging, the interface is the top priority, not the implementation. However, our programmers always focus on implementation details, so their partial code is very good, but the overall software design is relatively poor. This requires our more attention.

10.- Code review mechanism
Everyone will make mistakes. The probability of one person making a mistake is very high. The probability of two people making a mistake will be smaller. The more people, The probability of making mistakes will become smaller and smaller. Because when there are more people, they can look at a thing from different perspectives. Although this may lead to inefficient arguments, compared with the maintenance cost of problems after the software product is released, this cost is quite worth it. Therefore, this is why we need to let different people reivew the code. The code review mechanism is not only the most effective mechanism for discovering problems, but also a mechanism for knowledge sharing. Of course, for Code Review, there are several basic principles below:

The reviewer’s ability must be greater than or equal to the code author’s ability, otherwise, code review becomes a kind of training for novices.
Also, in order for reviewers to be truly responsible, rather than just doing a perfunctory review, we need to make reviewers primarily responsible for the code they reviewed, rather than the authors of the code.
In addition, a good code review should not be when the code is completed, but iterative code review during the process of code writing. As a good practice, code reviews need to be done continuously every few days, regardless of whether the code is completed or not.

http://www.bkjia.com/PHPjc/320310.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/320310.htmlTechArticle1.- DRY: Don't repeat yourself. DRY is the simplest rule and the easiest to understand of. But it is also probably the most difficult to apply (because to do this, we need to use generic settings...