| Many times (not departed as in departed, just - not there any more). Could of hard-won experiences: - under no ciscumstances should you do the rewrite until you understand the whole domain, which is not until you know the codebase inside-out. And even then it's probably a very bad idea ("Yes but the old version allowed us to do X..."). - start with business requirements: make sure you understand what people expect from the system, how they use it, what it does at high level. Sit with users and watch them use the app! - tests: do not touch the code until you understand the existing tests or, if tests do not exist, until you have covered the code with your own, preferably integration or end-to-end tests (unit tests are great, but they don't guard you against integration failures, which is what you want to be protected against here too) - skim the documentation if it exists, but don't put too much faith in it as it is probably out of date. Same for comments. - slowly start fixing bugs, cleaning up some code... whatever you do, make sure it is covered with tests. - good luck. :) |