   Major Rewrites - how do you go about it?
  I've got a couple very large projects now that I am integrating into a single system. Both were prototypes, that do some things very poorly because of bad design decisions; or cannot have the features that I want because of architectural limitations. As far as rewriting goes, there's a couple routes I'm considering:- Start with an empty project, and go from scratch. As long as I don't get caught up in overly optimistic second-system-syndrome; I figure the time to redevelop the prototypes into a more workable architecture would be about 2 months, as opposed to 3 months to build the original prototype. - Start a new project, and reference the old code. My classes are all fairly modular (although my view+controller+gui stuff was all mashed together. This is a major reason for rewriting) and encapsulated into appropriate name spaces so this is straightforward, but might not force me to revisit some decisions that may not have been appropriate.- Start an empty project, and add code from previous versions as needed. This seems to make a lot of sense too.1+3 are going to be longer routes, whereas 2 will be quicker but has some draw-backs in terms of: if code is working, it likely won't be revisited until it starts causing a problem.  What's your folks general strategy in terms of rewrites of fairly large projects? Or going from Prototype->"Real" Project?As an aside, how is this handled in GameDev land, professionally? I'm assuming that when creating a new game/engine, as opposed to churned out movie/sports licensed stuff, much prototyping is done in the beginning and a lot of that code probably never gets reused. Am I right in this assumption? Coming from more of a business background, I'm more familiar with: "Get it working, fight the client on feature-creep" - as well as dealing with a lot more established patterns where, since you know what you're dealing with ahead of time and most "business logic" is fairly simple stuff. With games, I'm assuming if a designer has an idea for how some esoteric control scheme works or new gameplay gimmick (prince of persia? god of war?), lots of prototyping must be done and I'm curious what the code-reuse rate would be there...   
  For me, prototypes are a way to assess the situation: You can make errors early and cheaply.If your prototype is good enough (ie. clean code), and you haven't hit major problems with your approach to the project, why not keep it.But if you are anticipating major problems with further development of this code base, and you have an idea how to make it better, it would perhaps be better to restart.You'll have to calculate how cost effective each approach is.   ;Quote:What's your folks general strategy in terms of rewrites of fairly large projects?Ahh, I'm also gonna need you to go ahead and come in on Sunday, too...   ;Quote:Original post by AntheusQuote:What's your folks general strategy in terms of rewrites of fairly large projects?Ahh, I'm also gonna need you to go ahead and come in on Sunday, too...niceMy strategy is sleep deprivation - I'll re-write code from scratch with the existing code on one side of the screen, and the new code on the other. That way I can copy/paste what I need and refer to the other code easily. Also it helps to have a wide screen   ;  Evolution. Not revolution.   ;  I rarely have 'major' rewrites. In part because I rarely write major code.My preference on code is to write very short, very simple components, and then write code that links and calls the small segments. This means I never have a 'major' rewrite for anything, but often I have rewritten my core files at the different levels.   ;Quote:Start a new project, and reference the old code. My classes are all fairly modular (although my view+controller+gui stuff was all mashed together. This is a major reason for rewriting) and encapsulated into appropriate name spaces so this is straightforward, but might not force me to revisit some decisions that may not have been appropriate.Might not?Do you know what your code does or not?Do you know what you're going to use it for or not?If it's not going to cause problems don't waste your time fixing it just to satisfy some ethereal concept of programmer integrity. If it is going to cause problems don't hurt yourself in the long run by ignoring it.Your first task is to figure out if it's going to cause problems or not.   ;Quote:Original post by WashuEvolution. Not revolution.Exactly :) I know it's probably stressed a lot, but agile programming practices usually prefer iterative changes. If you're writing code and you notice something can be done better then make the change. Huge changes though should be a last resort.Also you might have an abstraction problem if your code is extremely heavily coupled into one another? That's probably for you to decide.My general approach is to use the VS comment todo program. My projects are riddled with "// TODO: X". I'll go on huge writing sessions and look at my notes and my todo items and then when I have the big picture refactor the code piece by piece as I continue to use it.(I've noticed this strategy doesn't work well in PHP for me. Still trying to get a rhythm of development for that.;Quote:Original post by SirisianQuote:Original post by WashuEvolution. Not revolution.Exactly :) I know it's probably stressed a lot, but agile programming practices usually prefer iterative changes. If you're writing code and you notice something can be done better then make the change. Huge changes though should be a last resort.Also you might have an abstraction problem if your code is extremely heavily coupled into one another? That's probably for you to decide.My general approach is to use the VS comment todo program. My projects are riddled with "// TODO: X". I'll go on huge writing sessions and look at my notes and my todo items and then when I have the big picture refactor the code piece by piece as I continue to use it.(I've noticed this strategy doesn't work well in PHP for me. Still trying to get a rhythm of development for that.This approach kind of requires that the design be good to start with though. If the design is inefficient, iterating on it will just be wasted time in the long run.If your running in the wrong direction, iterating and optimizing how you run won't change the fact that you are running the wrong way.   ;Quote:Original post by way2lazy2careQuote:Original post by SirisianQuote:Original post by WashuEvolution. Not revolution.Exactly :) I know it's probably stressed a lot, but agile programming practices usually prefer iterative changes. If you're writing code and you notice something can be done better then make the change. Huge changes though should be a last resort.Also you might have an abstraction problem if your code is extremely heavily coupled into one another? That's probably for you to decide.My general approach is to use the VS comment todo program. My projects are riddled with "// TODO: X". I'll go on huge writing sessions and look at my notes and my todo items and then when I have the big picture refactor the code piece by piece as I continue to use it.(I've noticed this strategy doesn't work well in PHP for me. Still trying to get a rhythm of development for that.This approach kind of requires that the design be good to start with though. If the design is inefficient, iterating on it will just be wasted time in the long run.If your running in the wrong direction, iterating and optimizing how you run won't change the fact that you are running the wrong way.Yeah it's a point I made on IRC.Quote:<Sirisian> Washu, to be fair he said major rewrites. Agile iterative changes as you face them don't always work :\