1.-Dry:don ' t repeat yourself.
DRY is one of the simplest laws and is the easiest to understand. But it can also be the hardest to apply (because to do so, we need to do a lot of work on 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 generality into a unique new method, and change the existing code so that they can invoke the new method with some appropriate parameters.
DRY This law is probably the most common law in the programming session, so far, no programmer should have any objection to this rule. However, we can see that some programs have forgotten this rule when writing unit tests: Let's testing, when you change several interfaces of a class, if you're not using dry, then those programs that call the unit test of the interface of a series of classes, Need to be manually changed. For example, if you do not use a standard common method for constructing classes in many test cases of the unit test, but each test case constructs an instance of the class itself, then how many test cases do you need to modify when the constructor of the class is changed? This is the consequence 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 can reduce the degree of coupling between code)
The code will become easier to test.
3.-Good naming conventions
Using a good unified naming convention can make your program easier to read and maintain, and when a class, a function, a variable's name reaches the kind of realm that can "words too literally", we can have fewer documents and less communication. The article "Naming design in programming that something" can give you some hints.
4.-gives each class the right responsibility
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 responsibility, but a right one. If you have a class called customer, we should not let this class have a sales method, we can only let this class has the most direct relationship with the customer method.
5.-organize the code.
There are two levels of organizing the code.
Physical layer Organization: No matter what directory you use, packages or namespaces (namespace), you need to organize your classes in a standard way, so you can find them easily. This is a physical property of the code organization.
Logical layer organization: the so-called logical layer, the main point is that if we put two different functions of the class or method through some kind of norms to contact and organize together. The main concern here is the interface between the program modules. This is the architecture of the program modules that we often see.
6.-creating a large number of unit tests
Unit testing is the closest to the bug, but also the lowest cost to modify the bug, but also to determine the quality of the whole software is the success or failure of the place. 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 whether 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 code to keep up with this change. Of course, refactoring is risky, not all refactoring is successful, nor is it possible to refactor code at any time. Here are the first prerequisites for the two refactoring code to avoid getting you to introduce more bugs, or to make the bad 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 is not big, with little bit of small refactoring to replace that large-scale refactoring. There are too many times when we initially planned to refactor 2000 lines of code, and after 3 hours, we dropped the plan and restored the code to the original version. So, what we recommend is that refactoring is best built from bits and pieces.
8.-Program comments are evil
This one must be controversial, and most programmers agree that the program comments are very good, yes, yes, the program comments are very good in theory. However, in the actual program, the programmers write the comments are very bad (the programmer's ability to express very problematic), resulting in the program comments become All evil incarnate, also caused us to read the program, most of the time, we do not read the comments and read the code directly. So, here, we're not encouraging not to write annotations, 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 commenting.
9.-focus on interfaces, rather than implementing
This is one of the most classic rules. The interface is focused on--"what" is abstract, the realization is focused on--"how" is the details. The interface is equivalent to a contract contract, and the actual details are equivalent to a kind of operation and realization of the contractual contract. The operation can be very flexible, and the contract contract needs to be relatively stable and invariable. If an interface is not well designed and needs constant change, then we can imagine that the consequences of this generation, this will definitely be a very expensive thing. Therefore, in software development and tuning, the interface is the most heavy, not the implementation. However, our programmers always focus on implementation details, so their local code is very good, but the overall software design is relatively poor. This requires a lot of attention.
10.-Code Review Mechanism
All people will make mistakes, a person's probability of error is very large, two people the probability of error will be smaller, more people, the probability of error will be less and less. Because, more people, you can look at a thing from a different perspective, 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, that's what we need to get different people to reivew code, the code review mechanism is not only one of the most effective mechanisms to discover problems, but also a mechanism to share knowledge. Of course, for code review, here are a few basic principles:
The reviewer's ability must be greater than or equal to the ability of the author of the Code, otherwise the code review becomes a training for the novice.
And, in order for the censor to be really responsible, rather than perfunctory, we need to let the reviewer take primary responsibility for the reviewed code, not the author of the Code.
In addition, good code review should not be done when the code is complete, but in the process of code writing, constantly iterative code review. Good practice, regardless of whether the code is completed, the code review takes a few days to continue to proceed.
The above describes the programmer's Joint Development Network programmer programming 10 Commandments, including the Programmer's joint development Network content, I hope that the PHP tutorial interested in a friend helpful.
