The so-called "broken window Effect", that is, a house if the window is broken, no one to repair, soon, other windows will be inexplicably broken; a wall, if some graffiti has not been washed off, soon, the wall is full of messy, unsightly things; a very clean place, People are embarrassed to throw rubbish, but once there is rubbish on the ground, people will not hesitate to throw it, without any shame. Our development process is a lengthy process, and a broken window may be a poorly designed code, a poor management decision that the team must endure throughout the development of the project, but this is enough to make the project start to decay. once in the studio development process, those I seldom pay attention to in the development of these details. In fact, throughout the development process, our psychological changes are very subtle. We have to constantly terrain ourselves. Once, I wrote a tool class, and did not care to write the neatness and consider the rationality of the design because it was too eager. Some of my teammates have changed my code according to my Code style, and some have written some other tool classes. This is bad, after version control update, I found that the code is not so messy. Also once, in the beginning of an app development, do not want to clear the intention to use an interface framework, although cool, but with the real needs of the customer implementation of the function of the discrepancy, and the implementation of a more troublesome. Later had to make a big change to the whole. these are their own personal experience. If we find ourselves working in a project with broken windows, it's easy to think: "How the rest of the code is optimized and what I have to do, I'll do just fine." "Whether the project has been good before, and it doesn't matter. follow the same path, if you find that your code for your team and function is pretty--well-written, nicely designed, and elegant enough. Then we'll probably pay extra attention to whether our co-authoring will mess it up or get dirty. We will also learn this style to keep our projects in a lasting elegance. Canonical programming may be a practice for Android programming specifications, and it also requires us to always remind ourselves that programming is not random.
Programmer's Way of cultivation (2)-Don't let "broken windows" ruin your project.
