I've been asked to evaluate what appears to be a substantial legacy codebase, as a precursor to taking a contract maintaining that codebase.This isn't the first time I've been in this situation. In the present instance, the code is for a reasonably high-profile and fairly high-load multiplayer gaming site, supporting at least several thousand players online at once. As many such sites are, this one is a mix of front- and back-end technologies.The site structure as seen from the inside out, is a mess. There are folders suffixed _OLD and _DELETE lying all over the place. Many of the folders appear to serve no purpose, or have very cryptic names. There could be any number of old, unused scripts lying around even in legitimate-looking folders. Not only that, but there are undoubtedly many defunct code sections even in otherwise-operational scripts (a far less pressing concern).This is a handover from the incumbent maintainers, back to the original developers/maintainers of the site. As is understandably typical in these sorts of scenarios, the incumbent wants nothing to do with the handover other than what is contractually and legally required of them to push it off to the newly-elected maintainer. So extracting information on the existing site structure out of the incumbent is simply out of the question.The only approach that comes to mind to get into the codebase is to start at the site root and slowly but surely navigate through linked scripts... and there are likely hundreds in use, and hundreds more that are not. Given that a substantial portion of the site is in Flash, this is even less straightforward since, particularly in older Flash applications, links to other scripts may be embedded in binaries (.FLAs) rather than in text files (.AS/ActionScript).So I am wondering if anyone has better suggestions as to how to approach evaluating the codebase as a whole for maintainability. It would be wonderful if there were some way to look at a graph of access frequency to files on the webserver's OS (to which I have access), as this might offer some insight into which files are most critical, even though it wouldn't be able to eliminate those files that are never used (since some files could be used just once a year).
In a legacy codebase, how do I quickly find out what is being used and what isn't?
freelancing;tools;websites;source code;flash
Since what you're being asked to do is provide input for your client to write an appropriate proposal to the other client (owner-of-the-nightmare-code) for any work on that code, I'm going to go out on a limb and say that you're not going to be doing any thorough testing or refactoring or anything along those lines at this point. You probably have a very short time to get a rough estimate. My answer is based on my experience in the same situation, and so if my interpretation is incorrect, just disregard everything that follows.Use a spidering tool to get a sense of what pages are there, andwhat is inbound.  Even a basic linkchecker tool -- not a specificspider for auditing purposes tool -- will be useful in this regard.Make a basic audit/inventory spreadsheet. This could be as simple asa list of files and their last-modified time, organized by directory.This will help you get a sense of scope, and when you get todirectories like _OLD and _DELETE you can make a big note that a)your evaluation is based on stuff not in those directories b) thepresence of those directories and the potential for cruft/hiddennightmares attests to deeper issues that should be accounted for inyour client's bid, in some way. You don't have to spend a gazillionyears enumerating the possible issues in _OLD or _DELETE; the infowill feed into the eventual bid.Given you are reviewing what sounds like an entirely web-based app,even standard log analyzer tools are going to be your friend.  Youwill be able to add to the spreadsheet some sense of this is in thetop 10 of accessed scripts or some such.  Even if the scripts areembedded in Flash files and therefore not spiderable, there's a highprobability they are accessed via POST or GET, and will show up inthe server logs.  If you know you have 10 highly accessed scripts,not 100 (or vice versa), this will give you a good idea of howmaintenance work will likely go.Even in a complicated site, what I outlined above is something you could do in a day or day and a half.  Since the answer you're going to give to your client is something like this is going to be a tremendous pain in the butt, and here are some reasons why you'll just be putting lipstick on a pig, so you should bid accordingly or any reasonable person would bid not to maintain but to start over, so you should bid accordingly or even this isn't that bad, but it will be a consistent stream of work over any given timeframe, so bid accordingly, the point is that they're going to be making the bid and thus you do not need to be as precise as you would be if you were being hired directly to do a full content and architecture audit.