10 programming sayings that every developer should remember

The so-called proverbs are simple and easy-to-understand ways to convey the proverbs and universal truth of life. they can help you deal with things in your life and work. That's why I sorted out 10 programming sayings that every developer should

The so-called proverbs are simple and easy-to-understand ways to convey the proverbs and universal truth of life. they can help you deal with things in your life and work. That's why I have compiled 10 programming sayings. every developer should remember them and arm themselves.

1. no wind or waves

Don't be nervous. This may be just a fire drill.

Whether the code design is poor can be seen in some places. For example:

* A. super large classes or super large functions
* B. code commented out in a large part
* C. repeated logic
* D. If/else nesting is too deep

Programmers usually call them Code Smell, but I personally think the name "Code alert" is more appropriate because it has a higher sense of urgency. Improper handling of fundamental problems will lead you to the future.

Note: The Chinese translation of Code Smell is generally "Code odor" or "Code taste". it is a hint that an error exists in the Code, developers can use this smell to catch problems in code.

2. mainly prevention, supplemented by treatment

Okay, I believe it!

In 1980s, Toyota's journal Operations line became named efficient because of its innovative defect prevention methods. Every member who finds a problem with his/her department has the right to suspend production. This method is intended to produce, solve the problem immediately after the problem is discovered, and cannot cause more difficult and more costly problems after repair, replacement, or recall due to its continued production.

Programmers always make productivity, which is equivalent to the error of rapid coding. Many programmers start code design without thinking. Unfortunately, this kind of Leeroy Jenkins reckless approach will lead to a lot of poor software development processes, and poor code needs to be constantly monitored and modified-and may be replaced completely. In the end, the factors involved in productivity are not only the time consumed by code writing, but also the time needed for debugging. If you are not careful, you will "pick up sesame seeds and lose watermelon ". (For small reasons .)

Note: Leeroy Jenkins behavior: a player in the WOW game, regardless of the individual, faces the enemy, resulting in the destruction of the regiment.

3. Don't be desperate (over-reliance on someone)

The public factor of a software development team refers to the total number of core developers that will affect the entire project process. For example, if a person is hit by a car or has a child or another person changes, the project may be out of order or even put on hold.

The public factor refers to some common factors in the development process. If more factors are crowded into the bus, the more unstable the bus is. therefore, control the bus factor to avoid problems.

In other words, what do you do if your team suddenly loses a leading member? Is the business still going on?

Unfortunately, most software teams fall into the latter situation. These teams train their developers into "field experts" who only process their own specialized fields ". At first, this seems to be a reasonable method. It is very suitable for automobile manufacturing and assembly production lines, but why is it not suitable for software development teams? After all, it is impossible for every member to grasp the nuances of the program, right?

The problem is that developers are not easy to replace. Even though each member can use the drawer method, the drawer method is very effective, but if the "field expert" suddenly cannot work due to personnel changes, illness or emergencies, the drawer method will collapse immediately. (So) it is vital that the software team has some seemingly redundant and important reserve power. Code review, pair programming, and common code can be used to successfully create an environment in which each developer is at least familiar with systems outside of the field of expertise.

4. melons and beans

