5 tips on how to read someone else’s code.

Hello fellow coder , thanks for investing few minutes in reading this post ({hopefully} you will not be disappointed). 🙏

So, recently I was handed over an existing codebase (again), to start scripting automation test cases for a project. Now this situation happens quite often to software engineers and developers and testers and others. Wherein they are handed over the legacy code and are expected to provide deliverables on a (tight) timeline.

In my case, it was a vanilla JAVA project , but similar approach could be applied to others as well.

Here’s how I cracked the code in 5 easy breezy steps :

1. Talk to people: Time to use your networking superpowers. Talk to people you know, talk to people you don’t know and then do some more talking. Its always better to get a code walkthrough rather than spend coffee infused all nighters reading through abstract classes which inherit some other classes. (personal experience). Do you know the guy in your company who has coded pieces on the base? (Go talk to him). Not a friend ? (Still go talk to him). Not in your company ? Find out if he is reachable then go talk to him.

2. Understand the 10,000 feet view: Look at the packages, classes, method names at the high level. Ideally, the code should be self-explanatory. (Satirical joke). We live in a realistic world where people add code descriptions like twitter updates. On my latest project, the README file said “Test Automation Project”. No thats not just the header, its all of it. Nothing more , nothing less. (Take that for minimalism). Anyways, for JAVA code, you cannot read/execute/understand it sequentially. For example, when I started coding with BASIC, you can go line by line and understand what it is doing :

HELLO WORLD in BASIC
10PRINT"Hello World!"20GOTO10

Not the same case with JAVA :) (you know what I mean):

publicclassHelloWorld {

    publicstaticvoidmain(String[] args) {
        // Prints "Hello, World" to the terminal window.
        System.out.println("Hello, World");
    }

}

You get the point, understand what is being extended and what is being implemented (pun intended). In test automation, we would look for things like locators/test data/initialization or which class launches webdriver. Stay clear of nitty gritty details at this step. You need not spend exuberant amounts of time understanding how the clean up is working right away.

3. Get visual: Put your artist hat on and draw stuff digitally or on ol’ pen and paper.There are free tools which help you draw diagrams (UMLs anyone?) or ER schemas and visualize stuff easily. This will help you in the long run (Guaranteed!)

4. Time to RUN: By this time, I am assuming you have set up the code base on your local (atleast downloaded and imported to an IDE). See if you can run the code/fire unit tests.Logs would/should help you understand the flow. If someone writes code that is perfectly executable, but no other engineer can read it, then it’s bad code. Also, start small and test stuff. Take help from peers or online peers (looking at you Stackoverflow) and check your knowledge.

5. Judgemental can lead to mental: Dont judge the existing code right away. You never know what circumstances lead to the existing code base. You could fret all night on “Why the hell did they write 1 method for 10 things?” or “Why the hell did they write 10 method for 1 thing?”. As humans, we try to judge stuff in the shortest span possible. Try being the superhuman, who can resist the urge to judge, read through lines of code, and sometimes in between and then read/understand some more.

Well these are the few things Ive tried recently, what do you do when you are hit with legacy code? Do you run, do you fight or do you pull an all nighter?

Let me know in the comments below. ✍