To Re-Write or Re-Organize...???

• • Reply

  13 years ago

  by Spyder_Snyper

  Jon Moore

  , Japan

  Joined 14 years ago

  So I've got this little app that I've been working on for the past...year and some.  It started off as one thing and then feature creeped to it's current version.  As features creeped in, the code got a little disorganized (I think) and some code can probably be re-written to be much more efficient.

  The next big version will be Database driven, instead of just being a flat single file.  Now...  At this point, what would be easier?  Would it be easier for me to go through my existing code and "retro-fit" it with the new code for the database?  Or would it be better for me to go back to the drawing board and create a whole new app and keep it nice and organized and maybe copy/paste the good/difficult code that's already been done?
  

  Report abuse
• • Reply

  13 years ago

  by jmcilhinney

  John McIlhinney

  Sydney, Australia

  Joined 15 years ago
  It's impossible for us to answer that question without seeing the code.  That said, I think it likely that rewriting your code with a proper organisation now will ease maintenance in the future.  For instance, if you'd extracted the data access to its own library before then you could simply write a new library that accesses a database instead of a file and swapped one out and the other in.  Perhaps now would be a good time to organise your app that way so you don't have to ask this same question again in another year or two.
  
  Report abuse
• • Reply

  13 years ago

  by Spyder_Snyper

  Jon Moore

  , Japan

  Joined 14 years ago

  Quite true!  Which is why I want to look at my code...lol...Kidding.

  But I figured as much.  I was looking for something pretty vague like that.  Thanks.

  But now that I'm re-writing my code, I don't want to fall back into those 'bad habits' that are making me need to re-write the app.

  Now part of the problem I think is that the only coding I've ever done is stuff for class back in the day and stuff that only I work on.  Come to thinbk of it, I've never really ever seen any real 'professional' code...

  Like, I've seen the code for various open source projects, but I have NO idea what I'm REALLY looking at, so I never manager to really decipher any of it...  What kind of resources are me for that?  I mean, I don't even know what I would want to search for in Google for this...lol...It really is THAT bad...lol...

  So where could I look to find some 'best practices' for organizing the code and how it's layed out, how things are labeled and stuff?  Naming conventions and such I suppose.  But like I said, I have NO idea what to look for...lol...

  If anyone has any kind of pointers or hints to throw my way, PLEASE do so.  At this point, I'd be happy for any and all help.

  Thanks.
  
  
   

  Report abuse
• • Reply

  13 years ago

  by jmcilhinney

  John McIlhinney

  Sydney, Australia

  Joined 15 years ago

  You might want to look at n-tier design for a start.  You basically build your app as a series of self-contained layers that each expose an interface to the layer above.  The most common is 3 layers: one for data access, one for business logic and one for presentation.  If you need to change your business logic, for example, you can just change that one layer without affecting the other two.  If you need to start using a database instead of a file as a data source you can simply remove the data access layer and slot in a new one with the same interface but a completely different implementation.  The layers above are none the wiser because what they can see, i.e. the interface, hasn't changed.

  Such a design pattern makes for more work initially but, properly implemented, makes maintenance orders of magnitude easier.  It's important to spend the appropriate amount of time in the analysis and design phases so that your layers don't bleed into each other, defeating the purpose.
   

  Report abuse
• • Reply

  13 years ago

  by joe90

  J Alan

  , United Kingdom

  Joined 15 years ago

  Following on from what jmcilhinney has already said, one practice would therefore be: "program to interfaces and not implemenatation" (a google search for which, will pull numerous hits, as will "programming best practices")

  That said, following any "best practice" is not necessarily as easy as it may sound... and a decent pinch of pragmatic salt will inevitably find its way into your thinking over time.... as it does for most best practice behaviour. The use of best practices does not abdicate your own responsibility for analysis and general thinking. Best practices are guides IMHO; To be used when and where appropriate.
  

  Joe 

  Report abuse