How I Approach New Codebases
Tags: thoughts, codenewbie
Published: 2021-02-10 20:04:33

After having various jobs with differing levels of established codebases, looking a numerous open source repositories and reviewing technical tests I've never really noticed how I go about trying to familiarise myself with new codebases.

I saw a tweet the other day which made me think. 

{% twitter 1354696503617490945 %}

Until the tweet made me stop and think about my processes I'd never really thought about how I approach new codebases I just had. Below are my thoughts.

As a .NET Developer they all have a .NET/C# angle to them but the general rules for different languages and technologies still apply I think. This is more of a brain dump so the order of sections may not flow or follow each other.

* ASPNET Core / .NET 5.0 - Startup.cs
    * Look at how dependencies are registered
    * How are they registered?
    * How are services spread out?
    * Are they split by namespace and/or project?


* ASPNET Core / .NET 5.0 - Controllers
    * Where are the controllers?
    * What actions are on the controllers?
    * How are they expected to be called?
    * Can I call one with Postman or a browser?


* ASPNET Core / .NET 5.0 - UI
    * What type of UI is used in the application?
    * Client side / server side?


* Configuration - web.config / appsettings.json
    * Does it need a connection string?
    * Where does that connection string go?
    * Does it point to a local db instance?
    * How do I get a local db installed?
    * What other settings are in the file which may relate to what I'm doing?


* Authentication
    * Can I log in?
    * How do I log in?
    * What mechanism does the application use for logging in a user?


* Authorisation
    * How can I do something?
    * What mechanism does the system use to control what I can do?


* Running the application
    * How can I run the application?
    * Does it build and run with f5 from Visual Studio?


* Business Logic Services
    * Can I find the source code for the business logic?
    * Do the services have unit tests?
    * What do the unit tests do?
    * Are the unit tests well constructed?
    * Can I understand what the unit tests are trying to test?
    * Does the name of the unit test make sense?
    * Can I debug through a unit test to see what a service does?
    * Are there any integration tests?
    

* Exercising the code
    * Can I put a break point in a service and exercise that part of code from the UI?
    * Is the naming of the service clear?
    * Does the name relate to the part of the system you think it does?

The last point about trying to exercise the code usually happens when you are presented with a codebase and there is a lot of complexity. The codebase may have been around for a number of years, had a lot of functionality added but also a lot of churn in the code. It may have some convention over configuration which isn't obvious on first looking. Anything is possible.

The above works for me but you may have a different way of approaching different codebases. There is no wrong or right way and I'm always looking to learn different techniques. I'd be interested in hearing your thoughts, let me know on Twitter [@WestDiscGolf][WestDiscGolfTwitterLink].


[WestDiscGolfTwitterLink]: https://twitter.com/westdiscgolf