The simplicity and rationality of the Code

the logic of winding
There are 2 types of role projections in the project: Ambient Shadow,realtime Shadow in the form of a round spot (but will be banned at low cost)
In the high-level for each role management, because the two kinds of shadow implementation is step-by-step, and is a lot of changes, so the code shows a more chaotic situation, and the logic of the two are implemented in different functions, intertwined with each other, ambient Shadow is true when Realtime Shadow is forbidden in the ambient shadow function, whereas realtime shadow functions do similar things.
This may seem like a trivial matter, but I am quite worried about it:

• A similar level of things in the project still a lot of
• It brings the consumption far more than looks serious

the source and extension of the problem
This confusion first reflects the solid level of our programming fundamentals (or Literacy).
The better case is that the ambient shadow and the co-workers responsible for Realtmie shadow in achieving this borderline situation can be viewed from the "Role Shadow Settings" range, and then maintain the simplicity and reasonableness of the implementation and logic.
The reason for the occurrence of logic winding is that the process of implementation and debug, just deal with the current situation and problems, not the overall corresponding clean adjustment.
After the logic is confusing, the same functionality needs to be done with redundancy, further aggravating the logic and resulting in additional performance costs.
In the finishing of this piece, and then found in the plot mode, set the full real-time shadow, the use of each frame to determine whether in the plot, and then set the practice.
Perhaps colleagues at the time also have this awareness, need to be in and out of the plot when the adjustment can be, but perhaps because of time, may be afraid of trouble (from the chaos of logic).
If not processed, this part will spread out a little bit, and the last item will rot a little bit.

to the positive and to the odd win
We actually do a lot of good things in the project, performance in the industry is also good, but why still in the basic place problems?
Here I also try to analyze the psychological factors, perhaps because:

• The industry has given too little attention to writing simple and reasonable code.
  
  • Do not dazzle: we like to talk about architecture, good algorithm, effectiveness, efficiency, but do not talk about the reasonable realization, as if the NBA is concerned about the slam dunk, rapid change to, etc., but for a solid pass run to give too little attention, this thing does not dazzle
• Slow:
  
  • Concise and reasonable always slowly a little bit of work (positive or negative), short-term difficult to quantify the value of time investment, code to write a concise and reasonable, not to debug and optimize it. The realization of stealing a little bit lazy, less pursuit seems to matter.

In other words, if the project time is relatively short, the requirements are not particularly high, then the practical utility of concise and reasonable is small, but if the project time is long enough, the volume and scope is large enough, the power of simple and reasonable will appear very large, at this time is not just the pursuit of the programmer's faith.

So some talented players (O ' Neill, for example) will start to pay attention to basic training when it comes to the high-level competition in the NBA in the early days of talent, and that's the key to winning.

Faith and Practice
The previous article (http://blog.csdn.net/toughbro/article/details/44497517) also mentioned that writing concise and reasonable code is not only a question of subjective will, but also an accumulation of problems.
Accumulation will be in peacetime in the practice of a bit, in those can be concise, not concise, choose the faith, to write a concise code implementation.
Otherwise in the real large-scale projects, when the pressure comes, can only powerless.

The simplicity and rationality of the Code