DEV Community

Discussion on: 4 Things Developers Take for Granted That Used to Be Really Hard

Collapse
 
simonhaisz profile image
simonhaisz

Code reviews. Even when using version control 10+ years ago the code review would be you sitting at another devs desk as they walk you through the diffs.

Continuous Integration. Remember having to commit your changes in the morning so the noon build would get them? And because the build takes 2 hours and the first set of regression tests takes another hour you only have a few hours to fix any issues that happen before the 6pm build?
Yeah, I don't miss that.

Collapse
 
shawnoden profile image
Shawn Oden

Sadly, I recall too many times when "continuous integration" was just Ctrl-S, since there wasn't anything other than the live site. And QA was just reloading the website.

Collapse
 
rubberduck profile image
Christopher McClellan

Why aren’t your code reviews like that now?! Absolutely the most effective way to perform a code review, in my opinion. In fact, it’s so effective that my team does it continuously...

Collapse
 
simonhaisz profile image
simonhaisz

I believe that there are pros and cons for both types of code reviews, which I will refer to as sync and async. Depending on your situation one may work better than the other for you.

sync
Pros:

  1. Everyone is focused 100% on the review
  2. Questions can be answered immediately - "I don't know" is a valid answer
  3. No context switching during the review means efficiency That's all great, so even after we got software that supported async we kept doing sync. But then we ran into the following cons so we switched.

Cons:

  1. Requires reviewers to find time when both of them are available at the same time.
  2. It can take a while for the reviewer to process the changes so that they can even start asking questions. All the while the writer is just sitting there waiting...
  3. ...Which lead to their frustration sub-consciuosly influencing the reviewer to 'hurry up and approve' without them saying a word. During this time we had a number of bugs crop up that were the exact types of issues that code reviews are best at catching. Our RCA of this was that the nature of sync reviews put more pressure on the reviewers to approve changes quickly, meaning they were disincentivised to go "I'm not sure, I need to think about this for a bit". Now, depending on your team/culture maybe this doesn't happen to you.

What we've experienced from async
Pros:

  1. Allows people to review on their own time/pace, including remotely
  2. Not having someone waiting next to you while you review means you do not feel rushed (any more than the current schedule anyways)
  3. Documented feedback means a) things are likely to be followed up b) others can learn from the review
  4. If the reviewer needs to have a face to face discussion, they can still do that! It's not uncommon for me to add a comment "I'm confused/concerned about this approach" and then meet with them
  5. It's easier to review code not in the review using my own machine/setup rather than all to drive on their box.

Cons:

  1. Promptness of response can really lag
  2. Someone can technically click the green check mark without looking at a single line of code Depending upon the maturity of your team those may be big issues or not issues at all.
Thread Thread
 
rubberduck profile image
Christopher McClellan • Edited

I was just making a joke about pair programming man. I’ve been on teams that don’t do code reviews anymore because we pair anyway.

Thread Thread
 
simonhaisz profile image
simonhaisz

Ugh woosh right over my head...

Thread Thread
 
jrohatiner profile image
Judith

Very thorough explanation. And accurate as well. Namaste!

Collapse
 
remotesynth profile image
Brian Rinaldi

Yes. Agree on both.

Collapse
 
mazz profile image
Michael • Edited

I don’t recall ever working at a place with that high a degree of build integration. Maybe one place but that was mid-to-late 2000s

Collapse
 
simonhaisz profile image
simonhaisz

That example WAS from the mid 2000s :)