Refactoring Go in Large Codebases
summary
Argues against rewrites with three concrete reasons: hidden migration and maintenance cost, production edge cases encoded in messy code, and learning-new-tech risk that delays delivery. Lays out a systematic refactor checklist: add characterization tests, normalize error handling, break large interfaces, narrow dependencies with dependency injection, split API and DB models, and extract mutable business rules into services. Prioritizes work by impact versus effort and shows automation with the GitHub Copilot coding agent to create PRs for test coverage, error standardization, and mock-library swaps.
AI-written summary · about
chapters (6)
- 0:00Introduction
- 2:55Why refactor, not rewrite
- 7:30Systematic refactoring
- 16:31Prioritizing technical debt
- 18:22Using AI for refactoring
- 21:45Recap and conclusion
related talks
50mRefactoring Is Not Just Clickbait
50mGuide Refactorings With Behavioral Code Analysis
29mThink Pragmatically: Elevating Your Go Development Skills
01h 17mRefactoring the ROI of Software
36mRewrite, Rework or Refactor
47mPrioritization, Refactoring, and Keeping You Codebase Healthy
47mHow to Fix Your Technical Debt Dilemma
40mHow to sell a big refactor or rewrite to the business?