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.

Practice

1. Which of the following is the MOST important focus when reviewing a Low-Level Design (LLD) document?

easy

A. Clarity and correctness of the design

B. The color scheme of the document

C. The number of pages in the document

D. The font style used

Solution

1. Step 1: Understand the purpose of LLD review

   The main goal is to ensure the design is clear and correct so developers can implement it properly.

2. Step 2: Evaluate options based on relevance

   Options A, B, and D relate to formatting, which is less critical than clarity and correctness.

3. Final Answer:

   Clarity and correctness of the design -> Option A

4. Quick Check:

   Focus on clarity and correctness = C [OK]

Hint: Focus on design clarity and correctness first [OK]

Common Mistakes:

• Focusing on document style over content
• Ignoring correctness for aesthetics
• Confusing LLD with high-level design

2. Which checklist item should be included to ensure modularity in an LLD review?

easy

A. Ensure the document has a table of contents

B. Check if the design uses consistent variable names

C. Count the total number of classes

D. Verify if components have clear, single responsibilities

Solution

1. Step 1: Understand modularity in design

   Modularity means breaking the system into parts that each do one thing well.

2. Step 2: Match options to modularity

   Verify if components have clear, single responsibilities directly relates to single responsibility, a key modularity principle. Others are unrelated.

3. Final Answer:

   Verify if components have clear, single responsibilities -> Option D

4. Quick Check:

   Modularity = single responsibility components [OK]

Hint: Look for single responsibility to ensure modularity [OK]

Common Mistakes:

• Confusing naming consistency with modularity
• Counting classes without checking responsibilities
• Focusing on document formatting

3. Given this checklist item: "Ensure all public methods have clear input and output definitions." What is the MOST likely outcome if this is NOT followed?

medium

A. Developers may implement methods incorrectly due to unclear contracts.

B. The system will automatically generate method documentation.

C. The code will run faster.

D. The design will have fewer classes.

Solution

1. Step 1: Understand the role of input/output definitions

   Clear definitions guide developers on how to use methods correctly.

2. Step 2: Analyze consequences of missing definitions

   Without clear contracts, developers may misunderstand method usage, causing errors.

3. Final Answer:

   Developers may implement methods incorrectly due to unclear contracts. -> Option A

4. Quick Check:

   Unclear method contracts = incorrect implementation [OK]

Hint: Clear method contracts prevent implementation errors [OK]

Common Mistakes:

• Assuming code runs faster without definitions
• Thinking documentation is auto-generated
• Confusing method count with clarity

4. You find a design where security considerations are missing in the LLD. What is the BEST immediate action during the code review?

medium

A. Approve the design since security is handled later.

B. Ignore security as it is not part of LLD.

C. Request adding security checks and data validation in the design.

D. Suggest removing modularity to simplify security.

Solution

1. Step 1: Recognize importance of security in LLD

   Security should be considered early to avoid costly fixes later.

2. Step 2: Choose action that improves design quality

   Requesting security checks and validation ensures design is robust and safe.

3. Final Answer:

   Request adding security checks and data validation in the design. -> Option C

4. Quick Check:

   Missing security = request additions [OK]

Hint: Always include security early in design reviews [OK]

Common Mistakes:

• Ignoring security until later stages
• Approving incomplete designs
• Removing modularity harms security

5. During a code review for a complex LLD, you notice the design lacks scalability considerations and testability is weak. Which combined checklist items should you prioritize to improve the design?

hard

A. Increase code comments and skip testing details.

B. Add modular components with clear interfaces and include unit test plans.

C. Focus only on UI design and ignore backend scalability.

D. Reduce the number of classes and remove error handling.

Solution

1. Step 1: Identify key improvements for scalability and testability

   Modular components with clear interfaces help scale and isolate parts for testing.

2. Step 2: Match checklist items to these improvements

   Including unit test plans ensures testability is addressed alongside modularity.

3. Final Answer:

   Add modular components with clear interfaces and include unit test plans. -> Option B

4. Quick Check:

   Modularity + testing plans = better scalability and testability [OK]

Hint: Combine modularity and testing for scalable, testable design [OK]

Common Mistakes:

• Removing error handling weakens design
• Ignoring backend scalability
• Focusing only on comments without tests