DEV Community

loading...

What are some good questions to ask when you're inheriting a codebase?

leirasanchez profile image Leira Sánchez ・1 min read

When you are getting a project assigned that has a considerable codebase already, what are some good questions to ask to help you hit the ground running?

Discussion (17)

pic
Editor guide
Collapse
roelofjanelsinga profile image
Roelof Jan Elsinga

Things such as:

  • What are the steps I need to take to get this running on my machine?
  • What does the deployment strategy look like? (PR for new features/fixes, Commit styles, build steps)
  • What is the role of testing in this project?
  • Where do you keep track of issues?
  • Do you have a code style guide? (code rules)

Just some stuff to quickly write code in the same way as the current maintainers.

Collapse
ben profile image
Ben Halpern

Depending on the documentation situation, "who worked on this the most, who is the person to contact about this?"

And as you do contact that person, it's always a great chance to make the documentation at that point as you go, rather than continue the informal oral history.

Collapse
leirasanchez profile image
Leira Sánchez Author

This is great advice. Adding to the docs while gathering info is something I did in my main project and has been helpful when new teammates join. They have it easier :P

Collapse
ben profile image
Ben Halpern

IMO in terms of making the best impression when joining a new project: Docs are a huge one. I think people always wish they had better docs, and when new folks come in and show they have the discipline to contribute in this area it goes a long way in building trust.

Collapse
daviddalbusco profile image
David Dal Busco • Edited

"Could we solve a couple of bugs together first?"

I recently landed in a new client's project. Solving a couple of issues together with the team (pair programming) eased my integration and my understanding of the reasonable codebase size.

That being said, one of the task assigned to me is also rewriting one module from scratch 😉

Collapse
cjbrooks12 profile image
Casey Brooks

One of the helpful questions isn't really a technical one, but "who is my user?". It's important to get a "profile" of who the user of the application is, how they use the app, how they move between screens, how data is structured, and how data flows through the app. The way code is written is usually to fulfill those exact needs, so it's really hard to understand the code at a macro level if you don't understand the user. And knowing the macro level is essential for adding new features, refactoring, and fixing many kinds of bugs.

Collapse
barelyhuman profile image
Reaper
  • Setup
  • Credential Management
  • Code Flow
  • Target Use Case

Setup

I would normally recommend someone creating a repo to have all the steps required to setup that repo mentioned in the README but since not everyone does that, as someone who's been handed the project the next step would be to let the person guide you during the setup and while doing that any technology that's being uses can be used as a query to figure out why it's being used. If the person points out that it was a decision taken by someone else, make sure you get the answer to the "Why" from them later.

Credential Management

The next important part is how are the configs and database credentials (if any) being managed both in the local setup and in the production environment so you know what to keep in mind while messing with the credentials.
Some people have 2-3 different environment based files so it's a easy to know that changing the local configs shouldn't have an impact on the app that's on the staging servers even if you do deploy it

Code Flow

Now this one depends from project to project but the idea remains same, asking for the code standards / linters /code style to be followed for the project and also it's kinda important to know how the application flows.
For ex. a webserver, assuming a nodejs server starts off in the server.js file, figuring out how the plugins and routes and models are getting injected into the application, if not, are they just importing each route manually and using them. These can differ from company to company project to project based on how the company develops it's processes but it's always good to know what part of the code controls what.

Knowing :

  • where the scheduled jobs are stored.
  • where the binary scripts are being handled
  • what significance does each folder hold etc.

Target Use Case

I'm pretty sure you are already told what you are going to be working on and what that codebase's intent is but in case it isn't, you gotta find out why you are building it and what problem does it solve

Collapse
ionline247 profile image
Matthew Bramer

"Has this been deployed to production?"

After working on an app that was projected for 6 mos. of dev and is now pushing ~3 years of development w/o being in production, it's now a question on my checklist. This is a greenfield project, jsyk.

Collapse
leirasanchez profile image
Collapse
jrohatiner profile image
Judith

Definitely first: how do I set this project up on my local? Also good to ask: Are there docs on the project architecture? IMHO it’s really important to know how everything is put together from the get go.

Collapse
hoffmann profile image
Peter Hoffmann

What the funk did you do there??

Collapse
jizavala profile image
jizavala

best comment ever

Collapse
ledestin profile image
Dmitry Maksyoma

Whether you can rely on front-end tests. You can look up unit test coverage with tools, but not so with front-end tests.

Collapse
jizavala profile image
jizavala

Can we pretend that the git repo or svn server just fly away and make it again this time the right way? :v