Developer's Lesson

From:http://www.codeceo.com/article/10-years-20-tips-programmer.html

A programmer has 10几 years of experience with software development rules:

Development 1. Start with small things 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 very simple and almost without any of the required features, and then solve the problem one step at a time until I'm satisfied. I have never dreamed of being able to sweeping. Instead, I learn while developing, and the new information can also be used in the solution.

I like the phrase John Gall: "Complex systems are always derived from the evolution of simple systems." ”

2. Change only one thing at a time

When we are developing, we encounter test failures and ineffective functions, and if you study only one problem at a time, it will be easier to find the key to the problem. In other words, using short iterations. You must ensure that this problem is resolved before moving on to another issue. This applies to downward submission. If you need to refactor the code before you add a new feature, commit refactoring before adding new functionality. 3. Adding 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, since they were very useful from the outset. If the system doesn't work, then you need to know what's going on in the program-this is what the log does. This is also true of error handling--The sooner the errors and exceptions are processed, the better. 4. Each line of new code must be executed at least once

Before you actually complete a function, you have to test it. Otherwise, how do you know if it is carried out in accordance with your ideas? Usually, the best way to do this is through automated testing, but not always. However, each line of new code must be executed at least once. 5. Test the module first before the overall test

Some of the module tests first can save time. Generally speaking, we also have problems when consolidating different modules, such as the interface mismatch between modules. But if we can trust each component, then tracking the integration problem will be much simpler.

6. All things 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's very common to have unexpected problems when developing software.

Hofstadter's law actually says the truth: things take longer than you expect, even if you have considered the Hofstadter law in anticipation. 7. Understand the existing code first

Most encodings need 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 first need to understand the current solution. Otherwise, you are likely to break the existing function carelessly. This means that reading code and writing code are necessary skills. This is one of the reasons why seemingly minor changes can still take a long time to solve-you must first understand the context. 8. Reading and Running

Fortunately, we have 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. So make sure that you take advantage of both methods. Troubleshooting 9.bug is always inevitable.

I don't like the rhetoric that says software development can be "overnight." No matter how hard you try, bugs are always inevitable. It is best to have a system that can quickly troubleshoot, fix bugs, and deploy repairs. 10. Resolve the Fault report

Each developer should take the time to process fault reports from customers and fix bugs. This allows you to better understand the customer's intentions, understand how to use the system, know how easy to troubleshoot, understand the design of the system. This is also a good way to be responsible for your own development results.

11. Reproduce the problem

The first step in fixing bugs is to reproduce the problem. Then you have to make sure that after the fix, the problem will disappear completely. Such a simple rule ensures that you don't mistake the problem as a problem and make sure 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 interaction between them may leave you without a clue and at your wits ' end. Don't dwell on figuring 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 coincidence. As you change the value of the timer, it changes the frequency of the system reboot. So everything is not a coincidence. Add new features, and another irrelevant feature slows down. This is definitely not a coincidence. On the contrary, it is the content that you should investigate carefully. 14. Association time stamp

When troubleshooting, the timestamp of an event can be a good helper for you. Look for even increments. For example, if the system reboots and has just issued a request of about 3000 milliseconds, a timer may have been triggered to cause the reboot to occur. Team work 15. Face-to-face communication is the most effective

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

16. Rubber Duck Method

When you have trouble racking your brains, find a co-worker and explain the problem to them. Most of the time, when you are narrating, even if your co-workers are not saying a word, you may suddenly find the key to the problem. 17. Ask questions

Reading and running code is often very helpful in pointing out the purpose of the code and how it works. But if you have a chance to consult someone who knows better (like the original programmer), then don't miss it. 18. Sharing Honors

Do not covet the honor, who is who is the. For example: "Marcus came up with this idea ..." (if he really wanted to), instead of saying "what we came up with ...". Other 19. Try

If you don't know how a programming language function works, write a small program to understand how it works. This also applies to testing the system you are developing. What happens if I set the argument to-1. When I reboot the system, what happens if the service is lost. In order to study its working principle. 20. Sleep with problems

If you're dealing with a difficult problem, sleep with the problem. Scientific research has shown that this does not mean that you are not thinking actively, but your unspoken meaning has done so. The result is that the next day to study the problem, the solution is already ready. 21. job-hopping

Don't be afraid to change 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 continue to learn and understand software development. You can try different programming languages and tools, read software development books, and accept MOOC courses. Believe me, the quantitative change can achieve a qualitative leap, these small learning accumulation, one day will greatly improve your knowledge and ability.

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