When looking at a new codebase, the first thing I look out for is the docs for getting set up. If none exists, I ping the contact person to find out how to get set up. It’s important to always document what worked/didn’t work for me while getting setup because sometimes, even on a repo with documentation, the original developer(s) may have missed documenting a key component because they were writing the doc with loads of context and local libraries/packages that a developer new to the codebase might not have. Setting up can sometimes take forever, this is one of the reasons why I appreciate the concept of automating your development environment for a codebase as it gets complex beyond a simple Rails app setup.
When I’m done setting up, I’ll update the readme with how I got set up so it’s easier for the next developer. Updating the readme is good practice, but I sometimes forget to do this.
Once my development environment is set up to run the code, I’ll run the tests. If all is well on my development and test environment, I like digging in to figure out what the major user journeys/flows for the application are. I will schedule a video call with the client to figure this out if they aren’t obvious from navigating around. Knowing these helps me in 2 ways:
This helps me quickly get my local environment to match production as close as possible from CRUD-ing/manipulating items on the app (an added benefit is I get to catch as many bugs as I can from using the app as a real user would).
It also helps me to compartmentalize the models, relationships, controllers, views, services, etc and how things fit together in my mind which is super important for me. I take lots of notes at this stage.
If there’s a backlog, my preferred next step is usually to pick a teeny-weeny task and get that done just to dive in and get my feet wet.
This post first appeared in a writing series with my colleagues at Happy Bear Software.
Read more about how we get productive on a Ruby on Rails codebase