Working with an Unknown codebase

Understand architecture

• what is a client? Is it a desktop, mobile app or both? Maybe there’s only a web app, but used on different devices?

• what is a server? Is it a single instance or some distributed service? Where does it run?

• how do the client and the server communicate? Is there any framework used (e.g. WCF) or maybe just some RESTful web service communication?

• are there any architectural design patterns used by the team in both clients and server apps (e.g. Layered Pattern, MVC, MVVM, CQRS…)?

• what are the important frameworks/libraries used in the clients and server apps? By important I mean these ones which directly define the style of coding, for instance: ASP.NET MVC, WPF, Caliburn.Micro, Prism, Spring, Angular, React, TypeScript etc.

Learn the persistence

First of all, find out what kind of database is used by the software. Then check how the applications (clients, server) communicate with the database. In other words: find out in which place the queries are sent to the database.

Next, find out how is the persistent data (e.g. tables) represented in code. Where are the persistent classes defined? How are database restrictions (not-null fields, primary and foreign keys, constraints, data types) defined on them? How are the objects’ fields mapped to database tables’ columns?

Learn to deploy your system

Compile the whole code and learn how to run it all (server and all clients). If possible, start with a clean database as a new customer would. If the process is complex write down the step-by-step instructions while your colleague explains the process to you. It’s very important that you practice it yourself and finally are able to go through this “deployment” process even without your notes.

Know the system functionally

As soon as the whole system is running, spend some time clicking through the application. Try to grasp how it works, what’s the feeling of the system.

If possible, find someone who has functional knowledge about the software – preferably a consultant or customers’ trainer – and ask him/her for a live demo.

The better you understand the problem domain, the better your technical decisions are going to be. Such a perspective helps you think differently when you’re asked to implement a feature that initially sounds like nonsense.

Explore source code tests

As soon as you’re starting to work on some task you may have the feeling that you completely have no idea how the related part of the software works. If that’s the case, try to look for tests (unit, integration tests) in the code related to this feature.

Have software documentation around

If there’s any documentation for your new software – have it somewhere around. Don’t read it – except, again, if it’s veeeeery good and interesting (anyone has ever seen such docs?! ). Just keep it in case you need to find out how something works.

Document your actions

When I work with an unknown codebase I tend to keep track of what I’m doing. It can also be a new Notepad file, a new tab in Sublime Text or just a piece of paper. In such a place I write down what I’m currently working on. If I have some exception’s stacktrace I’m trying to analyze – I paste it there. I write down some objects and try to picture the relations between them.

Debug

When working with an unknown codebase I find it helpful to break through the application’s startup. Put a few breakpoints in one of the application’s entry methods and debug how it launches and initializes line-by-line.

It will help you to see what components are used and how are these loaded. It will let you understand how the codebase is built and what the developer exactly intended to do with this button.

Search literally

When working with an unknown codebase I very often search for things literally. For instance, when working on an issue occurring on pressing a button it may not be easy to find the code-behind the button (a method which executes as soon as you click it). In such a case, I just copy the text which is a button’s text or name and search by it literally in the whole codebase.

If you don’t have any GUI element with text to search for, try to search by intuition.

Don’t be afraid to ask

Not asking is a common issue, especially amongst experienced developers. Programmers are often afraid of asking questions. New guys in a team tend to think that it would be a shame to ask someone for such easy stuff… But hey, you’re new in the team and it’s perfectly fine to ask for anything that comes to your mind!

I’d say even more – by asking questions you show your engagement and a will to really understand what you’re doing. Sometimes digging into an issue ourselves can be much longer than doing it with a little bit of help from the project’s seniors. So by asking them to aim you in the right direction you’re also saving yours and your company’s time

When working as a team leader I preferred to have people in my team who asked questions to silent on-my-own geeks. Of course, you should first try to find the solution yourself, e.g. using one of the tips described above However it’s always better to ask and get the answer or be aimed in the right direction in 5 minutes than spending the whole day fighting with the problem. It would also make your day much better