Version-comparison Debug
Prequel
Search shaving belly, I have a big force in these months, and there is really no debugging can come out as a story and everyone. The only bit of bug is due to the comparison of the object's pointer, resulting in the calculation result of the program to change. In fact, the ID of the object should be used to compare, so that the uniqueness of the calculation result can be guaranteed. Just at the beginning (around December last year) overtime, dizziness, fascinated, painted the object's pointer and the ID of the object. Since the situation needs to be compared by the ID, it is too rare, so it has been discovered in the last half of the year. However, this Debug process is relatively flat: first written a bunch of log, then track the calculation process of a particular ID object, this bug is so solved. To put it bluntly, it is written to write log patient STEP time. This story is written to everyone, hehe is really ..., so I can't write half.
Now the words come forward.
About topics
This topic comes from a Blog (Diffdebugging) of Martin Fowler. MF In this blog, combined with personal experiences, how to use the DIFF tool to combine version control to "debug". In fact, this process may all have used many times in unconsciousness, but until reading this blog, I really have a clear understanding of this kind of debug, there is really a feeling of 醍醐 醍醐 醍醐.
my question
Due to the change of GCL7 and GGJ9 sharing code, the automatic regression test of GCL7 engineering calculated has not been run in 3 days (always compiling, I didn't bother me). Operation today, it is a lot of problems. There are many problems, because this is expected. Most mistakes can be seen at a glance. However, there is a problem, but the calculation of the beam seems to have no errors - the amount of the prefabricated beam is wrong, because the prefabricated beam does not have a deduction relationship with other components, so what we do should not be It has an impact on the prefabricated beam. What is the reason?
Debug
The history of Beamcalculator.PAS (responsible for the unit) of Beamcalculator.Pas was compared with SourceSafe, and three changes were made:
1. The prefabricated beam calculation has replaced the original center line calculation function with the new central line calculation class (LiUHQ)
2. The rules of the beam buckle have extracted a specialized class (ZHOUF)
3. Modify the edge of the non-preformed beam and the centerline initialization process. (liuwa)
Change 2 is first excluded because the prefabricated beam does not board. Change 3 is also obviously excluded, because the calculation of the prefabricated beam does not call this initialization process.
The suspicion of change 1 (huh, this seems to be obvious. But I still like to take it unlikely, so you can concentrate on a point). However, the changes made by the change 1 are very small, just modifying a function call, as follows:
It turned out: DLENGTH: = TcSeg2d.Length (fbeamedo.linearedoinfo.midline);
Now: DLENGTH: = TcSeg2d.Length (Fbeamedo.midline);
The difference between LinearedoInfo.midline and MIDLINE is just a way to call different central line calculations. Also, the result of the new central line calculation method should be the same calculation results as the old central line calculation method.
The problem is definitely out of the structuradedo.pas unit of the calculation center line! I have been three days ago Structuradedo.Pas, Buildall, and then run automatic regression test. The result of this return is certainly unanimous, and I want to drink my tea while I am beautiful.
what? Is the comparison result still inconsistent? I can't believe my eyes, the problem is not in the calculation method of the center line! It is impossible - this is my first reaction. I gified three days ago Beamcalculator.PAS and the latest strutualedo.pas, again Buildall, run automatic regression test.
Contrast results!
I set out the god and carefully considering it for a while.
It is already determined that it is not a problem with the central line calculation, so the only problem may have a simple code above. But what is the problem with a simple change? Will it be the impact of changes in other units? From the analysis, it will not be, but I need an evidence. A simple certificate is better than all analyzes.
I played again with Beamcalculator.PAS and Struatualedo.Pas before GET, and keep other units are Last Version, then Buildall, perform automatic regression tests.
Contrast results!
I understand very well, the problem is in beamcalculator.pas. But I still don't know what the result is caused, and the simple change is impossible to make mistakes. Is there any impact on calculations in some cases? I will change these three days from Beamcalculator.PAS, and run automatic regression test. The results indicate that only the version after the change 1 will have an error, and the change 2 and the change 3 have independent of this calculation.
So, there is a problem there?
I seem to have fallen into "Impossible Puzzle" [1], then it should be my assumption itself, I should change from the current hypothesis. Which is a problem?
What is my biggest assumption?
- The only unproveted assumption should now be the result of the automatic regression test - I assume that the previous calculation results are correct.
What if the previous calculation result is wrong? I found a wrong Liangzi to analyze its settlement results, very strange, the result seems to be correct? And the previous result, how is it wrong?
Why do we have to use a new central line calculation method?
- Because there is a defect in the original calculation method.
Why is it seen in the code change, only the prefabricated beam needs to be modified and other Liangdu do not need?
- Because the non-preformed beam has used a new central line calculation method for a long time!
^ _ ^, I suddenly turned out: the calculation of the center line of the beam has been changed for a long time, and now we now only change its initialization process and calling method, this should not affect the calculation results. However, the calculation of the prefabricated beam is missing when the center line is changed long. Since then, the prefabricated beam has always been calculated using the old central line, not the prefabricated beam, has always used the new centerline calculation method. The wrong seed is actually buried in that missed modification, but because LinearedoInfo has not been removed from the source code, the prefabricated beam is rarely used (not the focus of the test), so until today's thoroughly When I was deleted LinearedoInfo, the error was "Suddenly" took it out, and I bite the poor me.
555 ...., the code for the front to change the beam is not what I change .....
It ends here
In any case, the problem is still solved. From beginning to end, I didn't use Delphi's Debugger. Write here, I suddenly think, Martin Fowler uses Diffdebugging as questions, except for the literal version contrast (DIFF), is it also I hope that this DEBUG mode is a DIFF between the traditional DEBUG mode?
It is really true, since it has automatic regression test, my compilation has changed slowly, and it is more and more dependent on this automatic return. Of course, our automatic return is not a real unit test, but it gives me a lot of TDD feelings, giving my refactoring, it is necessary to protect. It is also from this point, I truly love the program. My next goal is to completely change my daily work with "real" UnitTest and TDD!
Special acknowledgment
Special thanks to my development manager Yue Liang, he is working overtime to prepare the GCL7 automatic regression test tool, let it become a powerful tool from one of my ideas.
Note
1. I translated into "Impossible to Put". The Pragmatic Programmer, P212. Chinese version is "programmer cultivation"
