VIEW SPEECH SUMMARY
- Legacy code is inevitable; like bank debt, it accumulates “interest” (maintenance cost).
- It's acceptable to have legacy if there is a plan to manage or pay it back.
- Good reasons to remove legacy code:
- High maintenance costs.
- Improve developer quality of life.
- Security vulnerabilities often associate with legacy code.
- Reducing cost and difficulty of adding new features.
- Bad reasons to remove legacy code:
- Removing it just because it’s trendy or to adopt new technology.
- Doing it only for career advancement or copy-pasting others’ approaches.
Starting the Refactoring Project
- Define a clear, focused problem to solve (e.g., security, deprecated frameworks, speed of delivery).
- Avoid scope creep by questioning if every new task solves the main problem.
- Use tools to track progress and communicate with stakeholders (dashboards, automated metrics).
- Expect programmers to dislike task management tools but use them for transparency.
Handling Legacy Code Refactoring
- Horror stories highlight pitfalls without sufficient testing or understanding.
- Always have a testing safety net: without tests, refactoring risks breaking production.
- Invest in tooling to auto-generate tests and detect unused code.
- Useful tools & tips:
- Use Jest for React coverage.
- Chrome DevTools’ coverage tab to find unused code.
- Tools like S-Link plugins, TS prune, Webpack bundle analyzer.
- Check and remove unnecessary dependencies (e.g., not pulling entire libraries for minor functions).
- Static code analyzers like ESLint and SonarQube.
- Use Chrome DevTools Recorder for auto-generating tests compatible with Puppeteer, Cypress, Playwright.
- Snapshot testing can catch component changes if used smartly.
- AI assistance for generating basic unit tests but require good code review.
Building Resilient Systems
- Systems must be resilient: able to survive failures gracefully (e.g., data center outages).
- Monitor proactively with meaningful logs and smart alerts.
- Prepare simple, clear runbooks for incident response; simplicity is critical (KISS principle).
- Implement retry queues, backups, replication, soft deletes, audit trails, and idempotent critical operations.
- Always try recovering backups regularly to ensure reliability.
- Conduct single point of failure exercises and “WarGames” to reveal weak spots and practice incident handling.
- Act on findings; documentation alone is insufficient without remediation.
Handling Legacy System Deprecation
- Often new systems are built but old legacy systems remain active causing confusion.
- Plan to aggressively deprecate old legacy systems in small batches using strategies like the strangler fig pattern.
- Decouple and abstract logic to facilitate incremental replacement.
- Use feature flags to toggle between old and new systems safely.
- Keep documentation simple and clear to explain decisions and avoid repeated mistakes.
- Mirror traffic or double-write to compare legacy and new databases.
Post-Refactoring Maintenance
- Treat codebase as a garden:
- Pull weeds = delete dead code regularly.
- Trim overgrowth = avoid bloat.
- Leave space for new growth = anticipate new features and expansions.
- Avoid recreating legacy by maintaining clean, concise, well-documented code.
Key Takeaways (TL;DR)
- Define one clear problem before refactoring.
- Always have a solid testing safety net; auto-generate tests when possible.
- Prioritize resilience over absolute reliability—expect failures and plan for them.
- Plan and execute aggressive deprecation of legacy systems in manageable increments.
- "Fire" (removing legacy code rapidly) is a tool, not a strategy; aim for code quality that negates the need for fire.
---
Actionable Items / Tasks from the Transcript:
- Define a clear, singular objective for legacy code removal projects.
- Implement automated metric gathering and dashboards for stakeholder communication.
- Establish strong automated testing, including unit tests and coverage analysis.
- Use tools like Chrome DevTools coverage tab and static code analyzers to identify unused code.
- Evaluate and minimize dependencies; consider writing small utility functions versus importing large packages.
- Generate tests automatically via browser tooling and AI assistance but always review them.
- Implement resilience strategies: monitoring, retry mechanisms, backups, soft deletes, audit trails, idempotent operations.
- Regularly test backup recovery on staging environments.
- Conduct single point of failure exercises and WarGames to prepare for incident handling.
- Plan and execute aggressive deprecation of legacy systems incrementally (using patterns like strangler fig).
- Document engineering decisions clearly in concise one-pagers.
- Maintain the codebase continuously like a garden to prevent future legacy accumulation:
- Remove dead code regularly.
- Avoid bloat.
- Keep code clean and concise.
Kill It With Fire a.k.a. Declutter Your Web Codebase
12:00 - 12:30, 27th of May (Tuesday) 2025 / DEV ARCHITECTURE STAGE
Is your codebase so tangled that even adding a simple console.log feels like performing open-heart surgery on Frankenstein’s monster? In this talk, we’ll explore proven ways to declutter and streamline your web projects. From detecting and pruning leftover JavaScript you thought you “might need someday,” to simplifying logic with modern browser features, catching unused imports, and removing old polyfills that are only collecting dust, you’ll learn practical tips and tools that make your code cleaner, simpler, and far less error-prone. We’ll also show how to remove colossal dependencies and other hidden gremlins so your codebase stays lean. At the end of the day, fewer lines really do mean fewer headaches—so let’s cut the bloat and get back to coding without a scalpel in hand!