How to Improve a Legacy Codebase
I agree with everything said, but I think they assumed a well-maintained and highly functionality legacy codebase.  In my experience, there are a few steps before any of those.<p>---<p>1. Find out which functionality is still used and which functionality is critical<p>Management will always say &quot;all of it&quot;.  The problem is that what they&#x27;re aware of is usually the tip of the iceberg in terms of what functionality is supported. In most large legacy codebases, you&#x27;ll have major sections of the application that have sat unused or disabled for a couple of decades.  Find out what users and management actually think the application does and why they&#x27;re looking to resurrect it.  The key is to make sure you know what is business critical functionality vs &quot;nice to have&quot;.  That may happen to be the portions of the application that are currently deliberately disabled.<p>Next, figure out who the users are.  Are there any? Do you have any way to tell?  If not, if it&#x27;s an internal application, find someone who used it in the past. It&#x27;s often illuminating to find out what people are actually using the application for.  It may not be the application&#x27;s original&#x2F;primary purpose.<p>---<p>2. Is the project under version control? If not, get something in place before you change anything.<p>This one is obvious, but you&#x27;d be surprised how often it comes up.  Particularly at large, non-tech companies, it&#x27;s common for developers to not use version control. I&#x27;ve inherited multi-million line code bases that did not use version control at all.  I know of several others in the wild at big corporations.  Hopefully you&#x27;ll never run into these, but if we&#x27;re talking about legacy systems, it&#x27;s important to take a step back.<p>One other note: If it&#x27;s under any version control at all, resist the urge to change what it&#x27;s under.  CVS is rudimentary, but it&#x27;s functional. SVN is a lot nicer than people think it is.  Hold off on moving things to git&#x2F;whatever just because you&#x27;re more comfortable with it.  Whatever history is there is valuable, and you invariably lose more than you think you will when migrating to a new version control system. (This isn&#x27;t to say don&#x27;t move, it&#x27;s just to say put that off until you know the history of the codebase in more detail.)<p>---<p>3. Is there a clear build and deployment process?  If not, set one up.<p>Once again, hopefully this isn&#x27;t an issue.<p>I&#x27;ve seen large projects that did not have a unified build system, just a scattered mix of shell scripts and isolated makefiles.  If there&#x27;s no way to build the entire project, it&#x27;s an immediate pain point.  If that&#x27;s the case, focus on the build system first, before touching the rest of the codebase.  Even for a project which excellent processes in place, reviewing the build system in detail is not a bad way to start learning the overall architecture of the system.<p>More commonly, deployment is a cumbersome process.  Sometimes cumbersome deployment may be an organizational issue, and not something that has a technical solution.  In that case, make sure you have a painless way to deploy to an isolated development environment of some sort.  Make sure you can run things in a sandboxed environment.  If there are organizational issues around deploying to a development setup, those are battles you need to fight immediately.