We've recently been collaborating on features by having one person do some part of it, and then passing it along to someone else to finish it up. I'm personally really enjoying this process since it's a great way for me to catch up on new code that's coming in. It's also interesting to me to see how one of us implements a solution to a problem or feature.
I don't always look at every line of code merged though (gasp!), and when I work on the next version of something that was built by someone else, I usually try on my own to figure out where the code lives and how it works.
Most of the time, I would have a seen a bit of the code when the pull request was made and I had the chance to look it over. When I don't, I end up going to GitHub, find the pull request, and see where the files are. Then I open up my editor and read the code for a while before getting my paws on it.
I'm sure everyone has their own workflow, or maybe your company provides some guidelines/rules for you? Do you often (try) to look at the code that's coming into the codebase, or are you usually working only in your own domain? Or maybe you ask the person who wrote it to explain it to you while pairing? Would love to hear how you catch up on new code!
Top comments (7)
Every situation and context is different.
Here is mine:
Direct impact
The code changes are directly affecting me, I will scan carefully.
Current job
Since it's a huge enterprise code base, we have multiple teams working in the enterprise code base. I often merge the
developmentbranch into my branch and 90% ignore the merged code. Now, if there is a merge conflict, then I take a look enough to fix the merge conflict.Curiosity
If I am curious about a feature or a piece of functionality another team implemented, I take my time looking at the code and learn from it.
Good points. I imagine it would extremely hard to keep up with every bit of code that gets merged if you're on a large enterprise code base.
Haha it is hard to keep up. When you first start a job, you've the urge.
That goes away when you are too busy trying to get your work done. :)
On projects where we do PRs, I'll be notified of them and give them a glance to see what's happening. Sometimes I'll go have an IRL chat about it.
On other projects (which is most of the things I work on, to be honest) when I commit more than a trivial change, I'll have a chat about what I did over a coffee after a stand-up or something like that. So from real conversation I'll have an overview of what was done and why, that doesn't require me to look at code or keep up with features that might not affect me. That way, in the general course of work I rarely end up finding anything that surprises me.
If it's directly hitting what I'm working on, I'll take a close look and have an IRL chat about it if there's a merge conflict or something complicated going on.
If there is overreaching functions from elsewhere being called on the piece I'm working on, I take a look.
It depends on what is going on and where. I can't be everywhere and it's hard to expect someone else to be too.
Read the tests!
Good one!