Code specification and refactoring

My point of view:

1. For programmers, code specification is too cumbersome and bad, but can not be no, the minimum specification is recognized C # Development specification;
2. The purpose of code specification should always be kept in mind so that programmers can obey it naturally.
3. Specification helps to reduce the difficulty of refactoring, and difficult refactoring often leads to bugs;
4. Constantly re-construction, continuous growth;

Code Maintenance Dilemma . Products continue to evolve and business adjustment, requires the programmer to maintain the code, for a mature product, code maintenance is basically the main work of the programmer. But why is it that sometimes the work makes us so difficult andbug- ridden? (code minefield) The flow of people is one of the reasons, after all, the same Code maintenance personnel may be more than one, the deeper reason is that we write inappropriate code, to the later (including ourselves, such as the code was developed three months ago) buried Thunder. At this time you are in the heart of the curse is not expected at the beginning of a normative constraints programmers writing it? Maintenance still has to continue, is to continue the wanton writing code, or refactoring for future maintenance to reduce the difficulty, this is really a problem.

Why should there be a norm ? The programmer should at least adhere to the minimum specification, the C # Development specification, which undoubtedly contains basic naming conventions, capitalization, and so on. In general, programmers who are able to follow the C # development specification can already write more crisp code. For different development teams, the specification is the team's development habits and effective experience of the summary, each team members should abide by, remember the code mined area mentioned earlier, inappropriate code is often in the first time the development of the burial. We should abide by the development norms, it has drawn a range for us, so that we can not cross the step. A long code approach can be laborious to understand, repeating code and writing dead constants are likely to be buried mines for the successors. Deeper layers, such as development habits and differences, use a different code architecture (or no architecture at all), which often breeds shallow problems that can make maintenance difficult.

brevity is the essence . The content of the specification should be as simple and straightforward as possible, for the simple reason that programmers do not like the cumbersome and impractical specifications.

Understanding Intentions - The driving force of self-compliance . Emphasis on adherence to norms is less than the intention to emphasize norms. Programmers should understand the intent of the specification, and from the practical understanding of the benefits of doing so, the intention is like the martial arts cheats to practice the heart, not understanding the benefits of the programmer can not expect to obey consciously. So-called do not change beginner's mind, Fang can always, for a mature programmer, the benefits of the norm he will be impressed with the heart, do not have to stress to abide by the norms, he will naturally abide by, because he has learned the benefits of doing so.

Refactoring -- Sometimes two executions of the specification . Refactoring can eliminate mined areas and not necessarily ensure that new bugs are not referenced, and refactoring is worthwhile for a piece of code that needs to be constantly maintained. It's better to re-create a more structured code, such as a few meaningful ways, to maintain an extra-long approach. The most basic refactoring is sometimes two executions of the specification, and the advanced refactoring is accompanied by a constant improvement in the programmer's level.

The code is more than a simple combination of language elements. We are more or less able to understand the benefits of compliance, but not necessarily and willing to get involved in the restructuring, many times we do not break the code maintenance of the dilemma, but continue to struggle in this dilemma, perhaps the last resort, perhaps not willing to touch the potential minefield, which lost a lot of growth opportunities, Every refactoring can prompt us to rethink: What kind of code is good code? This is a very interesting question for programmers, isn't it?

Code specification and refactoring