Going Over Old Code...

[Renegade]

So, I'm back at some code that I wrote quite a long, long while ago... and it all works amazingly well. And, it's just one fast hack after another. Fast, tight, get it done code, that is so utterly not reusable. Well, unless I want to do some copy & paste & refactor... 

And I know darn well that when I wrote it, I just wanted to get it done and working, and knew that it would take me 3x as long (at least) to get things done if I'd have done it "right".

Something like the old phrase:

Good.
Fast.
Cheap.

Now pick 2.


Anyways, now I'm debating whether I should just continue on, or bite the bullet and actually do some refactoring to clean things up. Decisions, decisions... 

[Ath]

Simple logic, IMHO:
if (minor_fixes_only || noDevTimeAvailable) {
  keepTheOldStuffJustFixIssues();
} else {
  refactorIntoModernStructures();
}

[Renegade]

Simple logic, IMHO:
if (minor_fixes_only || noDevTimeAvailable) {
  keepTheOldStuffJustFixIssues();
} else {
  refactorIntoModernStructures();
}

-Ath (November 22, 2012, 01:37 AM)

True enough.

But really, I've committed major sins. Like, it's almost the programming equivalent of worshiping the Devil... I suppose if I were to quote Aleister Crowley:

Black magic is not a myth. It is a totally unscientific and emotional form of magic, but it does get results... To practice black magic you have to violate every principle of science, decency, and intelligence.

Looking at one part... cripes... But it all works beautifully. I've just violated so much encapsulation... 

[vlastimil]

Old code almost always looks bad. Software engineering is too young and evolves rapidly. What used to be a good practice 10 years ago is frowned upon now.

Look at the current disputes about object-vs-functional approach to coding. Would all the nice object code we have written in the past decade be totally out of style in 2020?

I usually do not refactor just for code's sake. If there is a concrete goal and the old code stands in the way of progress, it gets re-done. But otherwise, I'd just let it live.

[40hz]

Probably presumptuous of me to even comment since what coding I have done in the last 10 years is mostly educational or hobbyist type stuff along with an infrequent fix sent over to some FOSS project. I haven't done any 'real' coding in years.

But I'm somewhat skeptical of many of the claims for code reusability. Certainly some stuff is. Core things like initialization routines, some snazzy error checking or sorting code, a security module or two... But from a lot of what I've seen, most code isn't all that reusable in practice. Especially now that coding conventions and best practices evolve so rapidly. And what was considered "good" a few years ago is often second guessed and replaced as new methodologies and paradigms emerge.

Top-Down, HIPO, structured, natural language, RAD, OOPS, 3-tier, RISC yadda-yadda all had their moment in the sun. Most made wildly exaggerated claims about solving the "programming efficiency problem" once and for all. And none did - although almost all of them contributed something worthwhile to the discipline in the process - even if some did nothing more than show us how not to do it. (APL and Prolog suddenly come to mind for some odd reason. )

So I'd agree with vlastimil on across the board refactoring. Unless there's a goal, why bother? You're a much better coder now than you were ten years ago. And your entire approach has probably changed a great deal since then. So why go and do the equivalent of rewriting a book report you did in back grammar school unless there was something in it that you had a use for?

Just my tuppence, but from what I've seen on contract jobs I've been responsible for overseeing, the best success was obtained with 85% code written specifically for the project. Only the balance came from purchased or reused code.

Maybe code reuse works well with something like database type apps where there's significant commonality of rules, objects, and tables used between one business and another. Especially when you consider most of what makes up your basic AP/AR/GL/INV accounting suite is already standardized to comply with legal reporting and auditing requirements. So reuse does make sense there. Just take a pre-written accounting package and add whatever customizations and special business rules you need.

But for what I call 'real' programs, I haven't noticed much actual code getting reused except for snippets or a few special routines.
 

[wraith808]

I think it really depends.  If it's just for you, and you understand it, and it doesn't stand in your way- let it live.  But in many cases, refactoring is for maintenance, and assumes you're working on a team.

