In the second part of this post on rescuing web applications, I'll go through some techniques for refactoring the codebase of an existing project. This is for the case where you've decided that there is hope for your project, and that the best course is to take the time to fix what's already there, as opposed to starting again from scratch.
Most programmers have the best of intentions. We all like to produce code that: a) nails a particular feature; b) runs quickly; and c) reads well. Despite these intentions, we've all ended up in the situation where our code has degraded into something ugly, unperformant or useless (aliteration unintentional). Sometimes it's out of our hands, e.g. when a client decides that yesterday's critical feature is no longer on their agenda, leaving redundant code littered through our project. Sometimes it's preventable, like when we gradually add tiny bits of code without refactoring to adopt it, or without introducing new tests. However it happens, it's an inevitabilty that we need to accept. In fact, rescuing projects from these situations help us learn and grow as developers.