There is a dilemma: to choose to either refactor the code to implement new features? .
What is the problem - what exactly? . Since I took the article to consider only one aspect of this issue, we reflect on the fact that prevents us from implementing a lot of good functionality? . But I think from my experience a very good example.
We were doing great business automation system. I was hired for this job is for the development of this new system. New features we are ' slapped ' is easy, using ready-made libraries. Thus, on average, a new module was produced within two weeks. A few years later timing of the new features were delayed, and we have tried to get into smaller code, disassembled reluctant to implement job. What is the cause of these changes?.
Trying to quickly provide users with new features, we do not do code refactoring. Programmers are all different, the code was written right. But, in time, he became less and less suitable for use in the implementation of the new features. It became a lot of time to go to debug because it right in one location code, and this leads to quite breathtaking links to another message in a completely different module. To correct it, something climbs in another module. That's afraid to touch the system once again, no one knows where, who and how sideways crawl out your intervention. The story ended on the fact that the development of large, multi-functional system stopped. So, has led to an underestimation of refactoring stop the project.
As it happens, that the code requires refactoring? . We believe that the average programmer writes the code. Based on the job, he writes of his right, a little at the prospect of laying, but not too carried away by abstractions. Over time, functionality of the program is growing, and there are already existing code written by our the average programmer can not meet user requirements. If at this point instead of refactoring prefer hurry to make a new function for the user, it can be.
of the private part of the class to pull out the desired variable and work directly with her,.
the parameters of the function call to add a new parameter and set its value to the default.
the class to add a new variable, and then, for its value, in either case if the structures necessary to make the branch.
Ugh, this is enough to master of the grave to bring Fowler. He is so rude in their quest zarefaktorit all ( which is why I do not like his work and recommend to anyone not read ). So terrible had happened, in the right code, carried out the hole. Now, adjusting the value of the former private variable, we easily and naturally get an error in another class method is not designed for direct access to the variable. But we're not afraid of difficulties, we have a new feature to the user to provide? . User is happy, he does not care what 's inside the code, head - glad it is done quickly, the money received, the new ' Lexus ' bought and programmers are well - no hurry, and you can drink beer. It is tempting to continue to work in a similar manner to quickly implementing new functionality, and not giving time refactoring.
Unfortunately, the result will be sad. As the garden requires regular weeding, as the car needs periodic inspection and program code needed refactoring. So we came to the original question: take the time to refactor or better more quickly realize the wish of the user? . Do as the chief says. Say to do refactoring - do, says the new features do make a new functional -. You are the implementer, your case -' from the fence and dig up dinner '.
If you lead programmer, it is always the priority of refactoring. In the matter of the timing of the implementation period immediately call in the light of refactoring. It is difficult, we must be able to convince the authorities what to do exactly. Tactfully and without resentment, that the authorities are not stupid and understands the importance of your plan.
A boss I will not give advice, my blog is not for them, and they are unlikely to read it.
No comments:
Post a Comment