Upgrade to Pro — share decks privately, control downloads, hide ads and more …

On the journey from legacy code to clean architecture

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.

657432c7d84826ea3642336a8c8c6edc?s=128

Marcus Wermuth

December 15, 2016
Tweet

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
  9. None
  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
  18. None
  19. Complexities ‣ A lot of different features ‣ Social network

    accepted data types ‣ No structure ‣ No tests
  20. None
  21. Complexities ‣ A bunch of different features ‣ Social network

    accepted data types ‣ No structure ‣ No tests
  22. And so the journey begins…

  23. None
  24. None
  25. None
  26. Clean Architecture

  27. Reactive Approach

  28. None
  29. None
  30. None
  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
  33. None
  34. None
  35. None
  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