2

I'm working on a project which has a codebase of about 3500 files probably a few hundred less than that actually. This project is made in PHP and is a quite messy, in this case it means that the documentation is hard to understand OOP and procedural programming is mixed, dependecies are unclear and the ones who made the system where beginner programmers with all that that entails.

To be honest what they have done is impressive, it is a working product and all that. But debugging and adding new features is a real chore.

Now to my question what are some good criteria for wheter we should refactor the whole project or do a complete rewrite. I should mention that rewriting parts of the system as we go is probably a no go because of everything being interdependet.

Daniel Figueroa
  • 10,348
  • 5
  • 44
  • 66
  • 2
    Buy the book "Working effectively with legacy code". It's a great start. – Benjamin Paap Dec 11 '12 at 11:11
  • @Benjamin Paap I Actually sent a mail to my boss the other day asking if we could buy that book. :) – Daniel Figueroa Dec 11 '12 at 11:13
  • "3500 files [...] what they have done is impressive, it is a working product" - three points _against_ a complete rewrite - not a knock-out criteria but ... – VolkerK Dec 11 '12 at 11:17
  • @VolkerK indeed it is, but as I mentioned it's probably less than that, I don't really know how much of the code is 3'rd part and how much is made inhouse. It could be much less than that actually. But couldn't it also be a warning that if a rewrite doesn't happen now the cost of maintenance will grow to much? – Daniel Figueroa Dec 11 '12 at 11:20
  • 1
    @Daniel : Yes, that balance is ...the problem. Maintance + further development vs. knowledge/experience accumulated in code. As you might have noticed the answer section isn't actually overcrowed and I'm hesitant to write an "answer" as well; it's a difficult topic. For smaller code blocks as a rule of thumb version 2.0 is per se better than 0.9.8764. But once you reach a certain limit and your components have to interact not only with themselves but with the real, messy world it boils down to "more elegant yet not working" far too often. "Working effectively with legacy code" is a good read. – VolkerK Dec 11 '12 at 12:26

3 Answers3

3

If the application is big, successful, and does interesting things, an attempt to rewrite it by hand will likely fail. The rewrite will never have enough mass to displace the original, and you can't throw the original away until it does, meaning you will continue to have to enhance the original until the replacement is ready. Twice as much work, no additional value. You are much better off, likely, keeping the application and cleaning it up.

You might consider two ideas to help reduce the size of the code base:

  • Run test coverage on the code. Normally people use this to validate the application functionality, but if you run test coverage and simply run the application the code for an extended period of time, what it will tell you is what code isn't exerecised and therefore likely dead. If the system is mess, it likely has a lot of dead code, and this is an easy way to find candidates. There are test coverage tools that can collect data on your entire application with low overhead; you can use them on production code.

  • Run a clone detector. This will find duplicate code. Outright duplication is easy to remove. A good clone detector will find not just identical clones, but parametric clones, that is, code which has been copy/paste/edited but in a way that can be summarized with parameters. Parametric clones require more finesse to remove, but finding them tells you of likely missed abstractions, and removing them (by replacing with objects or methods) inserts those missing abstractions into your code, making further maintenance involving that idea easier. (It isn't a very well known fact, but clone removal also raises test coverage rates, if you are really using test coverage to verify functionality!)

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
0

If the application works already and there are no major malfunctions then I would leave most of it as it is since rewriting everything from scratch is always costly.

Perhaps you should consider reducing the amount files/lines wherever you see duplicated code making objects/functions to centralize everything as much as possible. This helps a lot for an eventual maintenance and doesn't require a large amount of time to do. Especially if it was written, as you say by beginners, you will easily find the "wrong approaches" to improve.

MAXIM
  • 1,223
  • 1
  • 9
  • 16
0

The basic criteria will probably be the time ( = money).
The estimation is always hard when something is big. Split it to the smallest chunks.

Mind the point of view. Your estimation will probably differ from the estimation of the previous programmers, as it will be biased by the style you prefer. Maybe a better choice would be to hire the previous programmers to "fix" the code.

Anyways, you should state the minimum requirements to call the app well written and easy to maintain, discuss this with the boss and the team, split to smallest possible sprints and estimate the time required for all of them.

If you are able to convince your boss that the rewrite will return in better ROI overall, do rewrite. Otherwise, learn the "new style". If you have the comfort to stop the business for the time of the rewrite, or a spare time to do it, you're lucky. You're even more lucky if the code is testable, or you have at least some unit tests. If this is not possible, you should implement functional tests at least to help with both cases (refactoring or rewrite).

Note, that each one of us will probably prefer to rewrite from scratch, than to refactor. Then rewrite this rewritten...

So refactoring is always a good choice, assuming you already have tests or you are able to easily implement the tests.

takeshin
  • 49,108
  • 32
  • 120
  • 164