As a developer, becoming a member of a brand new challenge or firm is commonly a frightening and scary activity. You must get aquatinted with not only a entire new crew of individuals, however you additionally should familiarize your self with a wholly new codebase which may use new naming conventions, follows patterns that you just’re not conversant in, and even makes use of tooling that you just’ve by no means seen earlier than.
There are many causes to be overwhelmed once you’re a brand new member of any engineering crew, and there’s no motive to really feel dangerous about that.
Up to now two years, I’ve finished plenty of contracting and consulting which implies that I’ve needed to discover and perceive numerous codebases briefly quantities of time. Generally even having to discover a number of codebases without delay at any time when I’d begin to work for a couple of consumer in a given week or two.
I suppose it is truthful to say that I’ve had my justifiable share of confusion and feeling overwhelmed with new codebases.
On this publish, I’d prefer to offer you some ideas and methods that I take advantage of to get myself snug with codebases of any dimension in an affordable period of time.
Meet the crew
Whereas it is likely to be tempting to get by way of your introductory calls as quickly as doable so you possibly can spend as a lot time as doable on navigating and exploring a brand new codebase, I extremely advocate letting the code watch for a short time. Meet the crew first.
Attending to know the folks that wrote the code that you just’re working with can really assist to construct a greater understanding of the codebase as an entire. Ask questions on crew dynamics, and ongoing tasks, who’s an professional on what? Constructing empathy across the code you’ll be working with is a really precious device.
Realizing which crew members know most about particular options, components of the codebase, instruments which are utilized in an organization, and so forth additionally helps you determine the appropriate particular person to ask any questions you may need when you discover the codebase.
For instance, once I joined Disney virtually six years in the past I wasn’t all that conversant in Swiftlint. I had heard about it however I had no concept what it did precisely. Within the codebase, I noticed some feedback that regarded as follows:
// swiftlint:disable:subsequent cyclomatic_complexityIn fact, I might paste this remark into Google and go down a rabbit gap on what’s occurring and I’d most likely have realized loads about Swiftlint however as a substitute, I selected to determine who is aware of most about Swiftlint throughout the crew. Certainly that particular person might assist me be taught loads about what Swiftlint was used for and the way it works.
I requested my crew lead and by chance it was my crew lead that really knew heaps and plenty of issues about Swiftlint, the way it was arrange, which linter guidelines we used, and so forth.
We had a great chat and by the top of it, I knew precisely why we had Swiftlint at Disney Streaming, which guidelines we had disabled or enabled and why, and why it was okay to disable sure guidelines generally.
Google might have taught me that the remark you noticed earlier disabled a particular linter rule to permit one exception to the rule.
My coworker taught me not simply what that remark did but additionally why it did that. And why that was okay. And once I ought to or shouldn’t disable sure linter guidelines myself.
One other instance is a more moderen one.
Considered one of my purchasers had a fairly large codebase that has had many individuals engaged on it over time. There’s some Goal-C in there, numerous Swift, it has UIKit and SwiftUI, a number of structure patterns, and rather more. It’s a correct legacy codebase.
As a substitute of figuring the whole lot out by myself, I had conversations with numerous crew members. Generally they have been one-on-one conversations however different instances I met with two or three individuals without delay.
By these conversations, I realized about numerous architectural patterns that existed within the codebase. Which of them they thought of to be good matches, and which of them they have been trying to part out. I realized why sure bits of code have been nonetheless in Goal-C, and which components of the Goal-C codebase ought to be refactored ultimately.
I realized that sure crew members had spent plenty of time engaged on particular options, patterns, and companies throughout the app. They might inform me why sure choices have been made, and which selections they have been and weren’t significantly pleased with.
After assembly the crew I knew a lot extra in regards to the challenge, the codebase, the individuals engaged on the challenge, and the way issues transfer and evolve throughout the crew. This was extremely useful info to have as soon as I began to discover the codebase. By figuring out the crew I knew a lot extra in regards to the why of some bits of code. And I knew that some code wasn’t value exploring an excessive amount of as a result of it might be gone quickly.
On high of that, by way of figuring out the crew, I felt extra empathic about bits of code that I didn’t like or didn’t perceive. I do know who was more likely to have labored on that code. So as a substitute of getting annoyed about that little bit of code, I knew who I might ask to be taught extra in regards to the complicated part of code.
Break issues
Along with assembly the crew behind your new codebase, you’ll wish to begin exploring the codebase itself sooner fairly than later. One of many key issues to determine is how the challenge is ready up. Which code is accountable for what? How does one factor affect the opposite?
Hopefully, the codebase follows some well-established patterns that enable you determine this out. Regardless, I discover it helpful to try to break issues whereas I discover.
By introducing flaws within the enterprise logic for an app on goal, you possibly can be taught loads in regards to the codebase. Generally it helps you uncover sure “this could by no means occur” crashes the place a crew member used a power unwrap or wrote a guard let with a fatalError inside.
Different instances issues break in additional refined methods the place the app doesn’t fairly work however no errors are proven. Or possibly the app is superb about dealing with errors and it signifies that one thing went flawed / not as anticipated however the app informs you about this.
Whenever you break the networking layer in your app, you would possibly uncover some hints about how the app handles caching.
By making small modifications that almost certainly break the app you possibly can be taught tons. It’s a method I usually use simply to see if there are any threads I ought to begin unraveling to be taught increasingly more in regards to the cool particulars of a codebase.
In fact, you don’t wish to go round and begin poking at random issues. Normally, once I begin exploring I’ll select one or two options that I wish to deal with. That is precisely the main focus of my subsequent tip.
Deal with a slender scope
Whenever you be a part of a big sufficient codebase, the concept of getting all of that code in your head in some unspecified time in the future sounds not possible. And truthfully, it most likely is. There’s a great likelihood that the majority builders on the crew for a big challenge can have one or two components of the codebase internalized. They know the whole lot about it. For the whole lot else, they’ll roughly know which patterns the code ought to comply with (as a result of the entire crew follows the identical patterns) and so they may need some sense of how that code interacts with different modules.
General although, it’s simply not reasonable for any crew member to know all the ins and outs of each module or characteristic within the codebase.
So why would you be trying to discover all the codebase all of sudden?
For those who’re employed on a particular crew, deal with the code that may be maintained by that crew. Begin exploring and understanding that code in as a lot element as doable, have crew members present you ways the code works, and see in case you can break among the code.
Generally there might be bug tickets or options that you could begin to provide you a great place to begin to start studying extra a couple of codebase. If that’s the case, you should utilize your tickets that will help you decide your scope. For those who’re engaged on a bug, deal with understanding the whole lot you possibly can in regards to the part of code that appears almost certainly to be the supply of the bug.
And as all the time, you’ll wish to be in contact with the crew. Ask them in the event that they can assist you discover one thing to deal with initially. When you might have a bug ticket to work on, see if someone on the crew can assist you kickstart your analysis; possibly they’ve some ideas on the place you can begin wanting first.
And in a perfect world, leverage pair programming to double the velocity at which you be taught.
Leverage pair programming
One device that I often discover to be immensely underused is pair programming. In numerous locations the place I’ve labored, builders choose to work alone. Headphones on, deep within the zone. Questions ought to be initiated on Slack so that you’re disturbed as little as doable. Disable notifications if you must.
There’s completely a time and place for deep centered work the place you’re to not be disturbed.
Nonetheless, there’s an unlimited profit in pairing up with a teammate to discover matters and work on options. Particularly once you’ve simply joined a crew, it’s tremendous necessary you might have entry to your crew members that will help you navigate the corporate, crew, and codebase.
Whenever you’re pairing with a teammate throughout your exploration part, you possibly can take the wheel. You can begin exploring the codebase, asking questions on what you’re seeing as you go. Particularly when you might have one thing to work on, this may be extraordinarily helpful.
Any query or thought you may need can instantly be bounced off of your programming associate.
Even in case you’re not the particular person taking the wheel, there’s numerous profit in seeing someone else navigate the code and challenge you’ll work on. Pay shut consideration to sure utilities or instruments they use. For those who see one thing you haven’t seen earlier than, ask about it. Perhaps these git instructions your coworker makes use of are utilized by everyone on the crew.
Particularly when there’s debugging concerned it pays dividends to ask for a pairing session. Seeing someone that’s skilled with a codebase navigate and debug their code will educate you tons about relationships between sure objects for instance.
Two individuals know a couple of, and that is very true whereas onboarding a brand new coworker. So subsequent time a brand new particular person joins your crew, provide them a few pair programming classes. Or in case you’re the brand new joiner see if there’s someone all in favour of spending a while with you whereas working by way of some issues and exploring the codebase.
Use breakpoints
Once I was engaged on this publish I requested the group how they prefer to discover a codebase and lots of people talked about utilizing a symbolic breakpoint on viewDidLoad or viewDidAppear which I discovered a reasonably cool strategy to studying extra in regards to the completely different views and consider controllers which are utilized in a challenge.
A symbolic breakpoint means that you can pause the execution of your program when a sure technique is named on code you may not personal. For instance, you possibly can have a symbolic breakpoint on UIViewController strategies which lets you see at any time when a brand new subclass of UIViewController is added to the navigation hierarchy.
Realizing this sort of stuff is tremendous helpful since you’ll be capable of be taught which view controller(s) belong to which display screen fairly shortly.
I haven’t used this one loads myself however I discovered it an attention-grabbing concept so I wished to incorporate it on this record of ideas.
In Abstract
Whenever you be a part of a brand new crew, it’s tempting to maintain your head down and research your new codebase. In your head, you would possibly suppose that you just’re anticipated to already know the whole lot in regards to the codebase though you’re utterly new to the challenge.
You would possibly suppose that every one patterns and practices within the challenge are business normal and that you just simply haven’t labored in locations nearly as good as this one earlier than.
All of those sorts of concepts exist in just about anyone’s head and so they forestall you from correctly studying and exploring a brand new codebase.
On this publish, you might have realized some recommendations on why human interplay is extraordinarily necessary throughout your exploration part. You additionally realized some helpful ideas for the extra technical aspect of issues that will help you successfully deal with studying a brand new codebase.
Good luck in your subsequent journey into a brand new codebase!