BBQ Ribs and Maintainable Mobile Apps

How to create maintainability in your mobile apps.

Transcript

1. February 11, 2015 – Atlanta, Ga BBQ Ribs Maintainable Mobile Apps and
2. TL;DR Maintainability … good DESIGN is a direct result of …
3. Patrick Seda @pxtrick patrickseda@gmail.com •  Independent Mobile App Architect •  Titanium zealot … Appc Titan •  Apps: Enterprise to Children’s games
4. Confession:
6. What Are “Ribs”?
7. Skeletal Muscles External Intercostals Internal Intercostals •  Used for Inspiration •  Pull rib cage upward & outward •  Work in conjunction with diaphragm •  Used for (forced) Expiration •  Pull ribcage inward & downward
8. Skeletal Muscles What does a muscle do? •  Contract (* that’s it)
9. Modeling A Real-world System
10. Biological API SkeletalMuscle { contract(force) relax() } contract(force) = { // complex stuff, e.g. action potential, // T-tubule, actin, myosin, calcium ... }
11. Biological API * Real-world (involuntary) : •  Pulmonary stretch receptors •  Hering - Breuer reflex BrainStem { acquireOxygen(amount, speed) removeCO2() }
12. Breathing BrainStem -  acquireOxygen() - removeCO2()
13. Breathing BrainStem -  acquireOxygen() - removeCO2() ExternalIntercostals -  contract() - relax() Diaphragm -  contract() - relax()
14. Breathing BrainStem -  acquireOxygen() - removeCO2() Cortex -  acquireOxygen() - removeCO2() (voluntary) (involuntary) ExternalIntercostals -  contract() - relax() Diaphragm -  contract() - relax() ?
15. Facade ExternalIntercostals -  contract() - relax() Diaphragm -  contract() - relax() Breathing Lungs -  inhale() - exhale() BrainStem -  acquireOxygen() - removeCO2() Cortex -  acquireOxygen() - removeCO2() (voluntary) (involuntary)
16. ExternalIntercostals -  contract() - relax() Diaphragm -  contract() - relax() Breathing Facade Lungs -  inhale() - exhale() BrainStem -  acquireOxygen() - removeCO2() Cortex -  acquireOxygen() - removeCO2() (voluntary) (involuntary) InternalIntercostals -  contract() - relax() (forced exhale) (normal)
17. Mobile Software Design
18. Software Design Typical Scenario: Cool Feature/Module e.g. iBeacon
19. Software Design Cool 3rd-party modules App Design
20. Software Design Cool 3rd-party modules App Design Ooooooh, yeah
21. Software Design Design First: iBeacon stuff Cool Feature/Module e.g. iBeacon
22. Symptoms of Bad Design Rigidity: Difficult to change, changes cause cascading changes Fragility: Unexpected breakage after a fix Immobility: Not reusable across projects Viscosity: Easy to do the wrong thing, hard to do the right thing
23. Good Design … How? Single Responsibility Principle SOLID Principles Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
24. Good Design … How? GOF Patterns
25. Good Design … How? Ask these 3 questions: “Who should reasonably own this behavior?” “Who should interact with whom?” “Does this make sense?”
26. Good Design … How? Roles & Responsibilities Loose Coupling / Modularity •  Single Responsibility Principle •  Interface Segregation Principle •  Open/Closed Principle •  Liskov Substitution Principle •  Dependency Inversion Principle •  Builder •  Bridge •  Command •  Interpreter •  Proxy •  State •  Strategy
27. How Much Design? BDUF Agile/XP FDUF Everything! Nothing! “How much should we design up front?” Flexible Design Up Front
28. How Much Design? The best predictor of change … “How much should we design up front?” … is previous change.
29. Sample: Utilities
30. Utilities Typical Scenario: We start to recognize some common Utility functionality …
31. Utilities // Utilities Helper { formatSSN(str) handleHTTPError(obj) removeAllChildren(uiView) groupDigits(str, country) formatAsCurrency(str, country) removeAlphaChars(str) validatePhoneNumber(str) formatPhoneNumber(str, style) }
32. Utilities // Utilities Helper { formatSSN(str) handleHTTPError(obj) removeAllChildren(uiView) groupDigits(str, country) formatAsCurrency(str, country) removeAlphaChars(str) validatePhoneNumber(str) formatPhoneNumber(str, style) } PLEASE don’t do THIS! (Low cohesion)
33. Utilities StringFormatter { formatSSN(str) groupDigits(str) formatAsCurrency(str, country) removeAlphaChars(str) } PhoneNumber { validate(str) format(str, style) } Within a “utils” directory:
34. Sample: Web Services
35. Web Services C. Kleeschulte J. Lonon M. Lockley H. Proske S. Feather C. Curry Refresh P. Patel Web Service Some Meetup app:
36. Web Services HTTP Web Service Button /members
37. Web Services Mock Data HTTP Web Service Button select * /members PLEASE don’t do THIS!
38. Web Services HTTP Web Service WS Proxy Button /members getMembers()
39. Web Services HTTP Web Service Button Mock Data WS Proxy Mock WS Proxy getMembers() require()
40. Technical Debt
41. Technical Debt The Good The Bad •  Reduces time-to-market •  We understand the problem •  Code is kept clean •  Intentional (have plan for payback) •  Unintentional complexity •  Shoddy workmanship •  Becomes unmaintainable •  Leads to app REWRITE
42. Value Quadrants Visible   Invisible   Value   +   -­‐   (Features) (Architecture/Design) (Technical Debt) (Bugs) CRUFT
43. Value Quadrants “Badly designed, unnecessarily complicated, or unwanted code” - Oxford Dictionary Cruft: “The single contributing reason you’re going to rewrite your app from scratch, i.e. unmaintainable garbage” - Patrick Seda
44. Value Quadrants Visible   Invisible   Value   +   -­‐   (Features) (Architecture/Design) (Technical Debt) (Bugs) Op#mized  UX   Works  correctly   Organic  anima#ons   Good  UI  design   Modular  design   UI  Typos   Slow  performance   Crashes   Duplicate  code   No  unit  tests   Doesn’t  work  correctly   SOLID  principles   Logging  framework   Coding  standards   “Big  Ball  of  Mud”   CRUFT
45. Visible   Invisible   Value   +   -­‐   (Features) (Architecture/Design) (Technical Debt) Quality - (Desired)
46. Visible   Invisible   Value   +   -­‐   (Features) (Architecture/Design) (Technical Debt) (Bugs) Quality - (Prod. Reality)
47. Visible   Invisible   Value   +   -­‐   (Features) (Architecture/Design) (Technical Debt) (Bugs) Quality - (Prod. Over Time)
48. Summary
49. Summary 1) You MUST avoid creating CRUFT 2) You MUST be DISCIPLINED 3) You MUST focus on good DESIGN 4) You MUST LEARN from the past The Maintainable Mobile App:
50. Thank You
51. Patrick Seda @pxtrick patrickseda@gmail.com linkedin.com/in/patrickseda speakerdeck.com/pxtrick