A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am the currently only coder of a rather large project involving ecommerce. It is written in VB6 COM DLLs and ASP exclusively. At this point, I feel if a team of programmers were brought on, it would be nearly impossible to direct design on something with next to no discernible architecture whatsoever. Obviously, a first step would be to write a spec (*grin*), and I am working towards that. However, the design and style of the code itself is a large barrier to writing a concise spec. Various portions are so incredibly illogical and complicated, it would be hard to "spec" it.
I do not see, in the near future (i.e. next 3 years), an opportunity to completely rewrite the project. Although I would much like to.
Is there any way to redesign the program without a complete rewrite (from the ground up)?
How familiar are you with refactoring? While one way to use refactoring is to do it continually as you go, another big use of it is to apply it to a complete project. The whole idea of refactoring is to "improve the design of existing code." In fact, that quoted phrase is the subtitle of Martin Fowler's "Refactoring" book.
There are little refactorings and big refactorings. With a project like yours maybe it would make sense to go through it and apply lots of little refactorings. That should make the underlying design a little more clear, and may pave the way to larger refactorings. I believe Joel has a relevant article on this; I think it may be the one where he argues that a total rewrite is almost never a good idea. One comment I remember from that article is his assertion that if you've got working code, then it's probably put together in a fairly logical way, even if you tend to think it's crap. Doing lots of "little refactorings" may help to make the underlying logic of your architecture more clear. (There may be parts that don't fit in at all, but you could make them fit better as part of refactoring process.)
As far as deciding what parts of the code to refactor, refer to Fowler's book and get familiar with the idea of "code smells". Basically, you learn to find particular instances of a bad type of coding in your app (they will have a "bad smell") and go through a systematic replacement of an instance of that bad coding with a good code pattern.
I noticed that there's a new Addison Wesley book that sort of continues where Fowler's "Refactoring" book left off. From just paging through it at the bookstore it looked good; that book may be another good resource, and I think there's another good book or two out there specifically about refactoring. But Fowler's is the best. And probably it would also be worth hunting down the JoS article where Joel argues against total rewrites.
Here's the Joel article I was thinking of:
And here's link to Fowler's Refactoring book:
here's link to newer "follow up" to Fowler's Refactoring:
and here's another Addison Wesley book on refactoring, Refactoring Wookbook. I don't know anything about this one:
I do not own that second book, but I own the other two.
They're both great.
In order to use refactoring correctly, you're going to have to start writing tests for the code. You need to ensure that the functionality before the change is the same as after the change.
Of course, that may be a good thing if it doesn't work now...
Why not go ahead and re-write it? .NET makes development relatively quick. And ASP.NET is far better and easier to code than Classic ASP. Besides, the end result may be much, much better than if you try patching up what you already have. In my experience, re-writing from scratch is always better than trying to improve an existing, klunky app.
Thanks for all the suggestions. I've actually done a lot of refactoring already, not knowing the term! And it has improved much over what it was even a year ago.
I may just buy that book. There is still a lot of work that needs to be done.
Rewriting it completely, to my chagrin, really is *not* an option -- especially in .NET, at least right now.
As Joel has covered...
Re-writing from scratch sounds like a great idea, except for: * you must catch up to your existing functionality;
* your competitors have a clear field for a while;
* you get to make all the same mistakes all over again;
* now you're supporting two codebases;
* the client normally wants things *NOW*, not after having to upgrade, convert data/files, and pay for the priviledge.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz