Taming Legacy: Refactoring Patterns for Large Flutter Codebases
summary
A case study of a bank codebase shows concrete fixes: a landscape of 50+ Dart packages split across 50 git repositories causes broken workflows and dependency hell, so the team enforces formatting and a custom lint set (including use_design_system_item and shrinkWrap guards), runs codemod scripts to migrate widgets and spacings, duplicates/designs new design-system widgets after a Figma audit, and weighs gradual package-by-package migration versus a weekend big‑bang monorepo move.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:09Legacy Flutter challenges
- 3:15Case study architecture
- 5:03Code quality issues
- 7:36Stopping technical debt
- 10:28Design system consistency
- 13:42Custom lints in poly repos
- 16:15Fixing design components
- 19:48Automated refactoring
- 22:18Dart repo structure
- 24:07Dependency cycles
- 24:27Poly repo workflows
- 28:22Gradual monorepo migration
- 30:31Big bang monorepo migration
- 33:22Refactoring framework
- 36:52Summary
related talks
35mTaming Legacy: Refactoring Patterns for Large Flutter Codebases
30mFlutter at scale-experience from 25+ Flutter Devs working together on a mobile banking app
32mTailoring Flutter Architectures for Team and Business Success
19mEscaping Chaos: Strategies to Move from Polyrepo to Monorepo
44mMultimodule Flutter App
37mLessons learned from crafting an in-house framework
40mArchitecture: The LeanCode Guide
20mCode Quality Gates for Large-Scale Flutter Apps