Impact Analysis Before Modifying Shared Methods

๐Ÿ“– 1 minute read

When deciding whether to add new fields to a shared transformation method (like toArray() or custom serializers), always check all usages first to understand the blast radius.

The decision:
Should you add fields to a shared method, or add them at the call site?

Step 1: Find all usages

rg "MyClass::toArray\(\)" app/ --type php -B 2 -A 2

Step 2: Analyze each consumer

  • Does it expect specific keys only?
  • Will extra keys cause issues?
  • Is it part of an API contract?

Example scenario:

// Shared method
public static function toSettings(Product $product): array
{
    return [
        'name' => $product->name,
        'price' => $product->price,
        // Should 'markup' go here or at call site?
    ];
}

// Consumer 1: API endpoint (wants markup)
// Consumer 2: Alert notification (only reads price, ignores extra)
// Consumer 3: Report transformer (spreads array into larger struct)

Decision criteria:

  • If ALL consumers need it โ†’ add to shared method
  • If ONE consumer needs it โ†’ add at call site
  • If it breaks an API contract โ†’ versioned endpoint or call-site addition

Pro tip: Use git grep or rg (ripgrep) to search, not IDE searchโ€”catches dynamic calls and string references.

Daryle De Silva

VP of Technology

11+ years building and scaling web applications. Writing about what I learn in the trenches.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *