This is the second part of the series (dealing effectively with the code you inherited). You can see the first part here, second from here.
Try in this series to summarize the book “dealing effectively with the code you inherited”. We are now in the second unit which you talk about working with feedback the sense signal and numerology that we should wait for him when we edit the code to help us understand if we were walking in the right way or not.
Different methods of modification on any software system different programmers, in general there are two types:
- Edit and pray
- Cover and modify
Possible in this idea that they can be applied to many aspects of life, and like programming is a reflection of so life and way of thinking of the programmer. Either be programmed careful so that they don’t make a move without to be calculated safely, or that recklessly jumps and calls God to be his step blessing.
Edit and pray
When you start changing the code, start reading and try to understand it , then begin to make the change, and when finished choose the new features that you added, make sure that the program still works. Expect to experiment with other things within the program make sure that it still works as expected. If this is your style as a programmer, you should know that you are working with style Edit and pray.
Caution in programming is a feature of the coder is successful of course, but this caution can be misused to the point that living in the speed of your business and makes your life a nightmare left by the time you will see your program. And in order not to affect the new amendments on the rest of the program negatively.
I don’t think anyone who chooses to perform surgery complex, surgery doctor works with a kitchen knife, just because this surgeon will make the process very cautiously. Change the code in a professional manner like a little surgery , it takes both skills and tools adequate.
Work with caution is good, but not enough never in the absence of tools and the right techniques
Cover and modify
Style modification on the code here is completely different. The basic idea here is to cover the code safety net for the safety net prior to the amendment.
In other words, the cover and modify you mean: when you start to change the code, change the part below another part of the code network of the tests and then tweaking it with confidence. If you’ve been following this series since the beginning, you’ll notice the repetition of this term and it relates to the Always PAL tests, and our friends are real.
In the optimum condition in the life of a coder, the code covered a number of the tests that help to ensure that the new changes are good and lead the target or not.
The goal of these Tests is to give feedback on whether the new changes make our system The software is working as expected or is it the complexity of the code and make it is full of Pal Bugs.
Tests to detect changes in the code
There are many types of the tests vary depending on the goal of writing them:
The Regression tests writes until they are sure that the program works in the expected way .This type of the tests like having a Software Vise. The Vise is the same tool in the following picture.
Keep this Software vise the code fixed is not changing, and to make sure that the changes did not affect the operation of the program.
This type of the tests is effective but it is often at the level of the user interface user interface. As to the results to be public, such as that “the code no longer works in the expected way” without accurate details about the cause that led to the failure of the test or the part of the code responsible for this failure.
Imagine that the code you want to modify large and complex, in this case we need to know the most accurate in case of failure of the test, helping to reduce the chances places the error in the code. In this case we must use another type of the Testing is the Unit Tests.
Let’s imagine the following scenario: we have a code we want. Fortunately the coders to write unit tests. Try these tests and see that all is done successfully. We start by trying to understand the code by reading it and read the tests. We feel the desire to change the code to make it easy to read readable. Make some adjustments, and we conduct the tests and see that all of them are successfully. If we are now sure that despite the new changes, still the code works the way required. We perform the test after each modification, and we see sometimes that some of the tests fail. In this case we have feedback which is that the amendments that took place in this part of the code that is covered by this test is responsible for the error, i.e., it has changed the way design is expected and required of the program. Here specifically to see the importance of the unit tests and the difference between her and the regression test.
The Unit tests are one of the most important components of the work with the code you inherited
The bottom line
- The tests of all kinds are important because they give feedback on the status of the code at each modification.
- The presence of the Regression test is necessary and important, but having unit tests small and responsible for specific parts of the code more important due to the clarity of the feedback they give us about the cause of the problem, what provides them the time to fix the problems more safely.
Source: dealing effectively with the code inherited 3-semantics when you change the code