Recent Posts6651
Developer's Corner / Re: Going Over Old Code...
« Last post by wraith808 on November 22, 2012, 08:52 AM »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.
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.
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.
