Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Limits of Modularity
Samuel E. Giddins
May 19, 2015
Technology
0
62
Limits of Modularity
Samuel E. Giddins
May 19, 2015
Tweet
Share
More Decks by Samuel E. Giddins
See All by Samuel E. Giddins
Empowering iOS Developers
segiddins
1
52
Empowering iOS Developers
segiddins
0
320
Making CocoaPods Fast (with Modern Ruby Tooling)
segiddins
0
14
Making CocoaPods Fast
segiddins
0
230
Answering the Existential Question
segiddins
0
27
Scaling CocoaPods
segiddins
0
33
Building Swift Static Libraries
segiddins
0
260
Apple Radar: how it works & how to file one
segiddins
0
48
Exploring Clang Modules
segiddins
3
1.2k
Other Decks in Technology
See All in Technology
アルプの 認証/認可分離戦略と手法
ma2k8
PRO
2
360
[SRE NEXT 2022]組織に対してSREを適用するとはどういうことか
srenext
0
470
信頼性の階層の一段目を積み上げる/Monitoring Dashboard
shonansurvivors
0
180
1年間のポストモーテム運用とそこから生まれたツール sre-advisor / SRE NEXT 2022
fujiwara3
6
3.6k
アルプでのAgile Testing / Alp Agile Testing
nametake
0
330
Server-side Kotlin in LINE Messaging API
line_developers
PRO
0
170
我々はなぜテストをするのか?
kawaguti
PRO
0
590
プルリク作ったらデプロイされる仕組み on ECS / SRE NEXT 2022
carta_engineering
1
560
AWS CLI入門_20220513
suzakiyoshito
0
4k
[SRE NEXT 2022]KaaS桶狭間の戦い 〜Yahoo! JAPANのSLI/SLOを用いた統合監視〜
srenext
0
570
動的ルーティング・ゲートウェイ (DRG) 概要
ocise
0
110
2022年最新版 GatsbyJS + TypeScript + microCMS でブログを作る。
hanetsuki
1
210
Featured
See All Featured
Web Components: a chance to create the future
zenorocha
303
40k
Why Our Code Smells
bkeepers
PRO
324
54k
Producing Creativity
orderedlist
PRO
333
37k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
226
15k
How to name files
jennybc
39
59k
4 Signs Your Business is Dying
shpigford
169
20k
A Philosophy of Restraint
colly
192
14k
Scaling GitHub
holman
451
140k
Rebuilding a faster, lazier Slack
samanthasiow
62
7.2k
Practical Orchestrator
shlominoach
178
8.6k
The Web Native Designer (August 2011)
paulrobertlloyd
74
1.9k
Intergalactic Javascript Robots from Outer Space
tanoku
261
25k
Transcript
The Limits of Modularity Samuel Giddins
Samuel Giddins Realm CocoaPods Bundler RestKit
Bundler & CocoaPods Two Dependency Managers
None
• 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
Let’s take a peek at the architecture behind CocoaPods
None
In an iOS App
Let’s start at the networking layer
We have ’s NSURLConnection / NSURLSession to base things off
of So far, so good
We then use JXHTTP or AFNetworking, since both provide some
features and a nicer API
We then make a TMAPIClient (inside a pod called TMTumblrSDK),
since we want to abstract away the network calls we make
We then make a TumblrCore pod, to be able to
share code between our app and its extensions
And now, we have Tumblr.app! Whew.
That’s what’s called a deep dependency graph.
aside: Those things are really hard to fully ‘resolve’ It’s
a problem I’ve sunk many hours into
So, this is great! We’ve re-used lots of code, made
things modular, ‘componentized’ everything... Life is wonderful!
Until...
We need to change things. (And yes, this is where
we get to the interesting parts)
Let’s say we want to update our UI to show
upload progress for a new post
(I went through nearly this exact scenario when I worked
on the Tumblr app)
OK, so the first step is going to be figuring
out where, exactly, in this stack we can even start.
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.
I just need to rearchitect sockets and everything will work
beautifully!
Have fun.
Well, I just need to swizzle these three methods, and
I can do everything in my app!
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!?
Again & Again & Again
So we settle upon making this change inside JXHTTP. Excellent.
@property JXHTTPRequestProgressBlock progressBlock;
While we're in there, we choose to move a few
things around to make adding support for that progressBlock easier.
And this is great! !
So now we release a new minor version, and go
back up one level to incorporate those changes.
s/~> 1.2.4/~> 1.3.0
And our tests now fail !
Imagine this happening all the way up the dependency chain
Dependency Paralysis
When our frameworks aren't perfect, the gaps between them can
easily fissure
And our frameworks are never perfect
Edge cases and implicit assumptions propogate through each dependency
One subtle change can be in just the wrong place
And everything collapses
Our usual measures for keeping things sane & safe will
work against us
• Tests • Documentation • Encapsulation • Stable releases
All of those work by applying the brakes on drastic
changes
But N levels deep, every change at the bottom is
drastic
And you'll find that almost every change requires touching something
near the bottom
We also have to decide where to put everything
And choosing wrong? => !
We hear stories of Facebooks and the like with their
mono-repos
And all of this is why Move fast vs. being
"really" modular
So, Samuel, what's the right answer?
Available now on Speaker Deck. https://speakerdeck.com/segiddins/limits-of-modularity
for (Question *question in self.audience.questions) { NSLog(@"%@", [[question ask] valueForKey:@"answer"]);
}
Samuel Giddins Realm @segiddins