Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicates:
How do you dive into large code bases?
How do I handle refactoring that takes longer than one sprint?

I have 2 files that cover 5000 lines of code. I have been ask to fix THE problem. The code is object oriented but use hundred of flags, is multi threads, uses variable name without meaning, has recursion problems, etc... The problem is that rewriting the code will take a couple of months and there is not specifications. The specifications are encrypted in the code.

So the big question is do you have any ways or technique to fix/understand such bad code?

share|improve this question

migrated from stackoverflow.com Dec 21 '11 at 2:11

This question came from our site for professional and enthusiast programmers.

marked as duplicate by Mark Trapp Dec 21 '11 at 2:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4  
1  
Refactor, very slowly with mini steps... –  Erno Dec 20 '11 at 15:47
1  
Just my opinion: If this is a one time thing, great, take the challenge and fix it. If this is how you are always expected to work then this is a huge red flag. Nothing good can come of a situation where you are not given the time required to do it right and not given the specifications. I've been in that situation before -- the blame falls on the developer despite being expected to fix the problem in an unrealistically short amount of time and without any clear specifications. Work doesn't have to be like that... –  Matt Cofer Dec 20 '11 at 16:28

2 Answers 2

First off, I would advise you try to read through the code and run it (if it runs) to get as clear an understanding as possible as to how the code works.

Once you have that extent of an understanding, try to refactor elements of the code that should be easy enough, such as moving algorithms that are use multiple times into their own methods or classes.

After you have edited the code to that extent, if you wish to refactor more in order to clean it up but are not sure how best to approach something (or if you simply want help refactoring a more readable code base), then post samples of it on Code Review and others will review what you have posted.

share|improve this answer

Here's some tips that have helped me when having to do what you're having to do (these tips are catered to Object Oriented Programming (OOP) as you mentioned that was the type of code you're dealing with)...

  1. Break complicated parts into smaller chunks
    A tenet of OOP is to make code modular as much as possible. Instead of having a method that "does everything under the sun", parse it out into more manageable chunks. Also make your classes be specific; for instance, a "Dog" class shouldn't have methods for "Cat" in it; place common methods for a "Dog" and a "Cat" in the "Animal" super class and then specific "Dog" and "Cat" methods in their own classes.
  2. Use proper indentation/formatting/commenting
    One key to good code is readability, but often this is overlooked by developers who rush to get their code out the door and to the client. A good start with this code might be to properly format it with good indentation (i.e. 4 spaces indentation for each subsequent code block). Just lining things up in their proper place might make a world of difference in understanding all that the code is doing.
  3. Make small changes and test often
    Don't get into the trap of making a whole bunch of changes and then doing a huge testing session. Rather, make small changes and then test them. Also, it's a lot easier to take a small chunk of code, understand what it's doing and then modify it then dealing with a large construct. As you modify small sections of the code, you may also start to see patterns and be able to reuse those modifications (re-usability is another key component to OOP development) elsewhere.

Just remember to take your time and be patient with yourself. Above all, do it RIGHT so the next guy (which may be yourself 6 - 12 months down the line) won't have to deal with the mess you're dealing with now.

share|improve this answer