Controlling complexity for large iOS projects

Slide 1

Slide 1 text

Controlling complexity for large iOS projects Petro Korienev, iOS Engineer @ Techery

Slide 2

Slide 2 text

DISCLAIMER

Slide 3

Slide 3 text

• Sporadic crashes • Intermittent issues • Hardly debuggable code PROBLEMS WHILE SCALING

Slide 4

Slide 4 text

• Moore’s law (hardware’s getting twice faster every 2 years) WHY DOES IT HAPPEN? • Wirth’s law (software’s getting slower faster than hardware’s getting faster)

Slide 5

Slide 5 text

SO WHY?

Slide 6

Slide 6 text

FEW SLOC FACTS

Slide 7

Slide 7 text

• Complexity growth with time SO,

Slide 8

Slide 8 text

• Control decreases over time • Consequence of growing complexity • Maintainer change • Software is not an IP carrier, author is

Slide 9

Slide 9 text

Here comes TRUST

Slide 10

Slide 10 text

• Trust in community and time-proven solutions • Trust in self TRUST

Slide 11

Slide 11 text

• AFNetworking 2.5.1-2.5.2 • OpenSSL heartbleed • Numerous zero-day exploits • Just bugs TRUST IN COMMUNITY

Slide 12

Slide 12 text

• “I’ve seen stuff like this before” • “This is pretty straightforward” • “If i’d do stuff like this, i’d do this way” TRUST IN SELF

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

• Bugs • Exploits • Limitations • Tech debt Consequences

Slide 15

Slide 15 text

Prefer control over trust CAPTAIN’S VOICE:

Slide 16

Slide 16 text

When the code becomes legacy dependency

Slide 17

Slide 17 text

SOLUTIONS 1. Don’t care of it (Blackboxing) 2. Whiteboxing 3. Get rid of dependencies 4. Grayboxing

Slide 18

Slide 18 text

DON’T CARE OF IT • Simple • Unreliable • Tends to consume time when scaling

Slide 19

Slide 19 text

DON’T CARE OF IT

Slide 20

Slide 20 text

WHITEBOXING

Slide 21

Slide 21 text

WHITEBOXING • Very time-consuming • Reliable after certain effort put • Extremely difﬁcult with closed- source

Slide 22

Slide 22 text

GET RID OF DEPENDENCIES

Slide 23

Slide 23 text

GET RID OF DEPENDENCIES

Slide 24

Slide 24 text

GET RID OF DEPENDENCIES • Sometimes is not applicable • Possible even with closed- source • In moderate scale it’s the best approach to take control

Slide 25

Slide 25 text

GRAYBOXING • Good tradeoff between white- and blackboxing • Flexible • Applicable almost everywhere • Dynamic

Slide 26

Slide 26 text

GRAYBOXING • Idea is to ﬁnd a right place and inject something validating the correctness of contract • Unlike unit tests, veriﬁes dynamic, run-time behaviour

Slide 27

Slide 27 text

EXAMPLE • https://github.com/soxjke/ WatchDogs

Slide 28

Slide 28 text

PROBLEM • Inconsistency and mess within CoreData across the project • Fake certainty in thread- access

Slide 29

Slide 29 text

SOLUTION AND DEMO

Slide 30

Slide 30 text

THANK YOU FOR YOUR ATTENTION! Q&A TIME

Slide 31

Slide 31 text

YOU CAN FIND ME: • https://github.com/soxjke • https://twitter.com/soxjke • http://stackoverﬂow.com/users/ 2392973/petro-korienev