💻 Code Review: Focus on What Really Matters

Inspired by Thiago Caserta's LinkedIn post, which highlights the true focus of a code review: preventing production failures rather than obsessing over style.

Code reviews are essential to software development, but too often, they focus on the wrong things. While discussing spacing issues, variable names, and style guides can improve readability, they don’t prevent production failures. The most important question to ask during a review is:

“Will this code break in production?”

---

What Everyone Focuses On

Typical code reviews often revolve around:

• Incorrect spacing
• Variable naming preferences
• Following design patterns
• Code style enforcement

While these are useful for consistency, they do not prevent real-world issues. A perfectly formatted codebase means nothing if it crashes in production.

---

Automating Style Guide Enforcement

Rather than spending valuable code review time nitpicking style issues, teams should rely on automated tools to enforce coding standards. This allows developers to focus on what really matters: preventing production failures.

Popular Tools for Style Enforcement

• Java: Checkstyle, SpotBugs
• Node.js: ESLint, Prettier
• Git Hooks: Husky for pre-commit checks
• CI/CD Pipelines: Integrate linters into GitHub Actions, GitLab CI, or Jenkins

Examples of Automated Style Checks

Java - Enforcing Code Formatting with Checkstyle

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>3.1.2</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Node.js - Enforcing Code Formatting with ESLint & Prettier

{
  "scripts": {
    "lint": "eslint .",
    "format": "prettier --write ."
  }
}

By automating these checks, teams ensure a consistent code style without wasting time during reviews.

---

What Really Matters: Avoiding Production Failures

Instead of nitpicking minor details, focus on critical areas that impact system stability, performance, and reliability. A solid code review should prioritize:

Edge Cases – Will this code handle unexpected situations?

Edge cases are situations that developers might not expect during normal execution but can cause system failures. These include null values, timeouts, errors that bubble up unexpectedly, and system recovery after failures. Addressing edge cases improves software resilience and reliability.

Are there proper null checks?

❌ Bad Example (Java - NullPointerException risk):

public String getUserEmail(User user) {
    return user.getEmail(); // Crashes if user is null
}

✅ Good Example:

public String getUserEmail(User user) {
    return Optional.ofNullable(user)
                   .map(User::getEmail)
                   .orElse("No email available");
}

❌ Bad Example (Node.js - TypeError risk):

function getUserEmail(user) {
    return user.email; // Crashes if user is undefined
}

✅ Good Example:

function getUserEmail(user) {
    return user?.email || "No email available";
}

Is there a timeout handling mechanism?

❌ Bad Example (No timeout - request hangs forever):

HttpClient client = HttpClient.newBuilder().build();
HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

✅ Good Example:

HttpClient client = HttpClient.newBuilder()
    .connectTimeout(Duration.ofSeconds(5))
    .build();

❌ Bad Example (Node.js - No timeout set):

axios.get(url).then(response => console.log(response.data));

✅ Good Example:

axios.get(url, { timeout: 5000 })
    .catch(err => console.error("Request timed out", err));

Performance – Will this code cause performance bottlenecks?

Performance issues can lead to slow applications, high server costs, and poor user experience. Identifying bottlenecks early in code reviews helps maintain scalable systems.

Common Performance Issues:

• N+1 Query Problems: Excessive database queries can slow down requests significantly.
• Memory Leaks: Unreleased resources cause long-term performance degradation.
• Cache Invalidation: Poor cache handling can serve stale data or overwhelm the database.
• Resource Locking: Concurrent operations can cause race conditions or deadlocks.

Are there any N+1 query issues that could degrade database performance?

❌ Bad Example (Java - N+1 Query Issue in JPA):

List<User> users = entityManager.createQuery("SELECT u FROM User u", User.class).getResultList();
for (User user : users) {
    user.getOrders().size(); // Triggers additional queries
}

✅ Good Example:

@Query("SELECT u FROM User u JOIN FETCH u.orders WHERE u.id = :id")
User findUserWithOrders(@Param("id") Long id);

❌ Bad Example (Node.js - N+1 Query Issue in Sequelize):

const users = await User.findAll();
for (const user of users) {
    const orders = await Order.findAll({ where: { userId: user.id } });
}

✅ Good Example:

const users = await User.findAll({ include: [Order] });

---

The Reality: Style Guides Don’t Break Production—Edge Cases Do

A well-formatted codebase is nice, but a system that crashes due to unhandled exceptions, poor performance, or missing monitoring is a nightmare. When reviewing code, shift your mindset from aesthetics to stability, performance, and resilience.

Next time you're in a code review, ask yourself: Am I fixing a style issue, or preventing a production failure?

What do you focus on in code reviews? Let’s discuss in the comments!