Erwin Zwart - Writing future proof Swift

This was presented at the Swift Usergroup Netherlands. Would you like to speak/present? Visit https://swift.amsterdam for more information.

When change of code is a given, how can you write your code in such a way that has buildin flexability without doing massive refactors? Erwin talks about planning for change, drawing an outline for the future without being to specific now.

Transcript

1. Writing future proof Swift Erwin Zwart iOS Developer @ The Capitals
3. Code lives in an ever changing environment How can you plan for the future if you don’t know what’s ahead?
4. If time allows it • Write automated tests • Do code review
5. On a code level • Avoid assumptions, restrict your intentions • Write code that models what it represent • Write shy code
6. Avoid assumptions, restrict your intentions
7. –A lot of people in 2012 “The iPhone screen is always 320 x 460px”
8. –A lot of people in 2012 “The iPhone screen is always 320 x 460px”
9. –A lot of people in 2014 “The navigation bar is always has a height of 64px”
10. –A lot of people in 2014 “The navigation bar is always has a height of 64px”
12. All of these assumptions are wrong • There are always 24 hours in a day. • Months have either 30 or 31 days. • Years have 365 days. • Any 24-hour period will always begin and end in the same day (or week, or month). • A week always begins and ends in the same month. • A week (or a month) always begins and ends in the same year. Source: FalsehoodsAboutTime.com
13. Write code that models what it represent
14. Write shy code • Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. • Each unit should only talk to its friends; don’t talk to strangers. • Only talk to your immediate friends. Source: Umer Mansoor, codeahoy.com
15. Examples
16. Questions? erwin@thecapitals.nl @e_zwart