In every area of life there are people with some bad habits or misbehaviors that affect the work process. Software development is also not free of this kind of people. Today I will introduce you code wanderer.
Who is code wanderer?
Code wandering is more like bad habit than serious diagnose. Code wanderers tend to review and “fix” source code in files written by others. When code wanderer has some free moments he starts to open the code files he or she has never seen before and starts making little fixes to these files.
Why is code wanderer dangerous?
These fixes seem correct and are usually first choice to do when considering nice code. But as changes are made by coder who has no idea about the code he or she “fixes” then “fixing” usually ends up with messing up working code written by others. Often these “fixes” are not found immediately because they doesn’t introduce errors detected by compilers. So these “fixes” find easily way to production environments because there is also very good chance that “fixed” code goes through all tests without any problems.
How to stop code wanderer?
The first thing is to talk with person and explain him or her why those changes are dangerous. It is also good to establish rules that state clearly why, when and how can somebody change the code written by other people. If this does not work it is possible to isolate this person so he or she can post his or her changes to code repository as patches and somebody reviews those changes before applying them.
View Comments (8)
The code ReSharper-er. :)
It is understandable when entry-level Software Engineers do this. How, it is unfortunate and unacceptable when Senior level and higher- do it.
What is wrong with a little refactoring to tidy up code? Surely you have a good set of test cases that will pick up any errors that are being introduced!
Two words: test suite :)
It's really interesting article. Thanks for good information.
As stated in Martin Fowler's book, code must be refactored occasionally in order to keep the design from decaying and to get out the kludges as they accumulate. However, before any refactoring is the first order of business is to make sure that you have automated unit tests that exercise the code being refactored thoroughly and that you run the tests after each small change to make sure that the code still performs correctly. If all the tests pass but the code is not correct, the test is wrong or incomplete.
Have a good test coverage and dont stress about it. I better like idea of 'Boy scout rule' thats defined by Uncle Bob. Code shouldn't be 'untouchable'.
Thanks for feedback, guys! :)
Although you are correct mostly I cannot agree that code wandering is same as refactoring (okay, it may be same in the head of wanderer). When you are refactoring then you know the problem and you understand the code you are changing. You know what this code does and why. If you find something weird then you ask from your fellows about it - maybe there is some trick that you don't know or don't understand. Code wandering misses these important elements.