In a totally not surprising turn of events I have had another giant steaming pile of elephant shit dumped on my desk.
I don't want to get into the details about the whole thing, but I inherited a code base that is awwwwwwwwwweful!!!! I have to refactor it. And not because "oh I could write this better" or "this doesn't follow the standard I was taught in my university class." It's "Cotton you have to fix this code base - it no longer works correctly."
Keep in mind this is coming from a guy who maintains THOUSANDS of lines of uncommented PERL. When I say aweful - what I just got takes the ticket.
So I've ID'd why it doesn't work. But I'm afraid changing It is going to have unintended consequences because I'm a sysadmin - not one of the programmers that's been on staff for 10 years.
So, I'm Seeking advice / strategies on inheriting a crap code base of a medium high (closer to high) mission critical infrastructure process which needs quick turn around.
Fortunately I can program, but looking for high level approach to disecting bad code base.
For example print code out -> make comments everywhere -> fully understand shit code -> refactor. I don't know how to ask this properly ... uh for example, as a medic we did ABC for unresponsive people "airway, breathing, circulation" just guidelines.
Thanks! I think right now I'm probably in the pissed off stage in the stage of acceptance. I'll get it done, but when this guy was looking at me telling me this - I was like freal?!?!? And on a Friday at 5:15?!?
Sometimes I'm jealous of our programming team. When they get hit with stuff like this they pull together -it's really cool to see. However, being a lone sysadmin can get hairy...
The good news is the part I'm going to fix is at least a terminal branch of the overall "trunk" but its the business end of a major enterprise-wide process.
First of all, make sure your using some form of version control (I favor git). Keep your commits small - each commit should only change one thing (and comment your commits properly, see https://chris.beams.io/posts/git-commit/) Build a test suite that covers current functionality before changing anything. This should be a separate project/program to the current code - try to leave the codebase untouched initially. Then start refactoring - your test suite will ensure you're not breaking things as you go and the version control will provide the history of the changes if something does go odd.
Honestly, @sanfordvdev I'm so disillusion by this whole thing that I don't have the energy to describe what happened right now. I wanted to update everyone here that I'm okay and wholly conquered that shit.
It was not easy. They dumped a gigantic mess on me and left me out to clean it up, alone. I'm wondering where the hell my team was?
I'll explain how I approached it later, but right now I'm still a little no happy about the situation.
