Alles bleibt anders (Timeless Wisdom for Software Developers)

Als Softwareentwickler kann man sich nur auf eines verlassen: Man muss sich ein Leben lang mit ständig neuen Frameworks, Libraries, Tools und Programmiersprachen beschäftigen. Manches Wissen hat aber ein kürzeres Verfallsdatum als die meisten Milchprodukte. Was soll man als Junior also als Erstes lernen? Welches neue Wissen soll man sich aneignen, wenn man bereits viele Jahre Erfahrung hat? Dieser Vortrag möchte diese Fragen weder stellen noch beantworten und stattdessen den Blick auf die zugrunde liegenden Konzepte richten. Viele dieser Konzepte, Ideen und Weisheiten haben sich nämlich erstaunlicherweise in den letzten zwanzig Jahren überhaupt nicht verändert und sind daher ideale Kandidaten, um sie sich anzueignen und damit auch für die nächsten zwanzig Jahre gewappnet zu sein.

Transcript

1. Alles bleibt anders 
 Timeless Wisdom for Software Developers Frank Gerberding, 05.05.202
2. @ MilesBehind69 2 "Give someone a program, you frustrate them for a day; 
 teach them how to program, you frustrate them for a lifetime." ( David Leinweber)
3. @ MilesBehind69 3
4. @ MilesBehind69 4 Muss ich ständig etwas Neues lernen? 
 Muss ich ständig von Neuem lernen? 𐄂 ✓
5. @ MilesBehind69 5 Small is beautiful „Small is beautiful, Size is the #1 enemy of agility; keep your systems as small as you reasonably can (but no smaller)“ ( Stefan Tilkov)
6. @ MilesBehind69 6 Methode aus Code-Review
7. @ MilesBehind69 7 Single Responsibility Principle „Do not try to do everything. Do one thing well.“ ( Steve Jobs)
8. @ MilesBehind69 8 Single Responsibility Principle book flight 
 cancel flight FlightService Client Code FlightRepository CancelFlight FlightRepository TimeService CustomerService MessageService book flight cancel flight store bookings find customer store 
 bookings get system time send messages BookFlight
9. @ MilesBehind69 9 Side effects can be worse than the disease „Can placebos cause side effects? If so, are the side effects real?“ ( George Carlin)
10. @ MilesBehind69 10 Side effects can be worse than the disease Component-A Client Code Component-B Component-A call result 
 (depends on state of A and B ) call result 
 (depends on 
 state of B ) Component-B modifies some 
 internal data of B modifies some 
 internal data of A call result 
 (depends only on call arguments) call result 
 (depends only on call arguments)
11. @ MilesBehind69 11 Avoid accidental complexity “Any darn fool can make something complex; it takes a genius to make something simple.” ( Pete Seeger)
12. @ MilesBehind69 12 Avoid accidental complexity A Problem 
 Complexity Minimum 
 Solution 
 Complexity Accidental 
 Solution 
 Complexity
13. @ MilesBehind69 13 Dependencies prevent flexibility „The cheapest, fastest, and most reliable components are those that aren’t there.“ ( Gordon Bell)
14. @ MilesBehind69 14 Dependencies prevent flexibility depends on Component Component Component Component Component Component Component Component Component depends on Component Component Component Component Component Component Component transitively depends on
15. @ MilesBehind69 15 Divide and conquer through modularization „The whole is more than the sum of its parts.“ ( Aristoteles)
16. @ MilesBehind69 Base-Application 16 Divide and conquer through modularization Module-A - Interface Module-A Module-B - Interface Module-B Module-C - Interface Module-C Plugin-A Plugin-B Plugin-C Plugin-D Plugin-E
17. @ MilesBehind69 17 Loose coupling prevents fire of change from spreading „Architecture is the tension 
 between coupling and cohesion.“ ( Neal Ford)
18. @ MilesBehind69 18 Loose coupling prevents fire of change from spreading depends on Abstraction Component-A Component-B Component-A Component-B depends on implements
19. @ MilesBehind69 19 The Open-Closed-Principle prepares you for the future „A good design is not the one that correctly predicts the future, it’s one that makes adapting to the future affordable.“ ( Venkat Subramaniam)
20. @ MilesBehind69 20 The Open-Closed-Principle prepares you for the future Abstraction Component Component depends on implements Component Component implements implements
21. @ MilesBehind69 21 Ignorance is a bliss „I know this steak doesn't exist. 
 I know that when I put it in my mouth, 
 the Matrix is telling my brain that it is juicy and delicious. 
 After nine years, you know what I realize? 
 Ignorance is bliss.“ ( Cypher, The Matrix)
