Emerging Best Practices in Swift

Presented at GOTO Copenhagen 2015: http://gotocon.com/cph-2015/

Transcript

1. Emerging Best Practices in Swift Ash Furrow
3. Afraid I was
4. Fine Everything turned out
5. Best Practices in Swift
6. What do they look like? Also, how do we find new ones?
7. Agenda • We’ve been here before • Learning is forever, deal with it • Never throw ideas away • How to force yourself to think • Always be abstracting
8. Let’s go!
9. This looks strangely familiar…
10. —Lots of people, for hundreds of years “Those who don’t study history are doomed to repeat it.”
11. Wow, that’s depressing.
12. —Me, today “Those who don’t understand the past can’t make informed decisions about the present.”
13. iOS 5 or earlier?
14. Before Object Literals NSArray *array = [NSArray arrayWithObjects: @"This", @"is", @"so", @"tedious", nil]; NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys: @"Who would do this?", @"Not me", nil]; NSNumber *number = [NSNumber numberWithInt:401];
15. Before Object Literals and ARC NSArray *array = [[NSArray arrayWithObjects: @"This", @"is", @"so", @"tedious", nil] retain]; NSDictionary *dictionary = [[NSDictionary dictionaryWithObjectsAndKeys: @"Who would do this?", @"Not me", nil] retain]; NSNumber *number = [[NSNumber numberWithInt:401] retain];
17. After Object Literals NSArray *array = 
 @[ @"This", @"is", @"much", @"better" ]; NSDictionary *dictionary = 
 @{ @"Who likes this?": @"Me!" }; NSNumber *number = @(401);
