21–30 of 78 posts
One of the most important things is just to manage expectations - it sounds like you've got a huge task ahead of you and people will underestimate how long it will take you to fix stuff.
It might also pay to just focus on getting the software into a maintainable but ugly state.
I would start by spending a week or two wrapping the application in Acceptance tests (cucumber/capybara) just so when you do make a change you are able to quickly find out to a semi decent level of confidence things are ok. I would also recommend Working Effectively with Legacy Code By Robert C. Martin. Good luck!
This will allow you to be more aggressive when replacing crap code with new functionality.
Given this huge mound of code, this process will be quite a drag, but it will pay off in spades in the long run. Trust us.
2. Make sure there is some workable strategy for deploying and testing the code.
3. Ask somebody to provide you with a list of the changes, or else try to create some kind of diff against the original version of the code. If you can see crazy stuff here then find out who did it...
4. Ask somebody what the biggest bugs are? Which things are causing clients the most problems?
5. Try to establish which convention is 'winning' in the codebase. But you might want to create a more sensible convention which will allow unit testing (start this immediately!)
6. At this point, ask if you can hire people to work on this with you as it's a big problem, and you need to free yourself up for the rewrite.
7. If that isn't possible then leave. You have done enough to make your CV better and a company which passes you something like this does not care about your career.
Are you working on this by yourself? How long until your employer is expecting bugs fixed and features added?
Yes, by myself. The client so far has been understanding... they've already burnt through several contracting companies, and I think they're starting to understand what a mess it is. But still, they want to see serious progress within a month (eg. large number of bug fixes).
I would look at migrating the clients to another product that works, or even a less forked version of vtiger.
2. Set up a development environment and deploy the code there. Get it working. With code that large (and with the added wrinkle of executing code out of the database) changing things is going to be a nightmare of unintended consequences. Getting a testable environment up will let you find those things and help you understand what it does.
3. Get it in version control. This should be number 1: Before you make changes get a baseline of where it was.
4. Find a bug that exemplifies the nastiness of the whole situation and make a fuss. Let everybody know why this bug is so bad and what caused it. This will give your employer a concrete example to look at when you say "this code is shite". Harp on this bug.
5. Fix that one bug. Roll it out. Be a hero.
At this point you'll have a good base line, some credibility, and the organization will understand what a mess they've got. Now you'll have to figure out what you want to accomplish: keep it limping along? Improve it? Rewrite? The above steps will get your feet under you.
Are you working on this by yourself? How long until your employer is expecting bugs fixed and features added?
Yes, by myself. The client so far has been understanding... they've already burnt through several contracting companies, and I think they're starting to understand what a mess it is. But still, they want to see serious progress within a month (eg. large number of bug fixes).
Software Engineering is serious business, there's bugs, new features, maintenance, testing, etc. They failed to manage their code. You need to be realistic that with a team of 2-5 people it could take years to fix.
It might be best to put it out of its misery if they can't hold off their clients demands and buy you the time needed to rebuild it.
I've faced similar Augean stables in the past (and present, unfortunately). I'd suggest that correcting the DB is one of the last things you can do, especially if queries are scattered throughout the code instead of in functions. You could attempt to abstract it with an internal API and as you update the codebase replace with calls to the API. Once fully abstracted, you can then focus on getting the DB corrected and…
Second, I suggest applying as many tools as you can. A modern version control system, of course, and keeping any version control history that you inherited (although it sounds unlikely).
A powerful IDE might also let you start cutting out crap immediately, so try PHPStorm or Eclipse+PHP (or both!) and see what they can tell you.
And start writing tests as you start making changes, because you'll likely break something seemingly unrelated when you start changing things.