Where should the program be conceived before writing?

The structure should be clear and the logic should be rigorous.ProgramBefore writing a program, you must carefully analyze the problem, clarify the context of the program, and grasp the main logical clues. Once the main logic clue is grasped, the program can be divided into several parts to predict the difficulties and problems in advance. Finding clues is not an easy task. It is based on careful analysis and research on the problems solved.

When a cainiao like me is writing a program, he is always eager for success. When he catches the problem, he starts to crack the keyboard. The result is often a busy job for a long time and then return to the starting point again, a detail is not clearly considered, and the previous content has to be re-written when it is found. Or if you are lucky, you can run the program after it has been written together. However, because the logic is not rigorous and a bunch of bugs are made up, the program is barely supported. Such a program should not be a user, and has no confidence in it.

As a matter of fact, I have always understood the above principle. Every time before writing a program, I keep reminding myself to "analyze and analyze", but I keep an eye on the problem "analysis" for a while, I don't know where the "analysis" goes. Forget it. Write it first. It seems that it is difficult to analyze the results. As a result, the system could not stop until the program was strongly supported. For a long time, it seems difficult for me to get out of this strange circle. Even if some simple programs can be well written, it is difficult to ensure that the structure is clear and the logic is rigorous if it is slightly more complex.

What should we do? I think the following principles should be followed:

• There should be clear logic clues in your mind before you start, and the program logic can be implemented in your mind.
• Follow the logic clues to list the difficulties and problems that you can think of and find a solution. If the problem persists, go back to the previous step to check whether the program logic is faulty.
• If the first two steps are successfully completed, you can start to write the program. This will inevitably find many details. If there is a conflict with the design of the program logic, you should immediately stop and go back to the first two steps for demonstration.

The principle that runs through it is "Think about it again ". If you have a hard time thinking about it, you can do it. If something goes wrong, you can think about it ". In practice, it is difficult to grasp the degree of "doing something". It is often a thousand miles away when the gate is opened. How can we determine this degree? I think in the end, you have a sense of control over the program, and you must keep the program under your control. For example, if a function contains more than 50 rows, it is a dangerous signal.

for a person who is used to thinking about Code , such analysis may be uncomfortable at the beginning, however, it can greatly reduce the time for code Daze. So if you are not used to it, just get used to it.