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

Being Imperfect In A Perfect World

Abizer Nasir
September 21, 2016

Being Imperfect In A Perfect World

Just some thoughts on the choices we make about the patterns we use in development.

Presented at NSBarcelona September 2016

Abizer Nasir

September 21, 2016
Tweet

More Decks by Abizer Nasir

Other Decks in Programming

Transcript

  1. DESIGN PATTERNS AND BEST PRACTICES
    Abizer Nasir | @abizern | abizern.org

    View Slide

  2. BEING IMPERFECT
    IN A PERFECT
    WORLD

    View Slide

  3. THE PERFECT WORLD
    ▸ Tutorials
    ▸ Technical presentations
    ▸ WWDC
    ▸ Our Friends

    View Slide

  4. !

    View Slide

  5. OUR WORLD
    ▸ Nothing works?
    ▸ Autolayout, View hierarchies, Threading, Networking,
    Dependencies...
    ▸ PC Load Letter?! (If you’ve seen Office Space, you know what this
    means)

    View Slide

  6. !

    View Slide

  7. Everything is so hard, maybe I should do things differently?

    View Slide

  8. !

    View Slide

  9. TEMPTATIONS
    ▸ I’m having problems with this, maybe I should try...
    ▸ My friend said X is awesome, I’m going to use it!
    These are not necessarily bad, but doing things in the heat of the
    moment is usually a bad idea.

    View Slide

  10. MY BACKGROUND
    ▸ I’ve been a professional programmer since 2010.
    ▸ I’ve always been a contractor.
    ▸ I’ve worked day rate and hourly.
    ▸ I’ve worked solo and in teams.
    ▸ I’ve spent 12 months pair programming.

    View Slide

  11. WHAT I’VE LEARNED:
    1. Keep it simple.
    2. Simple doesn’t mean easy.

    View Slide

  12. View Slide

  13. View Slide

  14. SIMPLE

    View Slide

  15. EASY

    View Slide

  16. There is nothing wrong with doing things the easy way, as long as you
    do it by choice, not just because...

    View Slide

  17. HOW DO I KNOW
    WHICH TO USE?

    View Slide

  18. !

    View Slide

  19. There is a reason bad practices are known as “code smells”.

    View Slide

  20. WE LEARN TO RECOGNISE SMELLS, WITH PRACTICE AND
    INTUITION
    ▸ Repeated code.
    ▸ Leaky abstractions.
    ▸ UserDefaults used to store state.
    ▸ AppDelegate used as a Singleton.

    View Slide

  21. MVC

    View Slide

  22. MVC
    ▸ The first pattern we learned as developers
    ▸ Used almost everywhere, but it is not the only pattern.
    ▸ Massive View Controller

    View Slide

  23. “I FIND IT HARD TO TEST MY
    MODELS AND VIEW
    CONTROLLERS”

    View Slide

  24. MVVM

    View Slide

  25. “MY VIEW CONTROLLER DOES
    TOO MUCH”

    View Slide

  26. VIPER

    View Slide

  27. “I’M WRITING TOO MUCH
    GLUE CODE FOR
    INTERACTIONS”

    View Slide

  28. REACTIVE

    View Slide

  29. We don’t have to do this sort of thing.
    We can if we want to, but we don’t have to.
    This isn’t the Perfect World that was sold to us. Nothing is perfect.
    We have to find a way to live in the imperfect world.

    View Slide

  30. REMEMBER WHEN I SAID I WAS A CONTRACTOR?
    ▸ The code I’m working on is usually not started or finished by me.
    ▸ I don’t want to leave someone else with the constraints I’ve chosen.
    ▸ I tend to avoid clever code. I use what the system provides as much
    as possible.
    ▸ I started working on my own, not in a team, which is why I have
    opinions.

    View Slide

  31. I LIKE TO KEEP THINGS SIMPLE
    ▸ I use MVC, The observer pattern, façade, Dependency Injection.
    ▸ Probably a whole lot of other patterns that I don’t know the names of
    - I’m not Computer Science educated.
    ▸ I avoid third party omni dependencies.
    ▸ I try and use third party code that I understand and can fix.
    ▸ I sound like an Apple fanboi.

    View Slide

  32. TESTING MODELS AND VIEW CONTROLLERS?
    ▸ I use dependency injection and TDD.
    ▸ Swift is really handy for default parameters that allow injection for
    tests.
    ▸ I live without 100% test coverage.

    View Slide

  33. VIEW CONTROLLERS DO TOO MUCH?
    ▸ A view controller is supposed to control a view.
    ▸ Everything else can get passed off.
    ▸ Delegation (or even closures) for performing work related to views.
    ▸ Data sources don’t have to be in the view controller.
    ▸ Having separate subsystems makes them easier to test.

    View Slide

  34. TOO MUCH GLUE CODE FOR INTERACTIONS?
    ▸ Swift makes this easier with property observers.
    ▸ There’s also Key-Value Observing for NSObject based classes.
    ▸ The functional paradigm that made MVVM and Reactive attractive to
    me are now available in Swift.
    ▸ I use Core Data - plenty of change notifications there.

    View Slide

  35. “BUT I WANT TO LIVE IN A
    PERFECT WORLD”

    View Slide

  36. Congratulations! These new patterns (or architectures whatever you
    like to call them) are perfectly fine and supported.

    View Slide

  37. When the time comes to learning them, remember they are just MVC in
    different clothes - there is a defined flow of data and responsibilities.

    View Slide

  38. If you work in a team, get them on board, make sure they are
    enthusiastic, or you’ll spend most of your time justifying your choices
    rather than using them.

    View Slide

  39. You don’t have to use them everywhere, You can use a different pattern
    for different flows - You have a nose!

    View Slide

  40. It’s a good idea to actually try them in a play project.
    Just remember - real apps live in an imperfect world.

    View Slide

  41. !

    View Slide

  42. SWIFT

    View Slide

  43. YES
    YES
    YES

    View Slide

  44. THE GOOD
    ▸ No more breaking changes.
    ▸ Simpler, right now it’s not easier !.
    ▸ It’s the future. And I don’t just mean our platforms.

    View Slide

  45. THE BAD
    ▸ A lot of examples and blog posts are in the perfect world:
    ▸ JSON Parsers.
    ▸ Autolayout DSLs.
    ▸ Generics make code simple, harder to understand at first.
    ▸ Lot’s of new names, who do you believe?

    View Slide

  46. THE UGLY
    ▸ It’s still not done yet.
    ▸ Open Source, will we see design by committee? Forks?

    View Slide

  47. TAKE THE BITS YOU
    UNDERSTAND AND USE THEM
    TILL YOU GET BETTER.

    View Slide

  48. SUMMARY
    ▸ Code, examples, talks, all speak of a perfect world.
    ▸ Our daily work has to survive in the imperfect world.
    ▸ Don’t just believe the hype. You’ve developed engineering skills: use
    them.

    View Slide

  49. THANK YOU
    ABIZER NASIR | @ABIZERN | ABIZERN.ORG

    View Slide