How to enter an unknown terrain of code

Writing every single line of code grounds up in every project you work on is reductio ad absurdum. Often times we need to look at and understand code written by our team members or some employees who no longer work on that project.

So if you are new to a project, here is what you could do before you ask one of your colleagues for assistance and try to increase your skills to debug existing code.

Read Product documentation

This is mostly the best place to start because this is where your customers start. For you to know a feature from end to end, this should give references or content that your customers actually go through to setup or use the feature. If you don't find this, just imagine how a customer who doesn't even have access to the code would be using the feature!

‍

Try the feature in a lower environment

After you read up the documentation and you have some context, always try the feature yourself in a test account in one of the lower environments (something that’s your Continuous Integration environment). This will always give you the ability to be comfortable with some network calls and also with some interactions happening from the client which can help you kick start looking at code.

Go through the Technical Documentation

Every project ought to have some technical design document or some form of documentation for the feature that you are about to venture into. Going through the technical documentation will give you an idea of why a particular feature is developed in a particular way. It might answer some questions like `What were the design drivers, considerations, challenges?`, `What’s still to-be-done for the project?

Endpoint Identification

This section is only applicable if your application has HTTP (RESTful, GraphQL, SOAP, or such) Endpoints, Asynchronous Messaging Endpoint, Scheduler-based Endpoint, etc exposed that the client invokes to achieve a business functionality. Once you have the endpoint, you have to look for the endpoint pattern in the codebase of your application gateway (if you have a multi-tiered application) or the codebase of the microservices.

Unit test cases

This may seem weird to a few people, but unit test cases, if well written, can easily act as a guide to understand the business functionality and the output of a specific core business functionality for a given set of inputs 

Specifically, as you write code and if you are debugging your application, always try to ensure that you have the call stack and its arguments written at each level. This gives an idea of which stack was invoked with what values to arguments. And NEVER PRESUME ANYTHING. One should make no presumptions around the code and start debugging every stack and every code within a method.

For example, let’s take a sample code where you are trying to start a group call with a participant where you first validate if a group call already exists with the participant, if not fetch the participant detail and then start group call.

‍

public GroupCallDTO startGroupCall(GroupCallRequest request) {

final GroupCall groupCall = getExistingGroupRequest(request.getRequestId());

if (groupCall != null && groupCall.alreadyExists()) {

      log.error("Group call already exists for request: {}", request.getRequestId());

   throw new GroupCallExistsException("Group call already exists");

}

final Optional<CallParticipant> optionalParticipant =

        getParticipantDetails(request.getParticipantId());

if (!optionalParticipant.isPresent()) {

      log.error("Participant: {} does not exist", request.getParticipantId);

   throw new ParticipantException("Participant does not exist");

}

final CallParticipant participant = optionalParticipant.get();

final GroupCall groupCall = groupCallService.startGroupCall(participant);

return convertToDTO(groupCall);

}

‍

The code is a core logic and you would've gone through a lot of cases to understand each step. But what truly helps is something like

So always try to break the methods into smaller logical chunks based on the business workflow. Always understanding code based on business use-case mapping is easier.

Also read: Declarative programming