Question 1
Large-scale refactor strategy
You inherit a large, messy codebase that's slowing the team down. How do you approach refactoring it without halting feature development?
Answer outline
Start with the highest-pain areas and establish baselines before you touch anything, so you can judge whether the refactor is working. Four signals point at the right places:
- 1.Slow iteration: features that take days longer than they should because every change touches 10 files.
- 2.Crash-prone code: areas that keep showing up in crash reports and incident reviews.
- 3.Tangled dependencies: modules that can't be built, tested, or understood in isolation.
- 4.Hard-to-test flows: logic that only runs through the UI, so nobody writes tests for it.
Work incrementally alongside feature development instead of pausing the roadmap. The best time to improve an area is when the team is already working in it. Attach the cleanup to that feature work.
Aim for clearer boundaries and better testability, and resist the pull toward a full rewrite. Separate networking, persistence, and view model concerns first, then clean up internals. Leave each area better than you found it, and measure again so you know when you're done.
Principles
- Go after the highest-pain areas rather than aesthetics or code style.
- Refactor incrementally as you deliver features, so the roadmap never has to stop.
- Avoid full rewrites: they run long, lose context, and the same problems resurface.
- Draw boundaries between networking, persistence, and view models before you polish anything inside them.
- Measure before and after so the refactor has a clear definition of done.
