It takes about 2.6 minutes to read this article.
It's not that the more code you write, the higher the quality of the code. Thinking is.
To solve a problem, turn on the computer and tear the code by hand. The final result is often a variety of code problems. After a series of iterations, the code accumulates and it is difficult to return. The final result is to push it all over again. The previous efforts are all in vain. The most typical is now The so-called agile sounds tall, but the actual landing is actually working overtime, because there is no time to think.
Many companies nowadays disrespect science and objective laws. If they are asked to manage pregnant women, I think they can't wait to shorten the 10-month confinement period to 2 months.
Programmers should insist on their own quality, and cannot change some very good ways of doing things because of product managers or bosses. Many problems can be solved through communication. In the face of complex requirements, the construction period is particularly short. You might as well listen to Mr. Chen Hao. (Screen name: Mouse with Left Ear) Method: Don't say no, but give the other party a choice:
1. I can work overtime to finish, but I don't guarantee good quality, you have to admit that there are bugs, and you have to give me 1 month to pay off the debt afterwards.
2. I can work overtime and still guarantee the quality, but I can't fulfill so many requirements. Can I reduce it?
3. I can complete all the requirements with quality and quantity, but can you give me 2 more weeks?
Seeing this, I think you will definitely think: In addition to programming, communication is also an art.
In the past two days, I learned Wang Zheng’s column "The Beauty of Design Patterns", which mentioned how to find code quality problems. You can examine the code from the following aspects:
1. Is the directory setting reasonable, the module division is clear, and the code structure meets "high cohesion and loose coupling"?
2. Do you follow classic design principles and design ideas (SOLID, DRY, KISS, YAGNI, LOD, etc.)?
3. Are the design patterns applied properly? Is there over-design?
4. Is the code easy to extend? If you want to add new features, is it easy to implement?
5. Can the code be reused? Can I reuse the existing project code or class library? Is there a reinvention of the wheel?
6. Is the code easy to test? Does the unit test fully cover various normal and abnormal situations?
7. Is the code easy to read? Does it conform to coding standards (such as whether the naming and comments are appropriate, whether the code style is consistent, etc.)?
The above are some general concerns, which can be used as regular check items and applied to any code refactoring. In addition, we also need to pay attention to whether the code implementation meets the unique functional and non-functional requirements of the business itself. There are also some common problems, as shown below.
1. Does the code fulfill the expected business requirements?
2. Is the logic correct? Have all kinds of abnormal situations been dealt with?
3. Is the log printing proper? Is it convenient for debugging to troubleshoot problems?
4. Is the interface easy to use? Does it support idempotence, transactions, etc.?
5. Does the code have concurrency issues? Is it thread safe?
6. Is there room for optimization of performance, for example, can SQL and algorithms be optimized?
7. Is there a security breach? For example, is the input and output verification comprehensive?
When I saw these, I only felt that it was inspiring, that it is not difficult to write code. What is difficult is to write good code. What is good code and high-quality code? The above 14 questions point us in the direction.
The above 14 aspects are worth printing out and pasting on the table as a reminder for our daily code writing. Although the process of solving these problems is time-consuming, with time, we can definitely write very good code. Become an excellent engineer.