In The Pragmatic Programmer book, there is such an explanation of "broken window theory": do not keep "broken windows" (poor design, wrong decisions, or bad code. If one is found, it will be repaired. If you don't have enough time for proper repairs, keep it first. Maybe you can put the problematic code into comments, display "unimplemented" messages, or use virtual data instead. Take some measures to prevent further deterioration. This shows that the situation is under control.

We have seen a well-organized system crash immediately after a "broken window. While there are other factors contributing to the software crash (which we will be exposed to elsewhere), ignoring ("broken windows") will certainly accelerate system crashes faster.

In short, good code will promote good code, and bad code will also lead to bad code. Don't underestimate the force of inertia. No one wants to organize bad code, and no one wants to mess up the perfect code. Write your code to make it more likely to withstand the test of time.

Author Andrew Hunt/David Thomas. This book is a direct hit on programming through the increasing specification and technical barriers in software development, and examines the core process-that is, based on needs, create code that is acceptable to users, work and easy to maintain. This book covers content from personal responsibility to career development, to maintaining code flexibility and ease of adaptation and reuse of architecture technologies. From this book, I will learn how to prevent software deterioration, eliminate the traps of replication knowledge, write flexible, dynamic and adaptive code, avoid the same design, protect code with contracts, assertions and exceptions, etc. content.

Broken Window theory: it is an understanding of the effect of environment on people's psychology. The "window breaking effect" theory means that if someone breaks the window glass of a building and the window is not repaired in time, others may be subject to some suggestive indulgence to crack more windows. You must promptly rectify and remedy problems.

5. speed is not up

Managers, customers, and programmers are becoming increasingly impatient. Everything that needs to be done must be done right away. As a result, quick fixing becomes urgent.

Do you have time to perform proper unit tests on a new feature? Well, you can finish the test first, and then you can come back to test it at any time.

Will there be a strange object reference error when accessing the Y attribute? In any case, place the code in the try/catch statement block. We want to catch a big fish!

Are you familiar with this? This is because we have done this before. In some cases, it is beyond review. After all, we have a deadline to meet our customers and managers. But do not perform this operation too frequently. Otherwise, you will find that your code is unstable and there are many hot fixes, repeated logic, untested solutions, and error handling methods. In the end, you can either make things done, or finish things well.

6. think twice

The term "Agile development" has recently been abused frequently and is often used by programmers to conceal their poor planning/design stages in the software development process. We are the designers. we should be happy to see the substantial progress of our products in the right direction. Unexpectedly, UML diagrams and case analysis do not seem to satisfy our desires. Therefore, when we do not know what we do or where we are, our developers are often confused to write code.

This is like eating, but you have no idea where to eat. Because you are too hungry, you can't wait to find a restaurant and set a table. Then, when you get on the bus and drive along the way, you want to (find a place to eat ). However, this will take more time, because you have to go through many U-shaped curves and stop at the restaurant. maybe you will not eat it because the waiting time is too long. To be exact, you should be able to find a place to eat, but it may not be the time you want to eat, it may take longer to order meals than you want to go directly to a restaurant.

7. if your only tool is a hammer, you will often regard everything as a nail.

Have you seen it? I have already said that dynamic records are valid in this project.

Programmers tend to narrow their horizons when talking about their tools. Once a method "works" on one of our projects, we will use it on all the subsequent projects. Learning new things seems to be a kind of torment, and sometimes you may be confused. From the beginning, I thought, "If I use the previous method, this will not be so troublesome ". We must discard this idea and do what we know, even if it is not the perfect solution.

It is easy to stick to what you know, but in the long run, it is much easier to choose a tool suitable for this job. Otherwise, it will be incompatible with your career.

8. silent consent

I saw nothing! No!

The "broken window theory" has a macro connection with "turning into inertial theory.

The programming community is like a real community. Each work is a microcosm of developers. The more bad code is released, the more likely it is to reflect the status quo. If you don't try to write good, clean, and stable code, you will be accompanied by bad code every day.

Similarly, if you see someone else writing bad code, you have to ask this person. Note: At this time, wit should be used. In general, programmers are willing to acknowledge that they still do not understand software development, and thank you for your kindness. Mutual help is beneficial to everyone. turning a blind eye to the problem only keeps the problem.

9. two birds in the forest, not like a bird in the hand

If you can discuss the system architecture and restructuring, you may have to wait for a while to complete the process. It is important to weigh the advantages and disadvantages of changes in order to make normal operations more concise. Of course, conciseness is an ideal goal, but there will always be code that can be improved through refactoring. In the programming world, code is frequently changed to avoid code expiration. But sometimes you must ensure that the code is valuable to the customer. Then, you are faced with a simple dilemma: you can't be one stone or two birds. The more time you spend on refactoring the old code, the less time you spend writing new code. You also need to find a balance between timely code improvement and program maintenance.

10. the larger the capability, the greater the responsibility

Without a doubt, software has become a basic and important part of our lives. For this reason, developing excellent software is extremely important. Bugs in table tennis games are the same thing. the Bug in the Aerospace aircraft guidance system or the aviation traffic control system is another matter. Slashdot once published an article about a small mistake made by Google News alone that evaporated a company's stock by $1.14 billion. For other examples, see "ten severe consequences caused by software bugs". These examples illustrate how much rights we are exercising. The code you write today may come in handy in important applications, whether you are interested or not. Write correct and qualified code!