Limits of Modularity

Transcript

1. The Limits of Modularity Samuel Giddins
2. Samuel Giddins Realm CocoaPods Bundler RestKit
3. Bundler & CocoaPods Two Dependency Managers
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
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 beautifully!
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 changes
45. But N levels deep, every change at the bottom is drastic
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 mono-repos
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