I've been tasked with a solo project to investigate & resolve memory leaks in 8000 lines of Javascript code.

I anticipate the project to take up to a month.

Please recommend a development methodology I can use to structure my efforts.

Prefer something light & easy to pickup and run with.


  • 1
    Whatever methodology you choose, design it first and don't rush to code.
    – NoChance
    Sep 11, 2011 at 23:49
  • 3
    Is start early, drink coffee, ask questions on SO, and be healthy a "development methodology" ? If so , yeah ! Sep 12, 2011 at 2:04

3 Answers 3


Typically, a development methodology is designed to manage a software project over its life cycle, from inception to end-of-life. What you have been assigned to do sounds more like a task rather than a software development project. It's a large task that needs to be broken down, but it's nothing that needs a formal development methodology. Instead, you should be working within the process defined for use in the project that this task is related to.

I would start with just a very simple, methodical series of steps:

  1. Learn the system. Ask for requirements specifications, design documents, and any other relevant documents associated with this code base. Review them, along with the code. If anything is out-of-date, I would inquire about updating the documentation, since it would be of use to future developers.
  2. Read the code and associated tests. Once you've read the documents, read the code. Note discrepancies between the documents and the code. If anything is incorrect, file defects as appropriate. Restrain yourself here - don't jump in and start fixing things without following the project-level process. If there are no tests or test cases are missing, this is a good time to create them, especially if your work will involve refactoring.
  3. Execute the test cases. If any tests fail, file defect reports as appropriate.
  4. Instrument and profile the code. I'm not familiar with JavaScript development tools, but try to profiling the executing code and find out where the memory leaks are and if certain conditions trigger them. It might also be good to just create a general performance profile of the code base to determine where the least efficient code is. Even if you aren't tasked with fixing it, you have the tools you need to find it, so document them to save time for future developers.
  5. Prioritize the defects. This includes the memory leaks. Hopefully, you have more information about them by "there's a memory leak" at this point, so there should be a number of defects related to these problems. If there are any defects in the modules with memory leaks, fix those first. You want to make performance enhancements to code that otherwise passes tests.
  6. Begin fixing the defects, starting with those with the highest priority. Be sure to run your tests (automated and manual) to ensure that the system hasn't become unstable.
  7. Ask questions. Never take anything for granted. If you have access to the previous developers, take advantage of them when they have the time. Otherwise, consult documentation and Stack Overflow as appropriate. Make sure that you have a good understanding of how the system is behaving, why it is behaving that way, and convey that information to future developers through various forms of documentation.

Throughout this task, be sure that you use version control to keep track of changes. Good versioning and commit logs will help you keep track of what changes you have made and when you made them. Tracking time and tasks completed will help you improve your estimates as well as keep the managers or supervisors in-the-loop as to the current status of the project.


Best idea on a legacy code base like that is to "Divide and Conquer", by dividing the problem into smaller functional units, especially if it's not already structured well. This may involve some refactoring so that the code is more manageable, so look for seams where you might break it into smaller functions.

Some of this is covered in the excellent book Working Effectively with Legacy Code.

Another point is that if there aren't already any tests is to put in some unit tests to prevent from breaking things when refactoring so be sure to look for ways to test the code. There is a framework for unit tests called QUnit that can help with testing Javascript.


I'm guessing you don't really have time to read a book on working with legacy code, so here's my two cents (having read Working Effectively with Legacy Code) and having been in a similar position many times (I work for a Fortune 100 company, and periodically large companies have these HUGE project failures which cause them to reconsider investing in old legacy systems, so you end up with huge refactoring projects you hadn't planned to do).

  1. Do SOMETHING. Don't analyze the crap out of what you're planning to do. The very fact that you asked about a methodology might indicate that you have a psychological tendency to do this. Don't. 80% of getting it done right is getting it done -- especially on a small gig like a one month task.
  2. Spend a short amount of time (less than 5% of your total time budget as a rule of thumb) figuring out where you'd like to be at the end. What does success look like?
  3. Am I working on the right problem? Are you literally just trying to find a memory leak? If so, why are we talking about these 8000 lines of code? There are a limited number of ways to create memory leaks in JS (like circular references), so let's put first-things-first as they say, and make sure this issue is framed up right.
  4. Are you working alone, or with a team? If you're working with a team, have you figured out how to carve up the work among yourselves? If not, this will be an exercise in frustration -- get that figured out early, or at least figure out how you're going to decide as the time clicks away.
  5. Analysis/Development. Once you've got the 4 items above figured out, you're going to have to do the hard work of doing deep analysis -- seeking to understand what the code is doing. Once you figure out how something is working, codify that understanding by using a divide-and-conquer approach. That is to say, rewrite some subset of the code "the right way", and replace all references to the old code to the new code in the least intrusive way possible (which often means you have to pick some arbitrary point to "stop pulling the yarn out of the sweater"). You end up with a "clean room" version of the code on one side -- good, known, fully unit tested code (Jasmine is good for unit testing JS by the way), and legacy code on the other side -- untested, unknown quality code that you're trying to slowly replace.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.