• Blog
    • Tecnologia
    • Carreira e Cultura
  • Materiais Gratuitos
  • Podcast
  • Nossas vagas
  • Site Movile
Menu
  • Blog
    • Tecnologia
    • Carreira e Cultura
  • Materiais Gratuitos
  • Podcast
  • Nossas vagas
  • Site Movile
  • Android, Backend, Front-end, Frontend, iOS, Tecnologia

What is a code review?

Compartilhe

Compartilhar no facebook
Compartilhar no google
Compartilhar no twitter
Compartilhar no linkedin

In this post, I’m gonna introduce a very important practice in Software Engineering: code reviews.

What is a code review?

If you are a developer, no matter how experienced you are, you’ll make mistakes. Code reviews are a practice in Software Engineering that in general, help developers to find defects, design problems, assure best practices compliance and apply knowledge transfer before delivering code.

I really enjoy code review sessions, so I always try to bring this practice to every company I work for. It’s great for learning new things, share opinions and give great feedback!

Why?

We want the best code as possible to be delivered. Code that can grow organically, following the good principles of Software Engineering.

– Defects: During a code review, we can find if something was misunderstood, even communication issues.

– Design problems: it’s quite common to think in solutions and forget dark parts of the problem. This is a good time to find design issues that, maybe not now, but in the near future can cause problems. This is quite common with non-functional requirements.

– Best practices: each programming language has its _quirks_, so we look for adherence to the idiomatic code. Static analysis tool can help here.

– Knowledge transfer: everybody learns. Senior or junior, we make mistakes and write beautiful code!

General aspects

Leading a code review session requires a few things to keep in mind in order to avoid biases and preconceived ideas. A session usually takes many minutes of interactions through code acceptance.

Code reviews are _independent_ of programming languages. Scripts, build and automation code can also be reviewed. Recently, I also recommended my peers to review infrastructure code, an area whose is known to neglect code before the DevOps culture appeared. Things are changing and for the best!

The code review is only possible because of the VCS software like git. There are services that integrate with git and make it possible to have a centralized place, where you and your team members can establish a conversation and give feedback. Services like GitLab, GitHub and BitBucket are examples of that.

How it happens?

This is a way to review code, with your team you should define what is best and adapt if something doesn’t work.

Developers are responsible for frequently committing their code and when it’s ready or even when they feel feedback is needed, it is a good time to start a code review. If you’re on GitLab, reviews are called Merge Request. If it’s GitHub – Pull Request.

There are different ways of starting a review according to the git flow of your choice. My team currently works with a master branch – a known place for stable code. In this case, everything we develop must pass the review before being added back to master.

After three days, you finished your so expected feature. Tests are all green, static analysis ran, no issues found. You’re ready to start a review before finally shipping your code.

It’s time to choose one or more members of your team to subscribe to the review, give suggestions and receive notifications of interactions.

Best practices

No matter if you’re opening a review or you’ll act as a reviewer, empathy must guide both of them. Respect, help and contribute with your peers. It’s a rule good manner.

As the author

Having your code reviewed demands empathy overall. Don’t try to look so smart.
Let’s see a few practices that guide your good code:

  • Small commits: try to reduce the number of commits. Git squash may help!
  • Descriptive review: write a near-perfect title for it, with a detailed description (Is it a bug? A feature? Dark details, etc)
  • Scope: keep the scope of your changes limited. Your peers will thank you.
  • Explain your decisions: if there’s something a bit more complicated, algorithms choice, explain it.
  • Choose the reviewers: sometimes, people are very busy, so choose wisely who can collaborate more with your review. Be by subject expertise or availability, don’t choose just your friends.
  • Don’t take it too personally. Don’t be offended you received constructive critics.

As a reviewer

There are different things to look for while reviewing. I really enjoy the design aspects of the code. If we are in review session of Go code, I’ll look for the lack of idiomatic Go. Now, let’s see how to lead the review by the reviewer’s perspective:

  • Purpose: does the author followed the best practices, tested and write good documentation? Does this review follow the guidelines your team established?
  • Ask: this is very important. If you see code that’s is confusing, hard to understand, non-idiomatic, please ask! You’re helping not only yourself but your coworker.
  • Non-function requirements: if there’s something that smells bad, ask! Let’s suppose you found a piece of good that could cause bad performance, leave a question. You may not see something your co-worker wrote or it’s justified.
  • Look for unnecessary code: developers enjoy writing code, even when it’s not necessary. If you found something a lib solves better or it’s faulty, ask, suggest.
  • Is this code extensible? If not, give ideas on how to make it extensible.
  • Is this code clear enough for all the team members understand?
  • Does this code leave a future change? The infamous technical debts. If yes, create an issue and add a due date to it.
  • Are the unit/integration tests given the same care as the code itself? Test code is code.
  • Security: it goes deeper, look for potential security breaches and raise questions.
  • For bigger reviews (too many files, classes/methods, functions, etc), I highly recommend to checkout the branch locally and use your editor/ide to navigate the code. If you use a static analysis tool, it’ll help by warning about problems.

