Programmer Programming 10 Commandments _php Foundation

1.-Dry:don ' t repeat yourself.
DRY is one of the simplest laws and the easiest to understand. But it may also be the hardest to apply (because to do so, we need to make considerable effort 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 existing code to let them invoke the new method with some appropriate parameters.

DRY This rule may be the most common rule of programming, and no programmer should have any objections to this rule so far. However, we can find that some programs forget this rule when they write unit tests (units testing): Let's look at some of the interfaces of a class, and if you're not using dry, then those programs that call the test on the interface of an instance class All need to be manually changed. For example, if the many test cases of your unit test do not use a method of a standard common construction class, but each test case itself constructs an instance of the class, how many test cases you need to modify when the class constructor is changed? This is the negative consequences of not using the dry law.

2.-a short method.
At the very least, we have three good reasons to ask programmers to write down short methods.

The code will become easier to read.
Code becomes easier to reuse (short methods reduce the coupling between code)
The code will become easier to test.
3.-a good naming convention
Using a nice uniform naming convention makes your program easier to read and maintain, when a class, a function, a variable's name reaches the level that can be "words too literally", we can have fewer documents, less communication. The article "Naming Design in programming" can give you some hints.

4.-gives each class the right responsibilities
A class, a duty, such rules can refer to the solid law of the class. But what we are emphasizing here is not a single duty, but a proper duty. If you have a class called customer, we should not let this class have the sales method, we can only let this class have the most direct relationship with the customer method.

5.-to organize the code.
There are two levels of organizing the code.

Physical layer Organization: No matter what directory, package (package) or namespace (namespace) structure you use, you need to organize your classes in a standard way so that you can easily find them. This is an organization of code of a physical nature.
Logical layer organization: the so-called logic layer, which basically says, if we connect and organize two different functional classes or methods through some kind of specification. The main concern here is the interface between the program modules. This is the architecture of the program modules that we often see.
6.-Create a large number of unit tests
Unit testing is the closest place to bugs and the cheapest place to fix bugs, as well as the success or failure of the software's overall quality. So, whenever possible, you should write more and better unit test cases so that when you have a corresponding code change in the future, you can easily know if your code changes affect other units.

7.-often refactor your code.
Software development is a continuous discovery process that allows your code to keep up with the latest changes in actual requirements. So, we often refactor our own code to keep up with this change. Of course, refactoring is risky, not all refactoring is successful, or we can refactor code at any time. Here are the first conditions for two refactoring code to prevent you from introducing more bugs or making rotten code worse.

There are a lot of unit tests to test. As mentioned earlier, refactoring requires a lot of unit testing to be guaranteed and tested.
Each refactoring should not be large, with little bit of refactoring to replace that large refactoring. There are too many times when we first plan to refactor 2000 lines of code, and in 3 hours, we abandon the plan and revert the code back to the original version. So, what we recommend is that refactoring is best built from the dots.
8.-program annotations are evil.
This one must be controversial, and most programmers think the program annotation is very good, yes, yes, the program annotation is very good in theory. However, in the actual procedure, the comments that programmers write are bad (the programmer's expressive power is problematic), which leads to the application annotation becoming the embodiment of all evil, and also causes us to read the program, most of the time, we do not read the annotation and read the code directly. So, here, we're not encouraging not to write notes, but--if your comments aren't good enough, you might as well spend more time refactoring your code, making your code easier to read and clearer, which is better than annotations.

9.-focus on interfaces, not implementation
This is one of the most classic rules. Interface attention is-"What" is abstract, the realization of the focus is-"how" is the details. An interface is equivalent to a contractual contract, and the actual details are equivalent to a kind of operation and implementation of such contract contracts. Operation can be very flexible, and contract contracts need to be relatively stable and unchanging. If an interface is not well designed and requires constant change, then we can imagine the consequences of this generation, which is definitely a costly thing. Therefore, in software development and tuning, the interface is the most important, not the implementation. However, our programmers always focus on implementation details, so their local code is very good, but the software overall design is relatively poor. We need to pay more attention to this.

10.-Code Review Mechanism
All people will make mistakes, a person's probability of error is very large, two of the probability of error will be smaller, more people, the probability of the error will be less and less. Because, a lot of people can look at a thing from a different angle, although this may lead to inefficient debate, but compared to the SOFTWARE PRODUCT release after the problem of maintenance costs, this cost is quite worthwhile. So, this is what we need to get different people to reivew the code, the Code review mechanism is not only a discovery of the most effective mechanism of the problem, but also a knowledge-sharing mechanism. Of course, for code review, here are a few basic principles:

The ability of the censor must be greater than or equal to the ability of the author of the Code, otherwise, the code review becomes a kind of training to the novice.
And, in order for the censors to be truly responsible rather than perfunctory, we need to give the censor the primary responsibility for the censored code, not the author of the Code.
In addition, good code reviews should be iterative code reviews instead of when the code is finished, but in the process of writing the code. Good practice, regardless of whether the code is complete, the code review needs to be carried out for a few days.