18. Object Literals • Clearly way better • Adopted by everyone almost immediately • Became a “best practice”
19. ^{
20. Blocks & GCD • Introduced in iOS 4 • Adopted slowly, but surely • Required new ways of thinking • Did using blocks became a “best practice”? • Sort of…
21. Enable Blocks other best practices
22. ^{ Functional Reactive Programming Futures Promises Collections Operations Callbacks Inline Network Operations Generic Datasource Objects Deferred Customization Contextual Code Execution
23. Embrace Change
24. Swift 2
25. Swift 2 • Lots of new syntax • New syntax lets us do new things • However! Syntax is only a tool • Like blocks, Swift 2 syntax is most useful when it enables new ideas
26. Swift 2 • guard • defer • throws • etc…
27. Should I use guard?
28. What can I do with guard?
29. Examples
30. Pyramid of Doom if let thing = optionalThing { if thing.shouldDoThing { if let otherThing = thing.otherThing { doStuffWithThing(otherThing) } } }
31. Clause Applause if let thing = optionalThing, let otherThing = thing.otherThing where thing.shoudDoThing { doStuffWithThing(otherThing) }
32. Avoid Mutability func strings( parameter: [String], startingWith prefix: String) -> [String] { var mutableArray = [String]() for string in parameter { if string.hasPrefix(prefix) { mutableArray.append(string) } } return mutableArray } ಠ_ಠ
33. Avoid Mutability func strings( parameter: [String], startingWith prefix: String) -> [String] { return parameter.filter { $0.hasPrefix(prefix) } }
34. Currying • One of those weird words you avoid because people who say it are sometimes jerks • It’s actually a pretty straightforward concept • Currying is a function that returns another function • Useful for sharing code that’s mostly the same
35. Before Currying func containsAtSign(string: String) -> Bool { return string.characters.contains("@") } ... input.filter(containsAtSign)
36. Currying func contains(substring: String) -> (String -> Bool) { return { string -> Bool in return string.characters.contains(substring) } } ... input.filter(contains("@"))
37. Currying func contains(substring: String)(string: String) -> Bool { return string.characters.contains(substring) } ... input.filter(contains("@"))
38. Extract Associated Values • Use Swift enums • Attach associated values • Extract using a case
39. Extract Associated Values enum Result { case Success case Failure(reason: String) } switch doThing() { case .Success: print("") case .Failure(let reason): print("Oops: \(reason)") }
40. Extract Associated Values enum Result { case Success case Failure(reason: String) } if case .Failure(let reason) = doThing() { print(" \(reason)") }
41. Syntax That’s all just
42. Ideas What matters are
43. Protocol-Oriented Programming
44. … just go watch the WWDC video.
45. Others Let’s ask
46. Syntax vs Idea • How to tell if something is universally a good idea, or just enables other ideas? • You can’t • It’s a false dichotomy • I lied to you • I’m so sorry
47. Try stuff You’ve just got to
48. Ideas Never throw away
49. Never Throw Away Ideas • Swift was released • We treated Swift like object literals instead of like blocks • Some of us thought Swift was universally better • My fault, oops
50. Merit Older ideas have
51. A lot iOS developers throw things away
52. Why?
53. Beginner learns thing Is bad at thing Blames thing Thing must be bad
54. Beginner gets more experience New thing comes out Learning new thing is easier than old thing New thing must be good
55. Appealing New ideas are
56. Always a fresh supply of old APIs for us to blame iOS is constantly changing
57. Refactoring Let’s talk about
59. What is Not Refactor? • Refactoring does not add new functionality • Refactoring does not change a type’s interface • Refactoring does not change a type’s behaviour
60. Changing a unit test? Refactoring Rewriting No Yes
61. Bad Rewrites are
63. Favour incremental change
64. Code isn’t necessarily valuable But throwing it away is dangerous
65. Things to never throw away: Code Ideas &
66. Change Unit tests will help
67. Unit Testing & Thinking • So, uhh, unit testing • Controversial in iOS • Not so much everywhere else • Why? • We’ll get to that
68. Benefits of Testing • (Let’s presume that unit testing is a good idea) • I really don’t care that much about the tests • I care more about how writing tests makes me think about what I’m writing
69. Benefits of Testing • Limited object scope is good • High cohesion, low coupling • How to limit scope? • Controlling public interface and dependencies
70. Dependency injection?
71. Dependency Injection • €5 word for a ¢5 idea • Your things shouldn’t create the things they need
72. Example
73. Without Dependency Injection class ViewController: UIViewController { let networkController = NetworkController() func viewDidLoad() { super.viewDidLoad() networkController.fetchStuff { self.showStuff() } } }
74. With Dependency Injection class ViewController: UIViewController { var networkController: NetworkController? func viewDidLoad() { super.viewDidLoad() networkController?.fetchStuff { self.showStuff() } } }
75. Dependency Injection • Rely on someone else to configure your instance • Could be another part of your app (eg: prepareForSegue) • Could be a unit test • Protocols work really well for this
76. Dependency Injection protocol NetworkController { func fetchStuff(completion: () -> ()) } ... class APINetworkController: NetworkController { func fetchStuff(completion: () -> ()) { // TODO: fetch stuff and call completion() } }
77. Dependency Injection protocol NetworkController { func fetchStuff(completion: () -> ()) } ... class TestNetworkController: NetworkController { func fetchStuff(completion: () -> ()) { // TODO: stub fetched stuff completion() } }
78. Dependency Injection • Use of protocols limits coupling between types • Adding a method to a protocol becomes a decision you have to make • Dependency injection can also be used for shared state, like singletons
79. Without Dependency Injection func loadAppSetup() { let defaults = NSUserDefaults.standardUserDefaults() if defaults.boolForKey("launchBefore") == false { runFirstLaunch() } }
80. How would you even test that?
81. With Dependency Injection func loadAppSetup(defaults: NSUserDefaults) { if defaults.boolForKey("launchBefore") == false { runFirstLaunch() } }
82. Don’t be an ideologue
83. Cheat with Dependency Injection func loadAppSetup( defaults: NSUserDefaults = .standardUserDefaults()){ if defaults.boolForKey("launchBefore") == false { runFirstLaunch() } }
84. Cheat with Dependency Injection loadAppSetup() // In your app loadAppSetup(stubbedUserDefaults) // In your tests
85. Cheat with Dependency Injection class ViewController: UIViewController { lazy var networkController: NetworkController = APINetworkController() func viewDidLoad() { super.viewDidLoad() networkController.fetchStuff { self.showStuff() } } }
86. —Mackenzie King (Canada’s Winston Churchill) “TDD if necessary, but not necessarily TDD.”
87. Unit Testing • Don’t test private functions • Also, start marking functions as private • Remember, we want to avoid rewriting • Don’t test the implementation • Don’t use “partial mocks” • See @searls post on partial mocks
88. Unit Testing • So why don’t iOS developers do unit testing? • It’s unfamiliar and no one forces us to do it
89. Better Testing code makes me a Developer
90. Everything Abstract
91. Two or more lines of repeated code? Find a better way
92. (╯°□°）╯︵ ┻━┻
93. Look for Abstractions • You’re already learning new syntax • Look for new abstractions along the way • Not all ideas will work out • But you should still do it • Experiment!
94. No such thing Failed experiment as a
96. Learn Always opportunities to
97. Wrap Up • We have a history of being awesome, let’s keep it up • Learning isn’t just for when Xcode is in beta • Ideas are more valuable than code, but throwing away either is dangerous • Effective unit tests make it easy to change code • Operate at the highest level of abstraction you can at any given time
98. Make Tomorrow Better Mistakes