Suppose, you were given a project source code of an Android app, a pretty BIG sized app. You don't know anything about the code unless you read line by line. Now you were given a deadline to fix some bugs, but you don't know where to start or where to put breakpoints to debug. In that case, how would you do it? How would you debug the code?

  • 5
    I’m assuming files, classes, variables etc have sensible names? Search for keywords that could point you to relevant sections of code and start looking for places where the bug might originate from. Slap in a few breakpoints and go from there. You’ll find the bug in no time.
  • 2
    There is a book written for such cases - "working effectively with legacy code" by Michael Feathers. I do recommend this one for legacy and large codebases. In essence, it shows many practices with covering legacy projects with tests and then refactoring it properly.
  • 1
    @100110111 Nope. They don't. That's one of the biggest problems actually.
  • 0
    @puradawid the problem is that, the project is way worse to be called "LEGACY". Legacy codes do have certain standards, this project code doesn't have that.

    on top of that, Pretty sure 3 or 4 devs worked on it, and everyone worked on their own style.

    and there's public static variables everywhere. its like, "everything is connected to everything" :/
  • 2
    @Xoka just... run?
  • 2
    Don't worry about missing deadlines, it's normal when working on legacy products. If there is any documentation, read on it.
  • 2
    Organize some calls with the old devs, this should get you a better understanding of what's going on behind the hood and buy you some time too, which isn't gonna hurt.
  • 1
    That sucks pretty much. If you know at least when the specific bugs arise (in the manner of, [how / which component] should the user interact with to induce the bug), you should probably start with the methods tied to that specific component in the app.
  • 2
    If bug can be seen from UI, you can start with layout inspector to quickly find related views, and go from there.
  • 4
    Run the app, reproduce the problem.
    Skim the app file list, pick something that looks relevant, read and understand.
    Repeat until you find something that is hard to read. That's probably where the problem is...
  • 2
    If everything is hard to read, the devs are the problem.

    But start small. One class or function small.
  • 2
    code smells, the refactoring book and I think there's a talk on it
  • 1
    Thanks everyone for your kindest words and great advises. I really appreciate.

    I actually started cleaning up the code class by class since yesterday. Clean code feels awesome ^_^
Add Comment