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

Re-Architecting Applications (Without a Rewrite!)

Daniel Lew
February 10, 2018

Re-Architecting Applications (Without a Rewrite!)

Talk given at DevFestMN 2018 & MinneBar 13.

Recording here: https://youtu.be/dKm7MKoxVIg

Daniel Lew

February 10, 2018
Tweet

More Decks by Daniel Lew

Other Decks in Programming

Transcript

  1. Re-architecting Applications (Without a Rewrite!)
    @danlew42

    View Slide

  2. architecture: the structure and
    design of a system or product

    View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. “Model-View-
    Controller is the
    best thing since
    sliced bread.”
    ~Evil Dan Lew

    View Slide

  9. “OMG, I’m
    switching to MVC
    ASAP!”
    ~You
    Stability
    Some New
    Architecture

    View Slide

  10. Danger
    • Pure architectures require fresh code

    • Rewrites always take longer than expected

    • Old code == battle tested

    • Expectations may not match reality

    View Slide

  11. Goals
    • Introduce new architectures to existing codebase

    • Push releases while re-architecting codebase

    View Slide

  12. View Slide


  13. View Slide

  14. Goal #1:
    Introduce new architectures to
    existing codebase

    View Slide

  15. Re-Architecting Safely
    • Prevent overly ambitious rewrites

    • Prevent regrettable architecture choices

    • Steps

    • Explore

    • Experiment

    • Expand

    • Embrace

    View Slide

  16. Explore
    • What is the problem?

    • Define goals

    • Define constraints

    • What are the solutions?

    • Brainstorm

    • Research

    View Slide

  17. Experiment
    • Pick a project

    • Minimize work

    • Small project

    • Simplified implementations

    • Minimize damage

    • Self-contained project

    • Unimportant project

    View Slide

  18. Expand
    • Run more experiments

    • Pick projects wisely

    • Use architecture in new ways

    • Pick hardest problems

    • Stretch architecture to limits

    View Slide

  19. Embrace
    • Write all new code with new architecture

    • Deprecate old architecture

    • Delete old code (optional)

    View Slide

  20. Disclaimer
    Not an exact science

    View Slide

  21. Goal #2:
    Push releases while re-architecting
    codebase

    View Slide

  22. Can’t simultaneously use old
    and new architecture
    Can’t keep releasing

    View Slide

  23. Old
    New
    Old + New

    View Slide

  24. Parallel Development

    View Slide

  25. Decouple Code
    BAD GOOD

    View Slide

  26. Feature Flags

    View Slide

  27. Shims

    View Slide

  28. Shims

    View Slide

  29. Offline Mode
    A parallel development success story

    View Slide

  30. Online Only Offline Enabled

    View Slide

  31. Decoupling Services
    Before After

    View Slide

  32. Feature Flags

    View Slide

  33. Shims
    Before After

    View Slide

  34. Offline Mode
    • Project length: 1.5 years

    • Never stopped releasing

    • Minimal UI changes

    • Gradual experimentation via flags

    • Switched over without anyone noticing

    • https://tech.trello.com/sync-architecture/

    View Slide

  35. Failures
    With real life examples!

    View Slide

  36. Explore Failures
    • Architecting with no purpose

    • Navi

    • Choosing new and shiny without understanding

    • RxJava

    View Slide

  37. Experiment Failures
    • Making the experiment too large

    • JavaScript: The Good Parts

    • Not recognizing a failed experiment

    • Operations

    View Slide

  38. Expand Failures
    • Choosing only easy problems

    • Identifiers

    • Not recognizing a failed corner case

    • RxLifecycle

    View Slide

  39. Embrace Failures
    • Continuing to expend effort on old architecture

    • Fresh boards

    View Slide

  40. Pet Peeve
    Telling everyone about an architecture
    before proving it out!

    View Slide

  41. Current Architecture Thoughts

    View Slide

  42. Omni Models
    • Single model

    • Deserialized from JSON

    • Written to ORM

    • Used by UI

    • Problems

    • Which fields are present?

    • How do we avoid mutability issues?

    View Slide

  43. Domain-specific models
    • ApiModel

    • Only used when talking to server

    • DbModel

    • Mutable, flexible

    • UiModel

    • Immutable, guarantees values

    • ApiModel <-> DbModel <-> UiModel

    View Slide

  44. Unidirectional Architecture

    View Slide

  45. Thanks for listening!
    @danlew42

    View Slide