-1

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?

gnat
  • 21,442
  • 29
  • 112
  • 288
Anon
  • 101
  • 4
  • 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 Jul 23 '13 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. Jul 31 '13 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 Jul 31 '13 at 23:51

2 Answers2

4

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.

David 'the bald ginger'
  • 574
  • 1
  • 5
  • 17
3

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

limpan
  • 131
  • 2
  • Before refactoring, write tests that cover the functionality, then use them to verify the refactoring didn't cause regression. See http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 – Mike Partridge Jul 31 '13 at 14:03
  • I agree @MikePartridge – limpan Jul 31 '13 at 14:22