On the journey from legacy code to clean architecture

Presented with Joe Birch

Buffer for Android was first made in 2012 - and since then it's seen a range of iterations and features. Whilst it's important for a product to grow in-order to meet the needs of users, it's easy for code to become unclean and lose any sense of architecture. This legacy code makes it difficult for us to maintain our product and build new features without the fear of breaking the app.

But there is light! At Buffer we've just started to re-architect and refactor our application for Android using a clean architecture approach. Re-crafting our application feature by feature with the help of RxJava, Dagger and tests in the form of jUnit and Espresso has began to result in a more stable, better architected and maintainable codebase. Together with our new Continous Integration flow this all helps in providing a better Buffer experience on Android.

In this talk we will explore the journey we took through refactoring from legacy code to a clean architecture. Starting with heart of our app, the Composer, we'll share our learnings and findings discovered on our journey and the benefits from doing so.

Transcript

1. On the journey from legacy code to clean architecture by Joe Birch & Marcus Wermuth a.k.a The Android Team at Buffer
2. About us ‣ Android Developers at Buffer [buffer.com] ‣ Combining Architecture, Testing skills with Generalist Product and Design thinking ‣ @hitherejoe, @mwermuth at Twitter/Github
3. Journey ‣ Introduction to Buffer ‣ History of our Android App ‣ Rebuilding our Composer ‣ Clean Architecture ‣ Continuous Integration
4. ‣ Social media management tool + Customer service software [buffer.com/respond] ‣ over 4M Users in total ‣ over 800,000 posts shared a day About Buffer
5. ‣ 78 employees ‣ 100% working remotely
6. Our values
7. Buffer for Android ‣ around since 2012 ‣ ~150k Lines of Code ‣ 43k updates created daily ‣ minSdkVersion: 15
8. Challenges ‣ GodActivites everywhere ‣ no consistency in style ‣ old unsupported libraries ‣ no testing, no CI
10. Lookback
11. Lookback
12. Lookback
13. Lookback
14. Lookback
15. Lookback
16. How did we do all this?
17. Complexities ‣ A lot of different features ‣ Social network data types ‣ No structure ‣ No tests
19. Complexities ‣ A lot of different features ‣ Social network accepted data types ‣ No structure ‣ No tests
21. Complexities ‣ A bunch of different features ‣ Social network accepted data types ‣ No structure ‣ No tests
22. And so the journey begins…
26. Clean Architecture
27. Reactive Approach
31. Use Case Repository Remote Local Data Store Factory
32. Now we have tests! ‣ UI tests for activities and fragments ‣ Unit Tests for Use Cases, Repository classes and pretty much any class that can be tested ‣ From 0 to over 400 unit tests
36. Android Architecture Blueprints GitHub - googlesamples/android-architecture Blueprints Architecting Android…The clean way? Fernando Cejas - http://fernandocejas.com/ Android-CleanArchitecture Github - android10/Android-CleanArchitecture
37. How do we use those tests and deploy the app?
38. Want did we want? ‣ stable and easy way to run a build ‣ decentralised ‣ automated ‣ easy to understand and modify
39. Tools http://danger.systems http://www.vysor.io
40. Our Git “Flow”
41. PR Health Check
42. Release Process
43. Device Tests ‣ being remote makes it hard ‣ Firebase Test Lab
44. Thanks :) @hitherejoe - @mwermuth