Bodyguard Pattern Bodyguard Pattern"By definition, you only refactor code that is already working, which where I come from is scary. Working code is a valuable asset since it is hard to get right... and takes time. Touching working code is always a risk and so there should be a darned good reason for doing it" [1].
Pattern Name: Bodyguard
Also Known As: Protect Your Back
Problem
Performing changes through refactoring techniques in a functionally working code, can lead to the introduction of bugs or the complete uselessness of the modeling functionality.
Context
During the development of the project, refactoring techniques are applied as the source code evolve. The pattern "Refactoring in Very Small Steps" is completly or partially disobeyed, or given the type of refactoring, the volume of changes is big enough that the code cannot be taken to its original position in a simple way.
After appliying refactoring, the performed tests give a complete decomposition of the programmed functionality as a result, or in the best of cases, they reveal the introduction of bugs that cause results not according to the plannings.
The revision of the modified code doesn't lead to the solution of the introduced problems. Frequently, intents of correcting the lost functionality, cause that the code breaks down more and more, arriving to the point where it is necessary a complete rewriting of it.
Forces
The members of the programming team don't want to alter a code section after it is functionally correct. The realization of security copies is a backup tool easy to use and offers very good results. A code rewrite can cause an unjustified backwardness in the work schedule. It can also cause the appearance of new errors in the system. Solution
It is necessary to maintain security copies of the state of the source code of the program before applying refactoring where big code sections are involved. It is necessary to be completely sure that the performed changes will be able to be undone in case the refactoring broke the correct behaviour of the modified code.
Resultant Context
Keeping backup copies of the source code of a program before applying refactoring, assures the quick recovery of the system in case the refactoring process introduces irreversible changes.
The developers will have a tool that offers them the necessary trust to carry out modifications in the code without fear to lose the functionality already programmed.
This pattern can be applied making use of tools provided by the development environment in which the solution is being developed, or by means of semiautomatic mechanisms in dependence of the environment in which the realization of the project is unravelled.
Rationale
The refactorings, as they are defined in [2], are behavior preserving so that, when their preconditions are met, they do not break the program. However, the refactoring term is often used when it's not appropriate, as a synonym of restructuring [3]. The wrong use of both concepts can bring the use of one of these techniques in a non appropriate way, breaking the modified code.
One reason people don't change existing code is that they're afraid they'll break it [4]. Up to this point, it is necessary to wonder how sure the development team can be about the technique to implement not decomposing the performed work. Restructuring or refactoring won't have any importance if the code stops to offer the expected results.
On the other hand, program testing is an effective and practical way of improving correctness of software, and thereby improving software quality [5]. However, no system can be completely tested [6], therefore there are no mechanisms to assure that, after applying refactoring, errors will not be introduced in the code in a manner that they can't be detected by existent tests.
The use of this patterns breaks the barrier created by fear and offers the bases so that the development team decides to run the risk. A backup copy of the source code is clearly, the surest solution to the functional decomposition of a system.
Sources
In the Wiki pages about refactoring [1], under the link "TestEveryRefactoring", a comment appears on the topic of security copies by Falk Bruegmann. Kent Beck and Marnix Klooster gives their opinions about this approach in the same place. This pattern is born mainly from the combination of the ideas of these three authors.
References
[1] Cringely, R. X. Refactoring Refactoring: Sometimes (Even in Computer Programming) What Everyone Knows Isn't Always Correct. http://www.pbs.org/cringely/pulpit/pulpit20030508.html. (2003)
[2] Opdyke, W. F. Refactoring Object-Oriented Frameworks. University of Illinois, Urbana, Illinois. (1992)
[3] Fowler, M. Refactoring Malapropism. http://www.martinfowler.com. (2004)
[4] Jeffries, R., Anderson, A., et al. Extreme Programming Installed. Addison - Wesley. (2000)
[5] Cheon, Y. and Leavens, G. T. A Simple and Practical Approach to Unit Testing: The JML and JUnit Way. Department of Computer Science, Iowa State University. (2001)
[6] Jacobson, I., Booch, G., et al. El Proceso Unificado de Desarrollo de Software. Addison - Wesley. (2000)
[7] WikiPagesAboutRefactoring.
Actually, any good source code control system (version control) will have this already. The proponents of ContinuousIntegration don't allow for "platform" type changes, but even with that one can go back a revision or two to find where a bug was introduced. This does not appear to be a pattern at all; more of a larger context to a problem of which we are all aware.
Shouldn't this be called something like VersionControlPattern??
What happen if you don't have a version control system? the pattern goes hell because you aren't giving a branch to do backup copies different from CVS! I think the pattern must cover the generic term "BACKUP COPIES" which includes "CVS" and "no-automatic copies" or "copies-by-hand". The pattern must cover all possible aspects.
I have never seen a situation where there is a legitimate excuse for not using VerisonControl?. I have seen - and heard stories - of inexperienced or malicious programmers keeping code out of version control because of ignorance and job-security concerns, respectively. If you write software and your code is not in some kind of version control system, stop everything until it is. Even if it is a script for personal use. Keeping "backup copies" before every refactoring is no substitute. I don't think this is a pattern... in fact, it smells like a process AntiPattern because it implies a validity of completely backwards approaches. Making willy-nilly copies ("Backups") of your source code can lead to other problems, like "Which tree is current? Hmm, I don't know, I think I made some bug fixes to drivers.c in the Foo backup but then I changed the allocation model in the Bar backup." Or, "Bob made a backup on tuesday but he was using his copy of the code and then I made a backup on thursday but that didn't incorporate his fixes..." Regressions ensue and you don't even know, because now you don't even have an authoritative version of the unit tests. If you protest that your backup scheme is structured enough to avoid this kind of confusion, congratulations, you've just written a minimalist, ad-hoc version control system. There are rarely excuses for not using CVS, SVN, or some particular VCS, but you have to have something. In brief, I think this page can be reduced to the three words 'Use Version Control' and deleted entirely. --GlyphLefkowitz
I think the current problems are in the pattern context and solution. The term "backup copies" must be decomposed to show the possible form of copies (like using version control systems).
Please, sign your comments. In my work every pattern will have a section called "acknowledgments" where I'll mention all names that contribute to do a better stuff. -- SantiagoValdarrama.
This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004