Code review checklist for LLD - System Design Guide

Problem Statement

Without a clear checklist, code reviews for low-level design (LLD) can miss critical issues like poor class structure, tight coupling, or violation of design principles. This leads to hard-to-maintain code, bugs, and increased technical debt.

Solution

A code review checklist for LLD guides reviewers to systematically check key design aspects such as SOLID principles, modularity, naming conventions, and error handling. This ensures consistent quality and maintainability before code merges.

Architecture

Developer

→Code Review

↓

Checklist Items

Checklist Items

This diagram shows the flow from developer submitting code, through the code review process guided by a checklist, resulting in feedback for improvement.

Trade-offs

✓ Pros

→

Ensures consistent application of design principles across the codebase.

→

Helps catch design flaws early, reducing bugs and refactoring costs.

→

Improves code readability and maintainability by enforcing standards.

→

Facilitates knowledge sharing among team members through structured reviews.

✗ Cons

→

May increase review time due to thorough checklist adherence.

→

Can be seen as bureaucratic if checklist is too rigid or long.

→

Requires training reviewers to understand checklist items deeply.

Use when multiple developers contribute to the same codebase and the system complexity requires maintainable, well-structured code. Especially important for projects with frequent releases or long-term maintenance.

Avoid in very small projects or prototypes where speed is prioritized over design quality and the team size is one or two developers.

Real World Examples

Google

Google uses detailed code review checklists to enforce design principles and maintain high code quality across its large engineering teams.

Microsoft

Microsoft employs checklists during code reviews to ensure adherence to SOLID principles and modular design in their large-scale software products.

Amazon

Amazon integrates design checklists in code reviews to catch architectural issues early in microservices development.

Code Example

The before code lacks clear naming, encapsulation, and type hints. The after code applies checklist items like naming conventions, encapsulation, and SOLID principles to improve design clarity and maintainability.

LLD

### Before: No checklist, ad-hoc review
class User:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def getdata(self):
        return self.name + str(self.age)

### After: Review guided by checklist enforcing SOLID and naming
class User:
    def __init__(self, name: str, age: int):
        self._name = name
        self._age = age

    def get_data(self) -> str:
        return f"{self._name} {self._age}"

# Checklist applied:
# - Method names are clear and follow naming conventions
# - Encapsulation by prefixing attributes with underscore
# - Type hints added for clarity
# - Single Responsibility Principle maintained

Alternatives

Pair Programming

Instead of post-development review, design issues are caught in real-time by two developers working together.

Use when: Choose when immediate feedback and collaboration are preferred over formal review processes.

Automated Static Analysis

Uses tools to automatically check code for design smells and violations instead of manual checklist reviews.

Use when: Choose when you want to reduce manual effort and catch common issues automatically.

Summary

A code review checklist for LLD helps catch design issues early by guiding reviewers through key principles.

It improves code quality, maintainability, and team knowledge sharing with consistent standards.

Checklists should be balanced to avoid slowing development or becoming bureaucratic.