When you join a new company, how do you familiarize yourself with the code base and the architecture?

Question 528 9 Jan 2017

Write answer

  • Sort By :
  • Popular
  • Recent

This answer has received 1 appreciation.

Ah, what a perfect opportunity for me to answer this, having started a new job just a week back.

The best way is obviously to dive in to code. Pick out a part of the application that you think you understand the most and trace the code by inserting logs (or breakpoints) to get a grip of the coding pattern. Then, build a similar feature or a solve a bug in the part of the code that you understood. Once your first PR gets merged, you will be touching all parts of the code very very soon.

Happy coding! I am still in the process of shipping out my first feature, I'll keep you posted on how it works out for me. :)

This answer has received 1 appreciation.

  1. Checking readme.md
  2. If there are no readme or no useful info about the architecture/tech stack/etc - read diagrams
  3. If there are no diagrams - check docs/wiki
  4. If there are no docs/wiki - figure out which framework it uses (usually at least this info you can get by asking a simple question) and read it docs if needed
  5. If there is another custom framework or even 2 custom frameworks and 2 custom ORMs in the same codebase (I really have seen such 10years old project) - plan your exit strategy (how/when you will leave team/company and give that s-y codebase to someone else with a maximum profit to yourself)
  6. If you have no choice - find a place where you wouldn't be able to hurt anyone, play relaxing music and read the codebase folder by folder like a Bible and may the dark side be with you.

P.S. in your own life you always have a choice and an option to find a better place.

@danfromisrael this is exactly how you should work on any project. If there is no documentation, start writing at least small notes to yourself. At the end make sure your team contributes and everyone uses it. Problem, however, is that in a typical business you won't have much time for writing good documentation. managers consider it as a time and money waste for company.

At the end when you can choose and your time become expensive you can find a better place/project.

I usually dive right in. I'd ask for specific bugs I could go hunt down and fix. This is the first step (at least for me it is) in figuring out what is going on in the codel

Sometimes I open up a new text file and write down the execution path (who calls what and who constructs what) in pseudo-code. This is especially useful if the code is too difficult to follow or has too much stuff going on.

  • Try to find out what the code is supposed to do.
  • No matter how bad is the documentation will go through all them if exists.
  • Talk to anyone who might know something about the code.
  • Step through the code in the debugger.
  • Introduce small changes and see what breaks.

Ideally you'd start by looking at the tests!

If they don't have tests, then write some. Testing code is a great way to understand it.

After that I like to start with any small bugs or features, and work my way up from there.

Thats a great idea! Actually this should be every new developer first task! That way you'll have more tests as you hire along the way 😊

As @BigMonty suggested, dive in. Try to fix bugs and try to understand the workflow of application and try to figure various design patterns they used while debugging. Myself working on a Core Java support project for more than 3 years, To be frank I'm still learn a lot from my application.

Make little issues, self investigate and asking to your mates :)

Jump in, try and build something small. Fixing bugs is relatively small and easy to do quickly, but by making something using parts of whats already built gives you the best opportunity to ask questions and learn. Go to others when building and say, "hey so do you have a way already in the system to find/call/replace/update..." and then they can tell you about that small part that will help you create your new feature. One piece at a time.

I had a disorganized and frantic experience trying to familiarize myself with a codebase at a company mostly because there were several variations of it and no one was able or willing to explain it to me.

My answer to your question is that a "process" is highly contingent on the organization you're a part of.

I ask someone to draw me a diagram of higher-level architecture as an intro to know what is communicating with what. Then I dive into the code and I start understanding it in one part of the application - you can go and fix easy bugs as proposed. Once you have basic under of one part of the app, you can proceed to next part while looking back at the higher architecture.

This should not be your responsibility. The company should train you a couple of days or something. (even if you are not a newbie)

of course I agree with The best way is obviously to dive in to code. read, try to work doing code review with your partners or your boss, and ask for code standards, IDE configurations and IDE preferences :)

  1. read the readme
  2. find out what the usual dev environment setup process is and follow it
  3. update whatever documentation was out of date in the previous steps ;) no really, there's always something and the noob is the one who will find it. This is part of the assignment we give all new starters - be our "fresh eyes".
  4. check out the source and have a look through the raw code - is it tidy? is it logical? is it monolithic or broken up? how easy is it to understand?
  5. pick up some bugs or do a bugfix rotation - this will push you into a random grab bag of code that isn't working but is important enough to have been scheduled.

Since I'm a frontend dev I'll also do an in-browser evaluation of the code, run some validation checks, performance checks, etc. That's probably not what you're getting at though.

Read documentation. Create small tasks to try to use the architecture. Debug the architecture. The important thing is to maintain good communication with the team of developers.

Never miss an interesting discussion,
when you sign up for Hashnode. Learn more

loading ...