I have 22 lessons from programming summary

The following are some of the lessons I've been inspired by the software development process over the years, as well as the good experiences that have been summed up.

Development starts from the trivial and then expands

Whether it's creating a new system or adding new functionality to an existing system, I always start with a version that's simple enough to have almost no functionality, and then fix the problem step-by-step until you're satisfied. I have never been paranoid about being able to skyrocketing rise. Instead, I learn while developing, while new information can also be used in solutions.

I like the words of John Gall:

"Complex systems always originate from the evolution of simple systems. ”

2. Do only one thing at a time

When we are developing, we encounter the failure of the test and the function is invalid, if you only study one problem at a time, it will be easier to find the key to the problem. In other words, a short iteration is used. It is important to ensure that this problem is resolved and then transferred to another issue. This applies to submission down. If you need to refactor the code before you add a new feature, commit the refactoring before adding the new functionality.

3. Add log and error handling as early as possible

The first thing I did when I was developing a new system was to add logs and error handling because they were very useful from the start. It's more useful than a bunch of code for the system, and you need some way to understand the state of the program. If the system doesn't work as usual, then you need to know what's going on in the program-that's what the log does. The same is true for error handling-the sooner the error and the exception are handled, the better.

4. Each line of new code must be executed at least once

Before you actually complete a feature, you have to test it. Otherwise, how do you know if it is executed according to your idea? Typically, the best approach is through automated testing, but not always. However, each line of new code must be executed at least once.

In general, we want to trigger a condition that is difficult. But fortunately, we can cheat. For example, error handling of data can be triggered by temporarily misspelling a column name. Alternatively, an if statement can be temporarily reversed (from if error into if not error) to trigger conditions that are usually difficult to trigger, just to determine if the code is working properly and what it will look like.

Sometimes I find that there are some lines of code that will never be run. When we do code checking is it doesn't seem to be a problem, but it just doesn't work. You want to avoid this embarrassing situation, if you want each line of your new code will be executed.

5. Test the module before the overall test

It saves time to test some modules first. Generally speaking, we also have problems when we integrate different modules, such as the interface mismatch between modules. But if we can trust each component, then tracking integration issues can be much simpler.

6. Everything is going to take longer than you expected.

Especially in programming, even if everything goes well, it's hard to make the right budget for the time it takes to function. And, it is very common to have all kinds of unexpected problems when developing software. A simple merge operation can lead to a series of small bugs, and a frame upgrade means that some functions must change or some APIs do not work as you think.

Hofstadter Law ( Hof 's laws) is in fact true: the time spent doing things is always longer than you expected, even if you have considered Hofstadter law in anticipation.

7. Understand the existing code first

Most of the coding needs to change the existing code in some way. Even new features need to be adapted to existing programs. So, before you add new content, you need to understand the current solution first. Otherwise, you are likely to break the existing functionality accidentally. This means that reading the code and writing the code are all necessary skills. This is one of the reasons why seemingly small changes may still take a long time to resolve, because you must first understand the context.

8. Read and run the code

Fortunately, there are two complementary approaches to understanding the code. You can read the code, or you can run the code. Running the code is really a great way to do it. Therefore, make sure that you take advantage of both methods.

Troubleshooting 9. Bugs are always inevitable.

I don't like the rhetoric that claims software development can be "overnight". No matter how hard you try, the bug is always the same (the definition of the bug is basically: "We didn't think of it"). It is best to make a system that can quickly troubleshoot, fix bugs, and deploy fixes.

10. Resolve the failure report

Each developer should take the time to process the failure report from the customer and fix the bug. This allows you to better understand the client's intentions, understand how to use the system, know how easy it is to troubleshoot, and understand the design of the system. This is also a good way to take responsibility for your own development results. Don't miss out on these benefits.

11. Reproduce the problem

The first step in fixing a bug is to reproduce the problem. Then you have to make sure that after the fix, the problem disappears completely. Such a simple rule ensures that you don't mistakenly treat non-problems as problems and ensure that the solution really works.

12. Fix known errors, and then see if there are any other wrong places

Sometimes, there may be several different problems at the same time. The interplay between them may make you clueless and helpless. Don't struggle to figure out what's going on, solve all the known problems first, and then see what's wrong.

13. No coincidence

When testing and troubleshooting, do not believe that there will be any coincidences. Just as you change the value of the timer, it will change the frequency of the system restart. So everything is not a coincidence. Add new features, and another irrelevant feature slows down? This is definitely not a coincidence. Instead, it's something you should investigate carefully.

14. Associated Timestamp

When troubleshooting, the timestamp of the event can be a good helper for you. Look for even increments. For example, if the system restarts and a request has just been made for about 3000 milliseconds, then a timer may be triggered to cause a reboot to occur.

Cooperation 15. The most effective way to communicate face-to

When we need to discuss how to solve the problem, face-to-face communication is better than video, phone and email. I often find an exciting and better solution after discussing it with my colleagues.

16.The debugging method of small yellow duck

When you're stuck with a problem you can't solve, try to find a colleague and explain the problem to them. Many times, when you are in the narrative, even if your colleague is silent, you may suddenly find the key to the problem. It sounds like magic, but it often works. See this article for details: "Little yellow duck debugging, every programmer should know"

17. Ask a question

Reading and running code can often be very helpful in pointing out the purpose of the code and how it works. But if you have the opportunity to consult someone who knows better (like the original programmer), don't miss it. Continue to ask them specific questions and follow-up questions, and the information given to you in a few minutes is likely to take several days to get.

18. Sharing Honors

Do not covet honor, who is who is who's. For example: "Marcus came up with this idea ..." (if that's what he wanted), instead of saying "We came up with ...". Speak boldly of the names of those who have helped you or contributed to your strength.

Other 19. Do it!

If you don't know how a programming language function works, then write a small program to understand how it works. The same applies to testing the system you are developing. What happens if I set the parameter to-1? What happens when I restart the system and if the service is off? This is to study how it works. Often doing this will help you find bugs, and it will also deepen your understanding of the system's work.

20. Sleep with problems

If you are solving a difficult problem, then sleep with the problem. There is a scientific study that shows that although you have shown that you are not actively thinking, your unspoken intention is to do so. The result is that the next day to study the problem, the solution is ready to go.

21. Change/Job-hopping

Don't be afraid of character changes. It is very interesting to work with different people, to develop different products and to feel different company culture. In my opinion, too many people just passively stay in the same place year after year of work, only to change in the case of forced.

22. Learn to be old

One of the great charms of the software industry is that we have the opportunity to learn something new at any time. You can try different programming languages and tools, read the software development books, and accept the MOOC course. Believe me, quantitative ability to achieve a qualitative leap, these small accumulation of learning, one day will greatly improve your knowledge and ability.

Source: Bole Online

I have 22 lessons from programming summary