Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the rules of efficient programming". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought. Let's study and learn what are the rules of efficient programming.

1. Boy scout rules

"make sure the detergent in the camp is cleaner than you found"-this is a good rule of life. When you approach the camp, you should keep it clean, even if it is not caused by yourself. This is one of the rules of scouts. Programming is also applicable. As Robert C. Martin said, "make the code better than you find it." If we find some hard-to-read applications written by others and take some time to understand, at least make it better. If it is not within the scope of the task we are working on, we can always create a new small technical task, describe it in detail, and take it to the next sprint.

The minimalist version of this rule is more like singing in a public toilet. We should at least not worsen its conditions. We have to keep in mind that some people will one day take over that part of the application we developed and try to modify it. Let's not make life more difficult.

two。 Think about the problem, not just the solution

Software developers are really good at implementing solutions. We understand languages, patterns, libraries, frameworks, and how to use them. The problem is that from a business point of view, what we often do doesn't make any sense. Some of the features you are developing may overlap with existing features that the business owner does not know about. Some may not be thoughtful and will never be released to the next version, or no user will use them at all. It's a huge waste of time, money and frustration. Many people don't want to ask developers their opinions, just assume that their job is to deliver functionality. It's not negotiable. Only technical work.

Developers use the application every day. They know every function, even if no one uses it. Sometimes, tasks that seem easy to accomplish from a business perspective take months to develop. Some jobs that seem almost impossible take several days. The reason is the lack of communication between the person who is about to implement a function and the person who proposes it. There is a big difference between the two:

Create permanent storage for the user's shopping cart

Users should be able to save their shopping cart and use it on mobile and Web applications

The first one is very simple. I have nothing to ask. The second is more difficult because it makes you think about reasoning, and you will be the one who proposes the solution to a given problem. There will be a lot of questions about details, functional requirements, quality attributes and other aspects. Since you are not just the executor now, the solution will be better solved.

3. Consider the total cost of ownership

It is tempting to cut corners sometimes, skip tests later, leave temporary solutions and promise to correct them later. In most cases, if it doesn't break, you will never. There will be a new task, priority, functionality to be implemented, and problem to be solved. The problem you will encounter is that such applications may be corrupted. Moreover, it will be difficult to repair.

The total cost of ownership of a function is the sum of money and effort spent from development to deployment, maintenance to termination. If we take shortcuts in the development process, that will be the cheapest part. You may release faster, but maintenance will be troublesome, users will be dissatisfied, and in general, everything is more expensive than it should be.

4. Use SOLID

In programming, there are a lot of great rules in the form of acronyms: DRY,KISS,YAGNI,SOLID, etc. SOLID is a set of rules that can help make your code cleaner and avoid common pitfalls.

This can be a great listing before pushing the code to the repository. Does the course support the "single responsibility principle"? You can replace this class with any other class in the same hierarchy (does it satisfy LSP)? This will help filter out the sources of many future problems. Understanding and consciously applying the reasons behind each rule will make you a better programmer and improve the quality of code review.

5. Use design patterns

In most cases, you are not the first person to try to solve the problems you face or implement features with similar requirements. There are thousands of CRM,CMS, banking systems, chat rooms, online stores, markets, and basically any possible type of application that people can think of. The system you are developing may be the best on the market, or it may have some extremely advanced and unique features that others do not have. However, most of the work is referential to some extent. Others may try to do this in many different ways, or even describe the whole process. It can save you a lot of trouble and provide you with a better solution.

The Gang of four has a great book that introduces repeatable patterns that can be used to solve common problems. It was written in 1994, but those are still valid and useful. It was an ancient time in software, but now the problems we face when writing code are not very different. Since then, many new design patterns have emerged. Getting to know them can make your job much easier.

All designs are redesigned. Learn from others

6. Minimize complexity

In essence, software development is a complex task. Don't make it unnecessarily complicated. Sometimes it is tempting to implement some business rules by introducing some additional "if" or "loops" into the function. Development will be faster, but the code will become darker, and adding new features will only make it more complex. If something goes wrong, it will be more difficult to find out the cause.

There is a great and very simple metric whose secret name is "Cyclomatic Complexity". It was launched in the 1970s, but it is still very useful. This metric measures a variety of ways in which code is executed. Each conditional statement and loop adds a score of + 1. The smaller the score, the better. When we analyze a method, the score is in the range:

0-10: the code structure is reasonable and should not cause unexpected problems

10mur20: the code is very complex and there are many potential execution paths to test. Reconstruct the candidate

20mur50: the code is very complex and should be refactored

Over 50: refactoring must be carried out

Readability is more important than performance. The statement has some limitations, but readability is basically rewarding in the long run. You can change the code with fewer errors. Micro-optimization can easily mess up your code without bringing much value to the user.

7. Don't do it alone.

It may sound counterintuitive, but programming is a social activity. The era of programmers hidden in the darkness of the basement is over. Sharing professional knowledge and experience is becoming more and more important. In the worst case, the person you want to talk to will be your rubber duck, but chances are you'll get some valuable feedback. Someone may find a problem in the solution that you haven't considered at all. It's a good tool from a different point of view, and it's very easy to get.

No one should be responsible for the deployed code. It is the work of the team, not the individual, to provide new features. Code review, paired programming, and pull requests are tools that take responsibility for a person and hand it over to a group of people with the best cross-functional skills. Developers have too much responsibility for important functions that may affect the performance of the entire company. This situation is very unhealthy and should never happen.

8. Testing is necessary.

It is important to detect errors as early as possible, which can save a lot of work and angry phone calls from customers. Finding problems early makes it easier for them to solve them. When developing a particular application, we can best remember all the details and logic. We remember all the reasons for making a particular decision and how to debug each application. The cost of fixing errors increases exponentially over time.

9. Learn English

Knowledge sharing has always been one of the foundations of the software community. Most of the information is written in English and is easily accessible. At present, it is the most popular language in the software world. If you can't read and write in English, you will encounter a lot of difficulties and lose many opportunities. Moreover, the grammar of almost every language is written in English by default.

It is also a good habit to write notes and names in English. It makes the code cleaner and more consistent with the syntax. If we want to share code with others, especially people from different countries, there is basically no better way than English.

10. Multitasking makes you stupid.

People can't do many things at once. Software development requires the use of abstract concepts, and often requires the construction of very complex thinking models. If you are distracted or start doing something else, you will lose everything and have to start from scratch. In addition, several studies have shown that multitasking has a negative impact on performance, productivity and IQ.

I once attended a training in a software company and introduced a very useful practice. If you don't have any scheduled meetings or phone calls, you can play "Tomatoes" freely. The rules are very simple-you don't have to talk to anyone. If someone asks you any questions, you will answer in one word: "tomato". Therefore, you show that you are at work and do not want to be disturbed. When people are in "tomato mode", they also display the selected time in the calendar. Being completely "tomato" is not always a good thing, but it is an interesting way to improve performance.

11. Do less, the better.

Less code and better maintenance of infrastructure. There are a lot of people who like to brag about a lot of lines of code in their applications, modules, servers, nodes, pod, microservices or anything else. Every line of code in the application is likely to be of the highest quality and is in the right place. But this is a very rare situation. If you can do the same thing with fewer resources, you should do so. Quality is the goal, not quantity.

Thank you for your reading, the above is the content of "what are the rules of efficient programming". After the study of this article, I believe you have a deeper understanding of the rules of efficient programming. the specific use also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.