Backwards Compatibility

Let’s look at how to maintain backwards compatibility in code reviews. We’ll show you a simple example and explain why the feedback matters.

The Scenario

A developer has updated a function to remove the age field from user data. The code works but could break existing functionality.

function getUserData(user: User) {
  return {
    name: user.name,
    email: user.email,
    // Removed age field that existing code depends on
  }
}

How will you comment on this code?

Choose the option that you think is the most constructive and helpful.

Itsik Mamancommented on Apr 2, 2025

This will break existing code.

🚫

Less Helpful Approach

• Doesn’t explain what will break
• Doesn’t suggest how to fix it
• Feels critical without being constructive
• Doesn’t explain the benefits of maintaining compatibility

Itsik Mamancommented on Apr 2, 2025

Consider keeping the age field for now.

⚠️

Nit Approach

• The recommendation focuses only on one field
• Doesn’t explain the full compatibility implications
• Misses the opportunity to discuss gradual deprecation
• Doesn’t acknowledge the working implementation

Itsik Mamancommented on Apr 2, 2025

Great work on the user data structure! To maintain backwards compatibility, we should keep the age field for now and mark it as deprecated. This will give other developers time to update their code. Here’s how we can improve it:

userData.ts

function getUserData(user: User) {
  return {
    name: user.name,
    email: user.email,
    birthDate: user.birthDate,
    /** @deprecated Use user.birthDate instead */
    age: calculateAge(user.birthDate), // Keep for backwards compatibility
  }
}