How to grasp norms of the code?

1:30 minutes, I was staring less than a month ago I wrote a piece of code. At that time it looked like a piece of art, it is all understandable, elegant, simple, amazing. All this is no longer, tomorrow is my deadline, a few hours before I found a bug. At that time no longer it seems simple and logical strange. To be sure, if I write code, I should be smart enough to understand the code?
Later through a lot of this experience, I began to seriously wonder why my code is very clear when I write, when I was a few weeks or look back a few months later, when they are so hard to understand.
　　Question 1, overly complex logic model
　　for understanding between when you return from time to time to your code, but found it difficult to understand the code of the first step is to understand how we build the model from mental problems. Almost all the code you write all try to solve real-world problems. Before you write code, you need to understand what you are trying to solve the problem. This program is often the most difficult step.
　　In order to solve real-world problems, we first need to form a mental model of the problem [Note 1], as a programmer intent. Next you need to form a model program to achieve the intent of the program, we tentatively called semantic model (semantic model). Do not confuse your program never the intent and the intent of this program. We tend to consider major programs of stuff, but often ignore the intent of the model.
　　Your next step is probably the simplest form of semantic model. It is easy to mistake the second step. If you do not take the time to really understand what you are trying to solve the problem, you will stumble on a model when writing code. On the other hand, if you really think about the things you are doing as much as possible, you often get a very simple model, which is enough to make you grasp the original intent.
　　If you want to easily maintain simple code, to eliminate as much as some unexpected complexity. We are trying to solve the problem is complicated enough. If you do not have to do that, do not send unexpected complexity increases come in.
　　Question 2, clumsy ideological transformation into code
　　Once you make every effort to form the best semantic model, then to put it into the code of the time. We call syntax model (syntactic model). You are trying to sense your semantic model into a syntax that computers understand.
　　If you have a very good semantic model, but messed up when converted into the code, then modify the code in when you need to go back at a later stage, you will be more painful. When your mind when there are semantic model, your code is mapped to the semantic model is easy. Recalls variable "x" actually represents a record date to be created, and the date "y" Code record is deleted, it is not difficult. When you come back in three months to see the code, your mind will not have this semantic model, and therefore can not understand the same variable name.
　　The semantic model into syntactic task is to leave clues as often as possible, so that you return in the future, be able to reconstruct the original semantic model.
　　Well, how would you do it?
　　Class structure and naming
　　If you are using an object-oriented semantics, please try to get your name and class structure near the semantic model. Domain-Driven Design (Domain Driven Design) [Note 2] is put into practice in such a movement of considerable importance. Even if you do not fully believe the DDD method, you should very carefully consider the class structure and naming. Each class is left to your own and other people's clues, which help you rebuild your mental model in the future when returned.
　　Variables, parameters and methods named
　　to avoid common variables and method names. Do not split methods named "Process", because the more meaningful "PaySalesCommision". Do not put the variable named "x", as it should be "currentContract". Do not parameter named "input", because "outstandingInvoices" better.
　　Single responsibility principle (Single responsibility principle, referred SRP)
　　SRP [Note 3] is one of the core object-oriented design principles associated with good class and variable naming. It believes that any class or method should complete a single function, only a single function. If you want to give meaningful names for the classes and methods, then they only need to have a better-defined purpose. If a single class from the database to read and write, calculate sales tax, transaction notify customers and generate bills, then you may not give proper name. I often stay in the reconstruction of the class, because I always try to take a short enough names to describe each function it to do. For more discussion of SRP and other object-oriented principles, you can refer to my blog "object-oriented design."
　　Appropriate comment
　　If for some reason you can not make the code becomes clear that you sympathize with the future of their own, need to have to do something, then leave a comment to explain why you have to do that. Notes tend to become obsolete quickly, so I prefer to make the code as self-describing, comments to explain why you have to do that, rather than how to do it.
　　Issue 3, there is not enough chunk
　　chunk is defined on the psychological, the block information positioned single entity. So how to apply this to the programming? As a developer, when you gain experience, you begin to discover patterns in your solutions to recurring. High-impact design patterns: "Reusable Object-Oriented Software" is the first book to organize and explain some of the patterns. Nevertheless, with only the block and object-oriented design patterns. In functional programming (FP), the presence of a large number of well-known standard functions that have the same purpose. Algorithm is another form of chunks (more will follow).
　　When you use a reasonable chunk (design patterns, algorithms and standard functions), it makes you stop and think about how you write code that is running, rather than considering what it does. This shortens your semantic model (your code) and syntactic model (model in your head) distance. The shorter the distance, the more easily you rebuild your mental model.
　　If you are interested in learning more FP in function, please move to my article, functional programming for web developers.
　　Question 4, convoluted usage
　　At present, we mainly discussed how to structure your classes, methods and variables names. Another important part of the mental model is to understand how these methods should be used. Again, when you initially to form a mental model, which is quite clear. Later, when you return, it is very difficult to rebuild your classes and methods, all intentional use of. Usually this is because of different usage spread elsewhere in your program. Sometimes even in a lot of different projects.
　　I just found that test is very useful in this case. In addition to a modified accordingly know whether the destruction of the obvious benefits of code, provides a set of test use cases for your code. You do not have to search through 100 files, just look at the panorama test can get references.
　　Note To do this, you need to have a complete set of test cases. If your tests cover only a part of, and you think the test is complete, then you will be in trouble later.
　　Question 5, there is no clear path between different models
　　of your code from a technical point of view, often excellent, very elegant, but the intention of the program to the semantic model, and then there is the code very unnatural jumps. Consider transparency bunch of model you choose is important. Intent from the program to the semantic model, and then to process the code needed as smooth as possible. You should be able to see through all aspects of each model corresponding to the problem. In most cases, the best choice for a particular class structure or algorithm is not to isolate it in terms of elegance, but can be connected to a variety of models, for the purpose of leaving you rebuild a natural way. When you come to the specific programming code from abstract intentions, you make the choice you should be able to demonstrate more abstract model of clarity driven.
　　Question 6, the algorithm invention
　　as programmers, we often think that we invented in order to solve the problem of the algorithm. The fact is this is difficult. In almost all cases, there are already existing algorithms can be combined together to solve your problem. Like the shortest path search method, the string similarity algorithm, particle swarm algorithm. Most of the programming is the right combination, choose an existing algorithm to solve your problem. If you're inventing new algorithms, then either you do not know the appropriate algorithm, or you are busy on your doctoral thesis.
　　to sum up
　　Last Summary: As a programmer, your goal is to build to solve your problems, semantic model as simple as possible. The semantic model as closely as possible into syntactic model (Code), provides many clues as possible, easy to look after you no matter what people in your code, as you can reconstruct the original mind, the same semantic model.
　　Imagine, when you walk through the forest illuminated by your code, you leave crumbs behind. Believe me, when you need to find the way back, the forest is full of dark, dim and foreboding.
　　Sounds easy, actually doing it is very difficult. Added software development learning letter lion, let the teacher to tell you how to grasp norms of the code!