I am a web developer and at the moment am finding it hard to cope with long un-documented code written by previous developers in an organisation I work for. With the deadline gun always pointed at my forehead, it's doing my head in. I use aptana studio's search feature for some quick wins but it is becoming overwhelming to a point that I do not want to work with them anymore.

Is there any quick/proven approach that I can take to help me with a scenario like this?

  • It is NOT a full solution, but in C# you could at least make use of 'partial classes' to divide a class into its individual responsibilities. If time is ever available, refactoring is the better option.
    – Katana314
    Commented Jul 23, 2013 at 14:14
  • @Katana314 no, if you have a class with multiple responsibilities it should be multiple classes. partial classes should only be used for allowing a 3rd party to customize the class (e.g. with generated code).
    – jk.
    Commented Jul 31, 2013 at 21:31
  • @jk "should" is a sadly-neglected word of software development. Like I said in my comment: Refactoring is the better option and I'd much prefer code that's done in an object-oriented way. If no resources can be spared at all to do things the right way, then at the very least the file can be split up so that SVN comparisons are easier.
    – Katana314
    Commented Jul 31, 2013 at 23:51

2 Answers 2


To answer your question from an experience point of view there is unfortunately no 'good' or 'easy' or 'quick' way to manage long sections of code.

In our projects we dealt with such legacy code by breaking the larger chunks of code into smaller functions. But this is obviously a time based solution.

We initially applied the basic 'Pirate Rules' of a function should do only one thing and should preferably not have more than two parameters. Now we are adding that the new functions must also be Unit tested.


The short answer:

The only way to go fast is to go well. - Uncle Bob

If you don't take the time to gradually make things better they will never be good. You do it bit by bit, day by day.

A rule that I find useful:

  • Find out where to make your code change
  • Take some time to do some changes to the existing code to make your change easier to implement
  • Implement you change

Usually this doesn't take longer than trying to implement the change directly but you check in something that is better than what you checked out.

If you haven't done it already I recommend you reading Clean code by Robert C. Martin


Not the answer you're looking for? Browse other questions tagged or ask your own question.