Here's what often happens:
You join a company/project that is trying to build some software to do a number of things, as set out in the goals/design/specifications.
You break things up into tasks and different members of the team start working on them.
Frequently there is a framework being used, and hopefully some conventions, but frequently there is a lot of uncertainty.
People start plowing away, and the way Programmer A does things vs. Programmer B might be substantial.
Now you have 2-3 semi-working pieces of the product and you start looking at the code, and right away it's obvious that this code was produced by two different people.
As "hypothetically" I might have been one of the people involved, even as I was coding my piece, I realized along the way that there were some things my code did, where given more time I might have made it more reusable, or had a better design, so if I'm lucky I might stashed a few comments or TODO in my code.
Now we're on to more items, and programmer 2 is doing something very similar to the first item, and there's a lot of copy and pasting involved.
We do some code reviewing, and it's clear to everyone that this is not DRY. There is a lot of code being repeated.
Programmer 3 just joined, and now has to do something very similar to what Programmer 1 did, and I did, but the problem is, that even though they are similar items, the team has not agreed which is the best way to do it, so Programmer 3 basically has to just pick someone to emulate (if we're lucky) or maybe decides that everyone else was an idiot and does the new component in a completely different way than the two previous components.
The PM and QA are reviewing things, and everyone is super excited because we're only three weeks behind the original schedule (of completion in 6 hours) and the system basically seems to do the things that it was supposed to do.
The only problem is, that the underlying code now looks like it was assembled by a chimp with ADD, and there are 12 new features planned for next week....
If you're lucky, maybe there's a lead dev, who goes in and adds a couple of much needed unit tested components, and redoes one of the sections and this then becomes "the reference" for how to do something similar.
If you're lucky, there's some design patterns being used.
If you're lucky there are code reviews.
If you're lucky people go back before anyone notices and refactor things to be consistent.
If you're lucky you have appropriate roles and responsibilities and some division of labor.
Programmers that care about the overall quality of the underlying design, or are incented to insure it has minimal bugs, or have to maintain it or keep it running are going to be interested in refactoring.
Then there are situations where someone is brought in to start working on legacy code, and they realize that what they've just been assigned to work on is a rat's nest of rotten spaghetti, and those three things that "the old guy never got around to adding but should be easy right?" are actually close to impossible to add given the original architecture (or lack thereof) and the fact that doing just about anything to it has the potential to create side-effects that will break unknown areas of the system, causing everyone to question the new programmer's basic competence.
No, I would not say that refactoring is related to understanding someone else's code, and thus used as an excuse because you can't understand what they were thinking.
- scootstah likes this