22. @ MilesBehind69 What ( Visible) 22 Ignorance is a bliss How 
 ( Hidden) Client 
 Code
23. @ MilesBehind69 23 Avoid unnecessary work „Remember that there is no code faster 
 than no code.“ ( Taligent’s Guide to Designing Programs)
24. @ MilesBehind69 24 Avoid unnecessary work persons.filter {"a" in it.lastName } .map {"${it.firstName} ${it.lastName}" } .filter {it.length > 15 } .take(5) persons.stream( ) .filter {"a" in it.lastName } .map {"${it.firstName} ${it.lastName}" } .filter {it.length > 15 } .limit(5 ) .collect(Collectors.toList()) persons.asSequence( ) .filter {"a" in it.lastName } .map {"${it.firstName} ${it.lastName}" } .filter {it.length > 15 } .take(5 ) .toList() Evaluation Duration 0 ms 20 ms 40 ms 60 ms Person Count 100 10.000 1.000.000 Kotlin List Kotlin Sequence/Java Stream Kotlin 
 Lists Kotlin 
 Sequences Java 
 Streams
25. @ MilesBehind69 25 I/O is slow „Nothing travels faster than the speed of light with the possible exception of bad news.“ ( Douglas Adams)
26. @ MilesBehind69 26 I/O is slow 1 MByte/sec 100 MByte/sec 10.000 MByte/sec 2000 2010 2020 Storage Network Memory 50 ⨉ 400 ⨉
27. @ MilesBehind69 27 Quality leads to productivity „The paradox is that when you focus on productivity, long- term improvements are rarely made. 
 On the other hand, when you focus on quality, productivity improves continuously.“ ( John Seddon)
28. @ MilesBehind69 Aufwand pro Feature Zeit Kein Fokus auf Qualität/Tests Fokus auf Qualität/Tests 28 Quality leads to productivity Mehraufwand mit Fokus auf Qualität Mehraufwand ohne Fokus 
 auf Qualität Produktivität
29. @ MilesBehind69 29 Immutability is your code’s armor „One of the most difficult elements of program design 
 is reasoning about the possible states of complex objects. Reasoning about the state of immutable objects, 
 on the other hand, is trivial.“ ( Brian Goetz)
30. @ MilesBehind69 30 Immutability is your code’s armor ImmutableItem ImmutableItem MutableItem modify modify = copy ImmutableCollection ImmutableCollection modify = create changes reference previous version
31. @ MilesBehind69 31 Improving testability improves design „Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.“ ( John F. Woods)
32. @ MilesBehind69 32 Improving testability improves design Loose Coupling Immutability Keep things small Open-Closed- Principle Avoid Dependencies Single Responsibility Principle Quality is 
 Productivity Make things 
 easily testable Avoid side effects
33. @ MilesBehind69 33 Good names improve readability „There are 2 hard problems in computer science: 
 cache invalidation, 
 naming things, 
 and off-by-1 errors.“ ( Leon Bambrick)
34. @ MilesBehind69 34 Documentation is a love letter to your future self „A person who won't read 
 has no advantage over one who can't read.“ ( Mark Twain)
35. @ MilesBehind69 35 Modularization Loose Coupling Immutability Keep things small Open-Closed- Principle I/O is slow Lazy Evaluation Avoid Dependencies Quality is 
 Productivity Make things 
 easily testable Name things well Documentation Avoid accidental 
 complexity Avoid side effects Information Hiding Single Responsibility Principle
36. @ MilesBehind69 36 „One of the best programming skills you can have 
 is knowing when to walk away for awhile.“ ( Oscar Godson)
37. Vielen Dank für 
 Eure Aufmerksamkeit! https://speakerdeck.com/milesbehind69 
 http://frank.gerberding.blog https://twitter.com/milesbehin69 Zeichnungen von Sandra & Frank Gerberding