Turn: 20+ lessons learned by the programmer

Here are some of the rules that I have learned about software development as a programmer through 10几 years:

Development  

1. Start small and then expand  

whether it's creating a new system or adding 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 phrase John Gall: "Complex systems always originate from the evolution of simple systems." "

2. Change 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 records 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. 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 thoughts? Typically, the best way to do this is through automated testing, but this is not always the case. However, each line of new code must be executed at least once.

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.

The Hofstadter law actually says the truth: the time spent doing things is always longer than you expected, even if you have considered the 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-you must first understand the context.

8. Read and run 

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.
Trouble Shooting 

9.bug is 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 inevitable. 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.

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 that the solution really works.

12. Fix known errors, and then see if there are any missing 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.
Team Work  

15. The most effective communication

when we need to discuss how to solve the problem, face-to-face communication is better than video, phone and email.

16. Rubber Duck Law  

When you have a problem you can't solve, you might want 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.  

17. Ask a question  

Reading and running code is often 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.  

18. Sharing Honor  

don't covet honor, who is whose is who. For example: "Marcus came up with this idea ..." (if that's what he wanted), instead of saying "We came up with ...".  
other  

19. Try  

If you don't know how a particular 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.  

20. Sleep with a problem  

If you are solving a difficult problem, 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. Job-hopping  

Don't be afraid to switch jobs. It is very interesting to work with different people, to develop different products and to feel different company culture.  

22. Continuous Learning  

we need to constantly learn and understand software development. 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.

I hope these experiences will be useful to everyone. If there is any irregularity, please correct me.

Link:http://www.codeceo.com/article/10-years-20-tips-programmer.html
English Original: Lessons learned in software development

Turn: 20+ lessons learned by the programmer