Code reviews are an essential part of the software development process. When done effectively, they improve software quality, promote knowledge sharing, and help teams adopt coding best practices. This article explores the four main types of lightweight code reviews used by Agile development teams. We’ll look at the benefits and drawbacks of each approach, along with recommendations on when to use them.

Formal Code Inspections vs Lightweight Code Reviews

The most rigorous type of code review is the formal code inspection, pioneered by Michael Fagan in the 1970s. Formal inspections follow a highly structured 6-step process with clearly defined requirements for each phase:

• Planning 
• Overview
• Preparation
• Inspection Meeting  
• Rework
• Follow-up

While extremely thorough, formal inspections require significant overhead. Because of this, they aren’t commonly used in practice today outside of mission-critical software development. 

Instead, most teams rely on lightweight code reviews that aim to get 80% of the benefit for 20% of the effort. Lightweight reviews come in a few flavors:

• Pair programming
• Over-the-shoulder 
• Asynchronous pull requests
• Periodic code reviews

Let’s explore each approach.

Pair Programming For Complex Business Logic

The first type of lightweight code review is pair programming, where two developers work together in real-time on the same design, algorithm, code, or test. One developer acts as the driver, writing the code, while the other developer continuously reviews it as the navigator.

Pair programming works extremely well when tackling complex business logic. Having both developers analyze edge cases helps account for overlooked scenarios early on. The instant feedback also catches syntax issues, null pointers, off-by-one errors, and other mistakes quickly.

Other benefits of pair programming include:

• Increased code quality and fewer defects
• Knowledge sharing between pair partners
• Greater job satisfaction

That said, pair programming isn’t without downsides:

• It’s more expensive needing two developers per task
• Constant communication is essential for success
• Partners must be at similar skill levels

Overall, teams should use pair programming selectively for complex tasks requiring intricate business logic.

Over-The-Shoulder Reviews To Transfer Knowledge  

The next type of lightweight code review is the over-the-shoulder review. In this case, a senior developer directly mentors a junior developer by examining their code as they type it. It’s like pair programming, except the review is mainly one-way: senior to junior.

Over-the-shoulder code reviews are perfect for transferring institutional knowledge from veterans to new hires. The instant feedback helps junior developers avoid bad habits while showing them the preferred coding practices. It also leads to fewer bugs long-term.

However, like pair programming, over-the-shoulder reviews require significant time investment from senior resources. The approach also needs strong communication skills and interpersonal relationships to work well.

Use over-the-shoulder code reviews when onboarding new developers or tackling complex tasks with large knowledge gaps.

Asynchronous Pull Requests For Flexibility

In contrast to real-time pairing or reviews, asynchronous code reviews happen after initial development through peer review tools like GitHub, GitLab, or BitBucket. 

Developers open up pull requests when they complete a feature or bug fix. Teammates then provide feedback through comments at their own pace over the next few days before finally approving or rejecting the changes.

Compared to synchronous reviews, asynchronous pull requests offer more flexibility for modern distributed teams. Developers avoid constant context switching allowing them to stay in flow. The self-service model also facilitates more uninterrupted review time, resulting in increased code quality.

That said, asynchronous reviews have drawbacks too:

• Feedback loops take longer spanning multiple days
• There’s greater risk of miscommunication without real-time interaction

Overall, asynchronous reviews should be the default for professional developers. Use chat or video conferencing for conversations whenever needed.

Here’s an example pull request showing comments that help explain the context and suggest improvements:

diff --git a/src/email/EmailSender.java b/src/email/EmailSender.java
index a123d8f..b234dc9 100644
--- a/src/email/EmailSender.java
+++ b/src/email/EmailSender.java
@@ -5,7 +5,8 @@ public class EmailSender {
     private Transport transport;
     
     public EmailSender() {
-        // Configure SMTP transport 
+        // Consider extracting SMTP configuration to properties file
+        // for easier environment-based customization 
         transport = SparkPostSMTP.configure(); 
     }
 
@@ -13,6 +14,7 @@ public class EmailSender {
         Message message = new MimeMessage();
         message.setSubject("Welcome to Awesome App!");
         message.setContent("Thanks for signing up! Let me know if you have any questions.", "text/plain");
+        message.addRecipient(Message.RecipientType.TO, new InternetAddress(toAddress));
         transport.sendMessage(message, toAddress);
     }

}

Periodic Reviews To Spread Knowledge

The final lightweight code review variety is the periodic code review. Unlike previous approaches that review single pull requests or user stories, periodic reviews examine past work holistically.

In this model, teams schedule sessions every month or quarter for developers to showcase their recent code to the broader group. Reviewers analyze the design, tests, readability, and style to identify improvement areas.

The primary benefit of periodic reviews is strengthening the collective code health. They also build empathy, spread knowledge, and align coding techniques.

However, they come at a steep cost requiring full-team involvement. They also tend to rehash old decisions versus providing actionable feedback. 

Overall, periodic reviews work best for teams lacking regular code review processes. Otherwise, stick to asynchronous pull requests for efficiency.

Conclusion: Consistent Code Reviews Improve Quality

Code reviews are integral for producing high-quality, maintainable software. By thoroughly inspecting code changes, issues get caught early when relatively easy to fix. Knowledge also spreads quickly helping teams level up their skills.

While code reviews require initial time investment, they pay long-term dividends through cleaner code, fewer bugs, and improved team collaboration. Teams should therefore adopt lightweight, asynchronous reviews as standard practice, with periodic pair programming mixed in for complex tasks. Consistency is key: by reviewing every code change, quality drastically improves over time.

The key is choosing a style matching team needs, establishing coding standards, and integrating reviews within the development flow. There will be some friction at first. However, reviews will soon be seen as a friendly learning process versus a personal criticism. 

As teams mature, code reviews create the foundation for collective code ownership instead of isolated knowledge silos. The result is better software delivered sustainably at higher velocity. That’s incredibly powerful for developers, customers, and businesses alike.