Just my tuppence, but from what I've seen on contract jobs I've been responsible for overseeing, the best success was obtained with 85% code written specifically for the project. Only the balance came from purchased or reused code.

Maybe code reuse works well with something like database type apps where there's significant commonality of rules, objects, and tables used between one business and another. Especially when you consider most of what makes up your basic AP/AR/GL/INV accounting suite is already standardized to comply with legal reporting and auditing requirements. So reuse does make sense there. Just take a pre-written accounting package and add whatever customizations and special business rules you need.

But for what I call 'real' programs, I haven't noticed much actual code getting reused except for snippets or a few special routines.
 

-40hz (November 22, 2012, 08:09 AM)

I think it really depends on how it was architected, and what's considered reuse.  Certain things can make the use of code across multiple solutions very much likely.  Single Responsibility and Compartmentalization make it more likely.  The use of certain patterns makes it very much more likely.  Nothing is 100% written for you... but I've noticed as my approach gets more and more refined from job to job, there's less spin up time to get the base application going.  In fact, on my current solution, I just gave some developers from a new acquisition a presentation on how to get a solution going in our current framework.  It pretty much involves installing some templates into VS 2010, making a new solution from the template and running it.  And that was something that took a couple of hundred hours to get polished originally, so that's a significant savings on each solution.

And even with the framework I'm using at home, if I refine it to that point, when I create a new application, it should take me significantly less time to create each one.  So there's something to be said for refactoring.  But if it's just because it looks ugly but works, you don't plan to use it on any other project, and it's just you maintaining it... yeah.  What's the point other than an exercise.

[f0dder]

Ho humm.

A lot of the things that makes code 'reusable' is just general good programming practice, IMHO. Single Responsibility, commenting, documentation, modularization. You should almost never skip those, even if you're just "doing a quick hackjob" - since we all know that things tend to evolve beyond that. My day time job is working on a fscking big CMS in a fscking big company dealing with fscking horrible code - because the "this isn't reusable code anyway" mentality means every single of the beforementioned principles have been violated. Large amounts of copypasta, almost no documentation, about the only comments written are mine (after doing lots of code spelunking), et cetera. Is howwible.

Going beyond those principles, it can be worthwhile to add a few more tricks from the reusable-code bag, even for stuff that isn't going to be used in other projects. Like, for C++ code, splitting out core logic in it's own library, making it both easier to test as well as drive from a command-line tool, factor into a Windows service, whatever. You might not think you're ever going to need it, but spending that small amount of time while setting up your project is sooooooo much easier than properizing things later on.

One of the reasons fSekrit development has been stagnant for so long is that it started as a cute little hackjob. Some of the features I need/want to add for the next version, and needs to be in place before opensourcing, is proper modularization and librarification. The source wasn't all that bad, but it's really boring and tedious work when you need to do it down the road - and with the dayjob and whatnot leaving me with pretty limited spare time and energy, it's hard mustering the morale to take on the reeeeeally boring refactorings necessary before interesting tasks can be resumed.

So, while you shouldn't delude yourself that stuff is going to be reusable, coding for "reusability" is going to make your life a lot easier in the long run. Of course it's a balance kinda thing, you don't want to gold-plate your 100-line AutoIt script that does whatever simple task - but anything that's going to have any kind of longevity? Ask yourself how pissed you're going to be at your former self sometime in the future.

[wraith808]

Ask yourself how pissed you're going to be at your former self sometime in the future.

-f0dder (November 22, 2012, 01:04 PM)

LOL!  I like this! +1!

[barney]

Ask yourself how pissed you're going to be at your former self sometime in the future.

-f0dder (November 22, 2012, 01:04 PM)

LOL!  I like this! +1!

-wraith808 (November 22, 2012, 01:20 PM)

+10!!!

Currently going through code written a year and a half ago.  At the time, it seemed pretty obvious and cutting-edge stuff.  Looking at it now, it appears to be takeout from an Italian restaurant  .  Even if code won't be reusable in the future, it's wise to write and comment as though it will be.  As f0dder noted, code sometimes grows. and it can be embarrassing  , at the least, to share it  .