How did good software be written?

I have a lot of feelings when I participate in the software training of industrial logic.
Just like agility, a founder also said that agility is actually not mysterious. After several years of software development, a brain-loving programmer will naturally use these methods to improve work performance/efficiency. The same is true.

This is also the content of software training. Although many questions have been raised and improved before, in the real work environment, we can see a lot of code smell, which is powerless and can only be numb.
It is very helpful to take a look at this training. We have introduced various code smell/reconstruction methods in a systematic manner, as well as carefully designed practical drills and demonstration of some methods, are very beneficial.
Summarize some of the experiences that I think are important: 1 the code is modified repeatedly. I have had this experience before. I think a good code is only modified and modified, which is the same as writing an article. However, in fact, the software company may not think so, it may feel that it should not be modified after the code is submitted. If the modification indicates that the quality is poor, and some even adopt forced measures to lock the database, cannot be modified .)
2. Small-granularity reconstruction. Rebuild is divided into several small steps, taking only one small step at a time. After modifying a little bit, run the test case immediately and continue after passing the test case. Also become the baby step. Otherwise, you may not be able to run the use case at any time and check whether the modification will damage the existing functions .)
3. refactor with tools. It is much more efficient to use tools, and it is not easy to make mistakes. After mastering this routine, you can even refactor some codes that do not understand them with confidence. It's no wonder that TW doesn't understand the business, and it can also provide drastic guidance for restructuring. From this point of view, we are more inclined to supplement system use cases, rather than restructuring them. This is also a bit conservative. Of course, security is very important. We also emphasize automatic testing to ensure re-reconstruction .)
4. The comment is smell. The best code is very concise. The code itself is self-comments without additional comments .)
5. The long function is smell. Long is not an absolute length. If a software engineer looks at the function and does not know what to do, it is a long function .)
6. Pay attention to the code writing level. Writing upper-layer things, that is, close to the user's [such as the class user], then every sentence in it should face the user, users can easily understand the internal principles without understanding them. The real implementation may be encapsulated in a private method. This idea is also embodied in Agile story. It requires that the description of story be understandable to all users. In this regard, I think it can also be summarized as "writing code should be written like writing an article". It is estimated that no one will write the article as hard as anyone else can't understand it ?)

This article is from the "Jelly software technology blog" blog, please be sure to keep this source http://sinojelly.blog.51cto.com/479153/225444