Reading and Mapping Legacy Code

Before changing a legacy app, map it: entry points (index.php, cron scripts, CLI tools), routing (framework, .htaccess rewrites or one file per page), includes and globals, database access, and external integrations. Use IDE navigation, grep, Xdebug step-debugging, and tools like PhpMetrics or PHPStan at low levels to find hotspots. Write down the architecture as you learn it; focus changes where business value and bug density are highest.

# Find entry points and includes
grep -rln --include='*.php' "\$_GET\|\$_POST" public/ | head
grep -rn --include='*.php' "require_once\|include " src/ | wc -l
grep -rn --include='*.php' "mysql_query\|mysqli_query" . | head     # raw SQL hotspots

# Churn x complexity: files changed most often
git log --since=1.year --name-only --pretty=format: | sort | uniq -c | sort -rn | head -20

Common pitfalls

• Rewriting from scratch before understanding behavior (the 'big rewrite' trap).
• Ignoring cron jobs and CLI scripts that depend on the same code.
• Assuming dead code is dead without checking logs or usage.

Key points

• Map entry points, routing, data access and integrations
• Prioritize by churn and business value
• Document what you learn

Further reading: Martin Fowler: Strangler Fig Application