5 ms·
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 lot
by andygeers 19y ago
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 19y agoReally, 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.