Comment by t43562
3 years ago
i.e. you're the only one who can update your code because only you know what it's precisely supposed to be doing. Also if you come back in a year you'd better be able to remember everything.
I am sorry if I am being a bit mean - I just have had to take over maintenance of things like this and have found it a nightmare from hell so far.
I think code comments and breaking everything into well-named functions, along with ample side documentation, make it fairly clear to follow. The business logic gets confusing - but anyone who had to work on the code would need to understand that first anyway. I don't think the code itself is difficult. It's all in the docs. Frankly, I don't always remember how something should work and I need to spend a few hours to re-understand some tricky piece of 10 year old code again before I change it. That's the job.
My main concern, of course, is not leaving a mess for myself. That should be every coder's priority. Then taking over someone else's projects wouldn't be so hard.
The problem with anything you've been doing for 25 years is there's not that much chance that I, or anyone else, will convince you to do it differently. That is true of me too of course.
Nevertheless, I highly recommend having automated tests and running them in the presence of memory profilers etc like valgrind if you're using a compiled memory unsafe language like C or C++.
I would look for another job if I had to work with someone that refused to write them to be honest. It's not that I love tests, but I have had to fix other people's bugs.