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.
First read the Fowler's 'Refactoring' book; it was written just for you. Then:
1. Identify a small and easily separable piece of code (what you woud call a component in a normal system.)
2. Write tests covering every (important?) edge-case of the piece of code you want to rewrite.
3. Mercilessly refactor until it's nice and squeeky clean.
4. Lather, rinse and repeat.
And of course, make sure your client acknowledges that it's a giant clusterf... and is on board with you pulling the system out of the stone age.
Also, if you want to make life a bit more interesting for yourself, get the PHP code's AST and programmatically rewrite existing code to shared conventions for kicks.
As the title hints, it was written specifically and expressly for the "I just got a huge amount of complete shit of a codebase shoved unto me, how do I survive". Just check the TOC of part 2 (the meat of the book): http://my.safaribooksonline.com/book/software-engineering-an...
> And of course, make sure your client acknowledges that it's a giant clusterf...
That's hugely important. No promises of delivery, and that the client understands it's not a cakewalk.
Comments
1. Get it onto version control.
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.
First read the Fowler's 'Refactoring' book; it was written just for you. Then:
1. Identify a small and easily separable piece of code (what you woud call a component in a normal system.)
2. Write tests covering every (important?) edge-case of the piece of code you want to rewrite.
3. Mercilessly refactor until it's nice and squeeky clean.
4. Lather, rinse and repeat.
And of course, make sure your client acknowledges that it's a giant clusterf... and is on board with you pulling the system out of the stone age.
Also, if you want to make life a bit more interesting for yourself, get the PHP code's AST and programmatically rewrite existing code to shared conventions for kicks.
> First read the Fowler's 'Refactoring' book; it was written just for you.
"Refactoring" is not the tool for the job, although it's a nice sidearm.
What OP needs is the big gun, Feathers's "working effectively with legacy code": http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...
As the title hints, it was written specifically and expressly for the "I just got a huge amount of complete shit of a codebase shoved unto me, how do I survive". Just check the TOC of part 2 (the meat of the book): http://my.safaribooksonline.com/book/software-engineering-an...
> And of course, make sure your client acknowledges that it's a giant clusterf...
That's hugely important. No promises of delivery, and that the client understands it's not a cakewalk.