Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Working effectively at scale
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Francisco Díaz
November 29, 2019
Programming
4
300
Working effectively at scale
Presented at BA:Swiftable in November, 2019.
Francisco Díaz
November 29, 2019
Tweet
Share
More Decks by Francisco Díaz
See All by Francisco Díaz
Inteligencia Artificial en PedidosYa - Una mirada pragmática
fdiaz
0
9
I hate public speaking. So why do I keep doing it?
fdiaz
0
140
Definiendo límites
fdiaz
1
130
Si odio hablar en público. ¿Por qué lo sigo haciendo?
fdiaz
2
150
Move fast and keep your code quality
fdiaz
1
390
De qué hablo cuando hablo de trabajo remoto
fdiaz
1
150
Setting Boundaries
fdiaz
1
160
Swift Values
fdiaz
0
140
Sisifo o Cómo empezar de nuevo - y otra vez.
fdiaz
0
140
Other Decks in Programming
See All in Programming
ELYZA_Findy AI Engineering Summit登壇資料_AIコーディング時代に「ちゃんと」やること_toB LLMプロダクト開発舞台裏_20251216
elyza
2
1.3k
Architectural Extensions
denyspoltorak
0
250
16年目のピクシブ百科事典を支える最新の技術基盤 / The Modern Tech Stack Powering Pixiv Encyclopedia in its 16th Year
ahuglajbclajep
5
940
MDN Web Docs に日本語翻訳でコントリビュート
ohmori_yusuke
0
610
CSC307 Lecture 06
javiergs
PRO
0
670
2年のAppleウォレットパス開発の振り返り
muno92
PRO
0
190
Claude Codeの「Compacting Conversation」を体感50%減! CLAUDE.md + 8 Skills で挑むコンテキスト管理術
kmurahama
1
820
副作用をどこに置くか問題:オブジェクト指向で整理する設計判断ツリー
koxya
1
560
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
170
プロダクトオーナーから見たSOC2 _SOC2ゆるミートアップ#2
kekekenta
0
120
AIエージェントの設計で注意するべきポイント6選
har1101
7
3.3k
それ、本当に安全? ファイルアップロードで見落としがちなセキュリティリスクと対策
penpeen
7
2.4k
Featured
See All Featured
The Mindset for Success: Future Career Progression
greggifford
PRO
0
220
The Pragmatic Product Professional
lauravandoore
37
7.1k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
How to Ace a Technical Interview
jacobian
281
24k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.3k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
200
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
55
49k
Building Applications with DynamoDB
mza
96
6.9k
For a Future-Friendly Web
brad_frost
181
10k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Transcript
Working e!ectively at scale
Francisco Díaz franciscodiaz.cl - @fco_diaz
Startups 2011 - 2017
Airbnb 2017 - today
None
None
None
None
None
None
None
None
None
organizations ... are constrained to produce designs which are copies
of the communication structures of these organizations — Conway's law
How do you divide your codebase?
Architectural layer
User Flow
What about Airbnb?
None
1 million lines of Swift
~80 commits to master on any given day to the
repo (Android + iOS)
Bigger buckets
None
A user should be able to wishlist a listing from
the booking flow
How do they relate with each other?
None
None
None
50 min local clean builds
~30 min !
Buck HTTP Cache https://github.com/airbnb/BuckSample
None
~5 min !
None
None
Dependency inversion
‣High-level modules should not depend on low- level modules. Both
should depend on abstractions. ‣Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
None
A user should be able to wishlist a listing from
the booking flow
None
Easy! WishListDataSource + interface!
None
WishListDataSource is still visible
None
Socializing best practices
!
+60 iOS developers
Automating best practices
Groups Modules
Groups Modules Module Types
Module Types Feature + Interface Service + Interface
Feature A screen or a flow in the app
Service Manage shared state or resources
None
None
How do we enforce these best practices?
/services /service_interfaces /features /feature_interfaces
def service_interface( name, deps): max_visibility = [ "//ios/feature_interfaces/...", "//ios/features/...", "//ios/service_interfaces/...",
"//ios/services/...", ]
service_interface( name = "Networking", deps = [ "//ios/service_interfaces/Logging", ], )
feature( name = "Booking", deps = [ "//ios/service_interfaces/Networking", "//ios/service_interfaces/WishListService", ],
)
iOS Platform
Module creation needs to be easy
None
None
rake make:module
> Provide the type of module you want to create:
1: Non Platform 2: Feature 3: Feature Interface 4: Service 5: Service Interface 4 > New module name: Swiftable > Provide a high level description of this module: This is a module to present at Swiftable
Buck Human readable dependencies https://github.com/airbnb/BuckSample
feature( name = "Booking", deps = [ "//ios/service_interfaces/Networking", "//ios/service_interfaces/WishListService", "//ios/feature_interfaces/HelpCenter",
], )
None
Feature A screen or a flow in the app
None
None
None
Dev Apps
~1 min Dev Apps
Big buckets Small playgrounds
None
How do we get there?
~100 modules One module type: /libraries
libraries/AirbnbBooking libraries/AirbnbBusinessTravel libraries/AirbnbHelpCenter libraries/AirbnbListings libraries/AirbnbNetworking libraries/AirbnbWishLists ...
Before iOS Platform /libraries
On the iOS Platform /services /service_interfaces /features /feature_interfaces
How to get everybody on the iOS Platform?
Remove libraries/ and start over
!
Progressively migrate
Let's migrate WishLists Data Source
libraries/WishLists
None
None
None
What are the dependency rules for libraries/?
None
Inbound dependencies Outbound dependencies
Inbound dependencies Outbound dependencies
None
The interface module has stricter rules
Migrate all the call sites
As the owner of WishLists We don't control these
None
Calculated tech debt
Inbound dependencies Outbound dependencies
None
we know our usage of Networking
We control our dependencies
Allow inbound dependencies from libraries/ Don't allow outbound dependencies to
libraries/
libraries/ has access to the iOS Platform
The iOS Platform doesn't have access to libraries/
Code on the iOS Platform has good boundaries
while we allow for easier migration
def service_interface( name, visibility = []): max_visibility = [ "//ios/feature_interfaces/...",
"//ios/features/...", "//ios/service_interfaces/...", "//ios/services/...", ] add_visibility_for_legacy_module_structure(max_visibility)
def add_visibility_for_legacy_module_structure(visibility): visibility.extend([ "//ios/libraries/...", ])
We started migrating from the bottom up
Try it ourselves !rst
Pilot with others teams
Should I implement this?
Most likely NO
There's no silver bullet
Adapt
Summary 1. Figure out where you're struggling 2.Create and document
best practices 3.Automate best practices where needed
¡Gracias! franciscodiaz.cl/talks