Marcin Chudy

Flutter quickly became a solid technology to use in large-scale enterprise apps. However, as projects grow over time and developers are met with tight deadlines, we stumble upon the inevitable challenges related to dealing with legacy Flutter code. This is what I experienced firsthand while working on multiple projects across various business domains. In this talk, I will walk you through some real-life examples of how Flutter codebases can deteriorate over time and how we effectively refactor them. We’ll tackle duplicated code, tight coupling, the lack of reusable widgets, chaotic state management, polyrepo workflow issues and much more. We’ll try to stay pragmatic though. As halting the development completely to do total refactoring is rarely an option, I would like to show strategies that can quickly bring real value without disrupting the work of the whole development team. Whether you’re just starting your project or inheriting an old codebase, refactoring patterns are a must. Having a deeper knowledge of them will help you create quality future-proof Flutter apps.

In this talk, we'll go through a real-life case of a large banking app developed by 60+ Flutter developers that started as a polyrepo project, with each Dart package being placed in a separate Git repository. As the project grew, this became more and more problematic. The development workflow started being painful, and the main branch was broken most of the time, with developers spending more time solving conflicts and figuring out how to correctly merge all their PRs rather than focusing on delivering actual business value. We're going to analyze all the pain points that we suffered and see how the polyrepo approach compares with monorepo in Flutter projects. Then I'll show you the strategy we took to execute the migration. As we couldn't afford just to hold the development completely to clean everything up, we had to develop a smarter strategy that allowed for a more seamless transition.