Why I didn't pull out the key-Thinking about the program bug solution caused by unlocking

Why I didn't pull out the key-Thinking about the program bug solution caused by unlocking

When I returned to the dormitory at noon today, my roommate s couldn't pull out the key in the lock slot after unlocking the lock. In the past, the lock was not very easy to use. The lock can be opened within a few minutes after the left-handed and right-handed operation. This time, it is indeed possible that the card is tight. Roommate s has not been turned on for a long time. Then, I took it for a long time (almost the same method) and did not open it. At this time, roommate s told me that he opened the door to the teacher's house in the morning and did not open it. The key was broken in the room and he had just submitted for repair. At this time, my first reaction was: Don't try again, the key is very brittle, in case it is not more troublesome to break in, in the afternoon when the tutor went to the lab, I still want to go to work.
At this time, the J student in the dormitory next door also came over. One more student had another idea. He also came over and tried to pull out the key. It was also a long time, but it was unsuccessful.

During their testing, I thought: in order not to delay the progress of the afternoon, I will go to Aunt Lou Guan to report for repair. Aunt said that the locks master may go to dinner. You can check it yourself. I went there twice, maybe I went to dinner, but I did not get it. Then I ran back to the dormitory.

Sheyou S is still trying to pull the key. Because of the last key disconnection experience, he tried carefully and tried again and again ......

At this moment, another student, H, saw that we were getting the key. Then I took it and tried to pull out the key. At first, it was just like us, and it was ineffective. But the key was successfully obtained after repeated plugging and door insertion and removal.
My roommate s and I are grateful to everyone. Then, we cut the pencil core and put it in the lock core. The entire lock has a new look, and the locks and key pulling are smooth.
At noon, I thought about it repeatedly ...... Why am I not pulling out the key?
This led me to get in touch with the program design process and make a one-to-one correspondence.
1. Unlock normally-the program runs normally without any bugs;
2. Unable to pull out the key-a program running bug;
3. Repeatedly test and pull out the key-the common method tries to correct the bug;
4. other students help pull the key-they help solve the bug;
5. Ask Aunt Lou Guan for a warranty-find a specific Technician (Technical blog or hacker on the Internet) to solve the bug;
6. sheyou H unplugging the door and solve the bug;
7. Put the pencil core into the lock core-improve bug fixes, eliminate bugs, and avoid program errors again.
8. The last time I opened the door for a teacher, the key was broken. Previous program experience had a positive or negative impact on the bug. This time, it was also because of my timeness. I heard that the key was broken, dare not try.
9. If you do not want to affect normal rest at noon or normal work in the afternoon, the program design process requires progress. At this time, you must consider the schedule of the project team owner (such as the project manager, also have their own work habits.
10. My roommate and I didn't pull out the key-we didn't find the bug.
In this way, the entire unlocking process is the process of finding, modifying, and improving bugs in the program.
In the process of pulling out the key, that is, finding bugs, we used three methods.
Method 1: the common method (repeatedly trying to pull out the key) means to eliminate bugs one by one;
Method 2: Ask for help, that is, help debugging and searching for bugs;
Method 3: Ask the technical support staff for warranty, that is, find the IT professional to solve the bug.
Of course, during the test of method 1, my roommate and I obviously made an empirical mistake, that is, my roommate mentioned that he had locked the teacher in the morning and the key was broken. At this time, on the one hand, I considered the normal progress of my lunch break and work in the afternoon; on the other hand, I also considered that it would waste a lot of time in case the key was broken. At that time, I even thought: I had a normal rest at noon and continued the warranty in the afternoon. Obviously, I think too much, but it is completely unnecessary.
Comparison methods 1, 2, and 3; in fact, method 3 may be the fastest (in the case of days, places, people, and conditions ). Method 1 may be the slowest and risky. When unlocking, the key may be disconnected, the project progress may be delayed, and the normal work schedule may be delayed, the program design is reflected in the situations where bugs are not found, which takes a long time, and crashes. But think about it later. Method 1: Do it yourself, try it, and experience various rotations (that is, various ideas for solving bugs). If a bug is found, at this time, I will go back and think about the whole process of searching for bugs. I will be very happy and very impressed. If there are similar bugs next time, they will certainly be able to solve them.
If I did not speak after my classmate h came over, I would just pull the key. The traditional method combined with the new method, the final result was that the key was pulled out within two minutes. What reminds me of is that when traditional methods cannot solve problems in programming, we can consider another path. New ideas often break through the old thinking to achieve good results. But it may also lead to the risk of key disconnection, that is, the bug has not been resolved or even the risk of a crash. However, this increases the possibility of winning. That is to say, "The harder you work, the luckier you are !", From the perspective of probability theory, it is true.
This also reminds me of the questions I have discussed with my younger siblings: How can I solve the bug after encountering a bug? After the unlocking experience, I have strengthened my thinking more and more:
1st: Do your best to solve the problem by using the existing knowledge (existing procedural logic, notes, and books, you can consider looking back at another path to find a solution to the problem. If this method does not work after testing n routes, consider 2nd.
2nd: Ask the project team members/colleagues for help. Due to the closeness of your project, similar problems may occur during development. In this way, the discussion may soon generate a spark for solving the problem. If neither 1st nor 2 are feasible, consider 3rd.
3rd: When querying the Internet (Google search, csdn search, etc.), or using Internet forums, such as csdn forums and cnblogs, there are different sections, you can consider posting for help. I tried to solve 3rd problems that I could not solve in Articles 1 and 2.
Solving a bug is sometimes a painful process, even if there is no result for one or two days, but the more on the verge of despair, the less you want to give up on the bug solution. The problem will be solved. At that time, you will feel like you have suddenly realized that the problem has been solved. Unfortunately!

At lab