Biases

I’ve worked in places where people were code review _fanatics_. It was bad. No good conversations, just nitty pick details and a lot of egos. Please, don’t do that! I believe in teaching, educating people and feedback is priceless in this case. Why, instead of pointing your finger, don’t you show how and why your suggestions would be better?

Conclusion

Code review is an essential practice for professionals. It dramatically improves the quality of the code, decreases the number of bugs and shares knowledge. The adoption of reviewing code is part of a transition from Software Development to Software Engineering. It’s when you learn to work on a team, divide work and iterate into small steps to delivery well-engineered code.

It’s time well spent. Apparently, it isn’t generating value, but if you look closer, all your users want is software that works. It’s only possible with good practices of real engineering.

Original article published here!

Compartilhe isso:

  • Tweet

Curtir isso:

Curtir Carregando...
Gustavo Costa

Gustavo Costa

Deixe um comentário

Categorias

Categorias
  • Android
  • Backend
  • Banco de Dados
  • BI
  • Carreira
  • Carreira e Cultura
  • Carreira e Cultura
  • Ciência de Dados
  • Cultura
  • Data Specialist
  • Design
  • Diversidade
  • Front-end
  • Frontend
  • Fundação 1Bi
  • Grupo Movile
  • Histórias
  • iFood
  • Infraestrutura
  • Inteligência Artificial
  • iOS
  • iOS App Development
  • Kotlin
  • kubernetes
  • LeaderShift
  • Material
  • Mobile
  • Mobile Dream
  • Movile
  • Movilian@s
  • News
  • PlayKids
  • Podcast
  • Produto
  • Projetos
  • React
  • RESPECT
  • Software Architecture
  • Software Engineering
  • Solid
  • Swift
  • SwiftUI
  • Sympla
  • Technology
  • Tecnologia
  • testes
  • UX
  • Vagas
  • Wavy
  • Zoop

Posts relacionados

Arquitetando Sign In with Apple de uma forma testável

Leia mais »
Swift

Swift: Princípio da Inversão de Dependência em Swift [Artigo 5]

Leia mais »

Whitepaper: API’s no iFood

Leia mais »
Swift

Swift: Princípio da Segregação de Interface [Artigo 4]

Leia mais »
Tags
Agile Android Apache api App Apps Arquitetura Autoconhecimento Backend Banco de Dados BI Blog bot Bots Cache Carreira Carreira e Cultura Cloud code containers Continuos integration Cultura Dados Dados Probabilísticos data Data Center Data Science Desenvolvimento Design devs digital diversidade DSL Entrevista Evento eventos Experiências Facebook front Front-end Frontend Full-stack Fundação 1Bi Gestão GO google Groovy grupo Grupo Movile histórias home iFood Infraestrutura Inteligencia artificial iOS Java jetpack Json Kotlin kubernetes layout Liderança linguagem loadview Machine Learning marketplace Mobile Movile Movilianos news Objective-C PlayKids podcast produto Projetos pwa python Rapiddo react Reativas Redis research review RH Room spark Spring stack storyboards Superplayer Swift Sympla Talentos tdd Tecnologia Testes transformação digital Unity ux vagas Valores view viewcode viewcontroller viper Voxel vue wavy web Widget Zoop

Siga-nos

Facebook-f
Linkedin
Instagram
Youtube
Twitter

Baixe nosso e-book!

Receba conteúdos exclusivos em seu email!

Seus dados estão protegidos conosco.

Menu

  • Tecnologia
  • Carreira e Cultura
  • Materiais Gratuitos
  • Podcast
Menu
  • Tecnologia
  • Carreira e Cultura
  • Materiais Gratuitos
  • Podcast

principais categorias

  • Tecnologia
  • Carreira e Cultura
  • News
  • Movile
  • Backend
  • Android
Menu
  • Tecnologia
  • Carreira e Cultura
  • News
  • Movile
  • Backend
  • Android

FEED RSS

RSS Feed RSS - Posts

RSS Feed RSS - Comentários

redes sociais

  • Facebook
  • LinkedIn
  • Instagram
  • Youtube
  • Twitter

Copyright 2021 © Todos os direitos reservados. Criação de Site por UpSites & Weblab

  • Novas Vagas!

  • Último Podcast!

%d blogueiros gostam disto: