3 ms·

Tips for taking over someone else's code

11 points by andygeers 19y ago

pmjordan 19y ago
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 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 ago
    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.

11 points by andygeers 19y ago

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 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 ago
  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.