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

Limits of Modularity

Limits of Modularity

Samuel E. Giddins

May 19, 2015

More Decks by Samuel E. Giddins

Other Decks in Technology


  1. The Limits of Modularity Samuel Giddins

  2. Samuel Giddins Realm CocoaPods Bundler RestKit

  3. Bundler & CocoaPods Two Dependency Managers

  4. None
  5. • ruby -e "$(curl -fsSL https:// raw.githubusercontent.com/Homebrew/install/master/ install)" • brew

    install python • easy_install pip • pip install pygments • brew install rbenv ruby-install • rbenv install 2.2.2 • gem install pygments.rb
  6. Let’s take a peek at the architecture behind CocoaPods

  7. None
  8. In an iOS App

  9. Let’s start at the networking layer

  10. We have ’s NSURLConnection / NSURLSession to base things off

    of So far, so good
  11. We then use JXHTTP or AFNetworking, since both provide some

    features and a nicer API
  12. We then make a TMAPIClient (inside a pod called TMTumblrSDK),

    since we want to abstract away the network calls we make
  13. We then make a TumblrCore pod, to be able to

    share code between our app and its extensions
  14. And now, we have Tumblr.app! Whew.

  15. That’s what’s called a deep dependency graph.

  16. aside: Those things are really hard to fully ‘resolve’ It’s

    a problem I’ve sunk many hours into
  17. So, this is great! We’ve re-used lots of code, made

    things modular, ‘componentized’ everything... Life is wonderful!
  18. Until...

  19. We need to change things. (And yes, this is where

    we get to the interesting parts)
  20. Let’s say we want to update our UI to show

    upload progress for a new post
  21. (I went through nearly this exact scenario when I worked

    on the Tumblr app)
  22. OK, so the first step is going to be figuring

    out where, exactly, in this stack we can even start.
  23. Start in the wrong place, and you’ll be working at

    the wrong level of abstraction, and you’ll be contorting to even make simple changes.
  24. I just need to rearchitect sockets and everything will work

  25. Have fun.

  26. Well, I just need to swizzle these three methods, and

    I can do everything in my app!
  27. And again in my share extension. And then again in

    the right place because who in their right mind wants to swizzle the same method in three places!?
  28. Again & Again & Again

  29. So we settle upon making this change inside JXHTTP. Excellent.

    @property JXHTTPRequestProgressBlock progressBlock;
  30. While we're in there, we choose to move a few

    things around to make adding support for that progressBlock easier.
  31. And this is great! !

  32. So now we release a new minor version, and go

    back up one level to incorporate those changes.
  33. s/~> 1.2.4/~> 1.3.0

  34. And our tests now fail !

  35. Imagine this happening all the way up the dependency chain

  36. Dependency Paralysis

  37. When our frameworks aren't perfect, the gaps between them can

    easily fissure
  38. And our frameworks are never perfect

  39. Edge cases and implicit assumptions propogate through each dependency

  40. One subtle change can be in just the wrong place

  41. And everything collapses

  42. Our usual measures for keeping things sane & safe will

    work against us
  43. • Tests • Documentation • Encapsulation • Stable releases

  44. All of those work by applying the brakes on drastic

  45. But N levels deep, every change at the bottom is

  46. And you'll find that almost every change requires touching something

    near the bottom
  47. We also have to decide where to put everything

  48. And choosing wrong? => !

  49. We hear stories of Facebooks and the like with their

  50. And all of this is why Move fast vs. being

    "really" modular
  51. So, Samuel, what's the right answer?

  52. Available now on Speaker Deck. https://speakerdeck.com/segiddins/limits-of-modularity

  53. for (Question *question in self.audience.questions) { NSLog(@"%@", [[question ask] valueForKey:@"answer"]);

  54. Samuel Giddins Realm @segiddins