Refactoring Code: does the concept of refactoring exist purely because humans are not very smart?

[dennis-fedco]

If humans were capable of understanding most god-awful obfuscated computer code, whether it was binary, high level, or assembly,

 

will there be a need for complex refactoring rituals, design patterns, frameworks, application stacks, and so on?

I am wondering if the need to refactor code arose purely due to people not being able to comprehend, understand someone else's code.

 

It is sometimes said that perfectly refactored code is easier to change, and maintain.

While perhaps true in general, if humans were capable of comprehending code immediately upon access, no matter how horribly un-factored the code is, they will still be able to make changes to it.  Even if changes in un-factored code takes 20 times as much effort (i.e pure textual code changes), it still won't take as much time as common humans take now to make changes to god-awful un-factored code.

 

Are there any considerations that I have left out that will still make refactoring needed even if humans possessed super-human code-reading and comprehending abilities?

[requinix]

Complex refactoring rituals would still happen. They could be used to increase the efficiency of code, even if not to make it easier to read.

Design patterns would still exist. A design pattern is simply a common solution to a problem. They aren't necessarily object-oriented.

Frameworks would still exist. They're to save time in development not having to reinvent the wheel.

Application stacks would still exist. They're combinations of software so as long as software exists, they will too.

 

"Refactoring" is merely rewriting with the intent to somehow improve the code. Improvement in maintainability is one possibility. Improvement in efficiency is another. Those are are often mutually exclusive. Code that looks horrible means that it will be harder to alter.

 

I'm half-asleep.

[gizmola]

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]

I mean, if humans were smart enough to instantly know the absolute best way to write a program from start to finish, then they could probably skip refactoring. But only if the program never changes after they write it.

 

Refactoring serves two purposes. The first is to improve/refine code once something is working. The other is to make changes to accommodate new features or a design change.

 

Often, features that we aren't 100% sure how to implement, or don't how it will work with the rest of the system, take a bit of trial-and-error. So you maybe just make one class/method, and dump a bunch of code in to get a proof-of-concept. You don't want to spend a lot of time planning on this nice pretty system when you're not even sure if your idea will work. So, you just write some messy shit to get something working.

 

Once you have something working, then you can take some time to remove repeating code, reduce method/class responsibility, abstract some things, decouple some things, etc. This is refactoring. If humans were smart enough to know the end result before they wrote it, then they wouldn't need to refactor.

 

EDIT: Haha damn Giz, way to describe a nightmare scenario.

Edited August 20, 2015 by scootstah