

Tips for taking over someone else's code - andygeers
http://www.geero.net/2008/04/tips-for-taking-over-someone-e.html

======
pmjordan
Overall, fairly sound advice. Where possible, I'd add _characterisation tests_
, which are incredibly useful if you're having to replace some chunk of code
in a large piece of unknown software.

I'm not so sure about the author's advice of rewriting code. This might be
fine if you're changing the code for yourself, and if said code is reasonably
small, but I'd consider it quite risky if this is code that's in use by other
people, and you've been tasked to fix a bug or extend its functionality.
Unless that code is actually not working properly, I tend to either just
document/rename it, or possibly wrap the APIs on it if I need to call it from
my modifications.

That said, it _can_ be very helpful to conflate copy & pasted code. Often, the
copy & paste was done with little thought, and will actually contain bugs
itself. It therefore deserves extra scrutiny.

~~~
andygeers
That middle one's a good point - I guess I should have explicitly said that
the code in question was a) pretty small and self-contained, and b) doesn't
have lots of people wanting to make modifications to it simultaneously, so
fairly drastic refactoring was possible in a way that it sometimes isn't.

Writing some automated tests for the code is next on my list of changes to
make (which I agree is probably backwards)

~~~
pmjordan
Really, the main risk of changing code that doesn't need to be changed is that
there is input data out there, which you don't have access to, that works fine
with the current code but your refactoring might introduce some
incompatibility. Of course, depending on the situation, it can still be worth
munging the code to be more manageable, but I would certainly not do that
without a reasonable set of tests.

Well, writing the tests _after_ some exploratory programming can work just
fine, especially when you're tackling a defect of some kind, such as "this
input doesn't work". The first thing I'd do is figure out why it doesn't work,
and then try a fix. Then try and guess at some possible new failures you might
have introduced, and feed the original code and your changes with the test
cases and see if you get what you expect. Then throw in loads of random real-
world input data to make sure that still works.

I'm not suggesting there are hard-and-fast rules here, I'm just trying to
suggest some techniques that have worked well for me. Foreign code is always
tricky and is always as much about making your own changes as it is about
damage limitation. It's like making changes to your own code, except with
blindfolds on.

