What is the best approach to code review?

Recorded May 22nd 2020 – watch the full episode on YouTube.

How do you do code review being a senior developer? More broadly, what approach do you take towards reviewing someone else's code?

Paola Mata: My approach to reviewing code hasn't changed much since I started. So ever since I started as a junior engineer, I was always reviewing code. I was learning a lot more as I went. So I had a lot more questions. Or sometimes things would go over my head and I would ask for an explanation.

I think now that I'm thinking about how my team is writing code. I'm thinking more of the bigger picture. How's this going to work long-term? Is this something that is going to introduce any potentially technical debt or unnecessary complexity into the app or is anything unclear?

Surprisingly, sometimes naming is just terrible. And I have to make a comment on it. Like, “I’m not sure what this function does. Please make it more clear.” So things like that. Adding good comments, maybe when something is a little bit too complex. Whatever's going to make not just my life, but my team's life easier and whoever takes over the code when I'm on a different team. That's what I'm thinking about when I'm doing code review.

“And sometimes the questions that a junior might ask might be really beneficial to make me rethink with the way I wrote something to maybe break it down and make it more clear. So anybody can contribute at any level.”

Paul Hudson: When would you say it's not just the short term of let's make this code the best we can. But also as a senior developer, you're also looking at the long-term growth of those around you as well. Helping them get better at naming things, get better architecting things and thinking a bigger picture as well.

Paola Mata: So actually, a good example is the team that I'm currently on. When I came on, I was mid level, just a software engineer. We hired an associate and then the other teammate was a senior. So you have a little bit of the different levels.

We're all expected to do code review and contribute. And sometimes the questions that a junior might ask might be really beneficial to make me rethink with the way I wrote something to maybe break it down and make it more clear. So anybody can contribute at any level. I would say more confident at this point I'm more opinionated. And when I think something is not going to work or just looks too messy or hacky, I will point it out.

“I was really going back to just the very basics and trying to break them down. And reading down for somebody who has maybe never seen them or doesn't know how to use them yet. So there's a lot of thinking that goes into writing the documentation as well.”

Paul Hudson: Honestly, I love questions from junior developers, obviously anyone. But junior developers particularly ask questions that catch me out a little bit. Because they force me to think exactly how things work and how to phrase them in a way that can be understood at whatever level they are at.

And I enjoy that – it makes me really make sure I can explain what I've just done in a simpler way and in a way that really outlines what I considered, what I've rejected, alternatives that didn't quite work out, whatever, along the way in a way that makes sense to people. And that's actually quite hard to do. It's a skill you learn.

Paola Mata: Speaking of which, it's actually something that I had to think about like when you're writing any documentation or for example, the chapter that I wrote for the Swift Review book. Where I was really going back to just the very basics and trying to break them down. And reading down for somebody who has maybe never seen them or doesn't know how to use them yet. So there's a lot of thinking that goes into writing the documentation as well.

Paul Hudson: In fact, just Monday I was doing a video for UIKonf with my daughter, Sophie. And afterwards we were interviewed live by Glenna who was emceeing the conference for that day. And she asked Sophie, "What was the hardest thing about learning Swift?" And she said, "All those optionals."

And I said, "Well, optionals are for Sophie, but a lot of folks struggle with closures." And she turns to me on the camera and goes, “What are closures?” I'm like, “I can't explain to you what on livestream what closures are. We can go over this later on.” But it's not feasibly possible to do that on a livestream to explain closures with somebody because it is complex. You have to go over all your thoughts a little bit more, then convey them in a sensible way.

Sponsor Hacking with Swift and reach the world's largest Swift community!