Hmm I have a application in flex (codebase around 20K lines) ... its sort of a social network meets digg kind of thing, I need to add more features to it. This is my first ever flex project. Now im in a dilemma as to whether to refactor or rewrite the application. Im having a lot of trouble understanding the existing code (there is no documentation and the original developer is missing!!).
Anyone faced with such a dilemma before? any opinions on what i should do?
Everyone faces this dilemma every day. The usual answer is to never rewrite anything from scratch. Identify the problem areas and refactor them in small pieces until you get it to where you want it. You might want to spend some more time learning the existing code before trying to make this decision.
This is a very subjective answer - but...
My thought on this is two-fold.
First, if you are asking whether or not to rewrite, 9 times out of 10, it's probably a bad idea. If you really need to do a full rewrite, there's usually very little question.
More practically, I would start with minor refactoring. This often helps me learn much more about the existing codebase, what problems were faced and overcomed (or avoided), what decisions and compromises were made in the oriinal code, etc.
Once you understand the original codebase better, you will have a much better understanding of whether or not rewriting is the "best" option. Until that point, it's all speculation, and if you're guessing, I'd say don't rewrite.
In most cases, a refactor is better than a rewrite.
Rewriting is more risky than refactoring. Every element of new design may skip some old-tested functionality which is critical but not obvious to the rewriter.
The fact that it's your first project with this technology adds more risk. You should better refactor.
I think that it depends on your mind about this application.
If you think of your application as a prototype that allowed you to learn some key points (language, field, ...), you can throw it and rewrite the actual software with your newly acquired knowledge.
If you think of your application as the actual software, then refactor it. Little by little. It may happen that you rewrite it at the end.
Im having a lot of trouble understanding the existing code (there is no documentation and the original developer is missing!!).
Sorry to say, but this is not a valid reason to do either. If you don't understand the code, how do you think to rewrite it?
Your first task is to understand the code. And yes that can be hard, but you better get used to it because most code will be "hard to understand". Documentation is often either not available or not up to date.
If you understand the code you can do some refactorings. But be sure to add unittests else you end up in a bigger mess than you started with.
Can be categorized into two things really.
1) Size of the project
If project is very BIG like say 10K lines. Refactor is the thing to do. as you won't have enough time to rewrite 10K lines. But, yes you can identify, isolate and rewrite any independent (decoupled) components therein which need serious repair. But, if project is a small one and is totally screwed up and you have time its better to think about rewriting.
2) Stage of the project
In projects, when we integrate several issues come up such as performance issues etc. For this, refactoring of a component is demanded. But if the project is in early stages it's better to think about changing the design or communication model/framework and rewrite the trouble causing component.
One thing is clear, the more decoupled the components in your system are, the easier it is to rewrite. So, remember to design things well, you may never even have to refactor!
Branch, refactor/rework in small steps, see if and where it broke to pieces. Rewrite only if changes showed a total disaster in the design.
One problem I think you need to be aware of in refactoring existing code in small parts is that it could still force you into a situation were you need to write bad code in order for it to fit into the existing system.
I.E They made some poor design decisions in the application and these affect the rest of the codebase. So you would need to address any of those issues before you change any given section. Examples would be they are using stupid ways to move data around, logic mixed with presentation code mixed in with dataaccess, literal numeric values are used across the site for the same thing. (I.E UserIsActive needs to be true and everywhere the coder sets this by using = "1") and so on.
My suggestion would be do refactor and rewrite both.
Configure Flex PMD to figure out blocks of unused, complex or inefficient code. This will help to understand your project condition and you will be able to figure out areas where you want to do a rewrite or a refactor.
Remember that your intution may guide you for complete rewrite but generally this is not a good idea as those ugly looking blocks of code are actually critical bug fixes and someone have invested hours of hard work to write it. You simply can't afford to loose it after your rewrite.
As a general principle
Rewrite the code and not refix the bugs.
Being said that there is nothing which says rewrite is better than refactor or vice-versa. You are the Neo Anderson of your project and you have to make that CHOICE.
Best of luck.
READ THIS ARTICLE!!!:
http://www.joelonsoftware.com/articles/fog0000000069.html
I was all ready to go re-writing a project till I read this.
Sometimes you can spend one week on rewriting some part of the system from scratch and end up at the same point as you were a week ago (with a buggy code). And even though you lose whole week on rewriting, it can still be good for you. You will learn a lot in that week, code will be easier to maintain, and you will be much more motivated. Of course this approach depends a lot on how much code you write in one week...