Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Agile Software Development In Practice

55.342 Aufrufe

Veröffentlicht am

These are the slides to my "Agile Software Development in Practice" lectures. They are intended especially for Software Development students but have also partially been used in inhouse Clean Code developer trainings.

The following topics are covered:
* most aspects of Agile Methodology from Pair Programming to Collective Code Ownership
* Clean Code based on Robert C. Martins work
* Test Driven Development
* advanced Unit Testing techniques like Mockito mocks and Hamcrest matchers

The deck is divided into 9 lectures which each consist of a theoretical part and a practical excercise for the students. Included are building a Mars Station from building blocks (using agile methods and SCRUM roles), Uncle Bobs famous Bowling Game Code Kata and a smallscale Code Retreat.

Accompanying source code and examples can be found on https://github.com/bkimminich/AgileSoftwareDevelopmentInPractice

Veröffentlicht in: Bildung, Technologie
  • Als Erste(r) kommentieren

Agile Software Development In Practice

  1. 1. Agile SoftwareDevelopment inPractice withCleanCodeandTestDrivenDevelopment v1.42 (01.09.2015) Björn Kimminich https://twitter.com/bkimminich https://linkedin.com/in/bkimminich https://google.com/+BjörnKimminich http://slideshare.net/BjrnKimminich/
  2. 2. Björn Kimminich 2007+ Senior Manager IT Architecture at Kuehne+Nagel Former Developer, Architect and Security Officer in Corporate Web Development 2011+ Part-time lector for Software Development at private UAS Nordakademie Currently teaching engineering students to program in Java 2012+ OWASP Member & low-frequency contributor to OWASP Zed Attack Proxy (ZAP) Author of the intentionally insecure Juice Shop webapp
  3. 3. Lecture 1 Organizational Stuff Agile Software Development
  4. 4. Organizational Stuff Schedule •9 lectures of 180min •2/3 head-on presentation •1/3 excercises and demos •Finishing exercises at home is recommended
  5. 5. More Organizational Stuff Rules of Behavior •No other work/“work“ done during lectures •Feel free to interrupt with questions right away •Particpate actively and discuss openly •Breaks on demand. I tend to forget those… 
  6. 6. Agenda I •Right & Duties •The Agile Manifesto •Agile Techniques •Scrum Agile Software Development •Building a Mars Station Excercise
  7. 7. Agenda II •Motivation •Names •Functions •Comments •Formatting Clean Code •Writing a clean Trading Card Game from scratch Excercise
  8. 8. Agenda III • Unit Tests • Junit 4 • Test Driven Development (TDD) • BDD Test Style • Matchers • Mocking Testing • Adding advanced rules to the Trading Card Game Excercises
  9. 9. Agenda IV •Code Kata Fizz Buzz •Code Retreat Game of Life Additional Excercises
  10. 10. Icon Legend Goal Tool Quote
  11. 11. Source Code Examples https://github.com/bkimminich/AgileSoftwareDevelopmentInPractice
  12. 12. Agile Software Development Introduction
  13. 13. Targets of efficient Software Development Source: http://labs.andrae-ag.de/2012/12/scrum-und-das-teufelsquadrat-von-sneed/
  14. 14. Why classic devlopment methods often fail… Source: http://projectmanagement-ijourneys.com/project-management-illustrated-with-a-tree-and-a-swing/
  15. 15. Agile Software Development Agile Software Development takes into account the short innovation cycle Quick customer feedback Open discussion Integration of the customer into the project Lean and adaptable development process Early visible and deployable results Embrace the change
  16. 16. Rights and Duties – Customer Rights • Define release content • Receive agreed scope • Change requirements Duties • Express the requirements • Define acceptance criteria
  17. 17. Rights and Duties – Developer Rights •Independent effort estimation •Risk estimation •Define release scope Duties •Adhere to release plan •Adhere to quality criteria
  18. 18. AgileManifesto.org Source: http://agilemanifesto.org/
  19. 19. Agile Development Techniques Iterative Process User Stories Transparent Estimation Process Test Driven Development Regression Tests Pair Programming Collective Code Ownership Continuous Integration Refactoring
  20. 20. Iterative Process An Iteration should not take longer than 2-4 weeks Each Iteration delivers new functionality with business value In each Iteration a fixed set of User Stories is defined and implemented The customer approves/declines all User Stories at the end of each Iteration The result of several Iterations will be deployed as a (production) Release Release 1 Release 2 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Iteration 7
  21. 21. User Stories Functionality that generates business value Brief description Estimated by developers Unit of Work
  22. 22. Task Board I
  23. 23. Task Board II Source: http://www.axisagile.com/resources/scrumtrooper-images/
  24. 24. Planning Poker I Consensus based estimation method Define estimation reference Pre-defined estimation values 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ? 1. Discuss User Story 2. Hidden estimation 3. Reveal all estimations 4. Discuss outliers 5. Hidden re-vote
  25. 25. Planning Poker II Source: http://www.axisagile.com/resources/scrumtrooper-images/
  26. 26. Test Driven Development 1. Write a failing test 2. Write the (smallest) amount of code to pass the test 3. Refactor You are not allowed to write any production code unless it is to make a failing unit test pass You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
  27. 27. Regression Tests Test Suites contain all class Unit Tests Suites should be executed After every finished development task After every Refactoring Before committing into Version Control System At the end of the day all tests must pass Other types of automated tests (Integration, UI, …) should also be bundled into Test Suites
  28. 28. Pair Programming Two developers program on one computer One active programmer One observer reviewing each line of code considering the strategic direction of the task Roles are switched regularly Pairs are changed regularly Benefits Increased Software Quality Knowledge Management
  29. 29. Collective Code Ownership Abandons any notion of individual ownership of modules (“my code” vs. “your code”) Code base is owned by the entire team Anyone may make changes anywhere Common style guide and coding standard
  30. 30. Continuous Integration Build Server continuously checks out sourcecode from version control system Builds software and runs tests and static code analysis as often as possible Nightly Several times per day Every 15 min After every commit Feedback via eMail, RSS, IM, Monitor
  31. 31. Refactoring Disciplined technique for restructuring existing code Alters internal structure without changing external behavior Series of small behavior preserving transformations Sequence of small transformations can produce a significant restructuring System is kept fully working after each small refactoring
  32. 32. Scrum Source: http://www.scrumprimer.org/overview
  33. 33. Scrum Roles Product owner responsible for the business value of the project ScrumMaster ensures that the team is functional and productive Team self-organizes to get the work done Source: http://www.scrumalliance.org/pages/scrum_101
  34. 34. Scrum Ceremonies Sprint planning the team meets with the product owner to choose a set of work to deliver during a sprint Daily scrum the team meets each day to share struggles and progress Sprint reviews the team demonstrates to the product owner what it has completed during the sprint Sprint retrospectives the team looks for ways to improve the product and the process. Source: http://www.scrumalliance.org/pages/scrum_101
  35. 35. Daily Scrum Source: http://www.axisagile.com/resources/scrumtrooper-images/
  36. 36. Sprint Retrospective Source: http://www.axisagile.com/resources/scrumtrooper-images/
  37. 37. Scrum Artifacts Product backlog ordered list of ideas for the product Sprint backlog set of work from the product backlog that the team agrees to complete in a sprint, broken into tasks Product Increment required result of every sprint. It is an integrated version of the product, kept at high enough quality to be shippable. Source: http://www.scrumalliance.org/pages/scrum_101
  38. 38. Excercise 1 Building a Mars Station
  39. 39. Goal Build a Mars Station model with DDR building blocks using Agile Development techniques Iterative Process User Stories Product Backlog Transparent Estimation Sprint Backlog Pair Programming Collective Code Ownership Refactoring Product Increment Sprint Review Sprint Retrospective
  40. 40. Roles 1x Co-Founder & CTO Mars Tech Inc® 3x Product Owner 2x Scrum Master 6x Team nx Keen observers
  41. 41. Project Timeline Sprint 0 Preparation Release 1 Sprint 1 Sprint 2 (Sprint 3) Deployment of Mars Station Release 1 on the Red Planet
  42. 42. Sprint 0 CTO Mars Tech Inc® shares Vision of the project with the team Project is staffed Product Owner defines first set of User Stories from the overall Mars Station vison Team gets familiar with the Development Environment and defines an Estimation Reference
  43. 43. User Story Examples I As an astrophysicist I want a deep space observatory So that I can study the stars. As a communications engineer I want a radio tower So that I can stay in contact with the company’s personnel on Earth.
  44. 44. User Story Examples II As a CEO I want a luxurious apartment So that I have the same comfort on Mars that I have on Earth when visiting the station. As a security officer I want a security station in every sector So that I can better fend off invading demons if need be.
  45. 45. Sprint 1-3 Sprint Planning (15min) PO presents new User Stories Team estimates effort Team defines Sprint Backlog Sprint (15min) Team implements User Stories PO refines Product Backlog Sprint Review & Retrospective (10min) Team presents Product Increment to PO Team reflects on last Sprint and adjusts process
  46. 46. Clean Code Lectures 2-4 Source: Martin, R.C. (2008). Clean Code. Prentice Hall http://cleancoders.com/codecast
  47. 47. Lecture 2 Motivation Names
  48. 48. Motivation Does Clean Code matter?!
  49. 49. How long did it take you to spot the mistake in these simple ~4 lines of code? How long would it take in your own code? Can you spot the bug in this code? == true // always! Source: https://github.com/bkimminich/java-pitfalls
  50. 50. Do you know this man?
  51. 51. Who is „Uncle Bob“? I’ve been a programmer for 42 years; and in that time—let me tell you—I’ve seen it all I’ve been fired. I’ve been lauded. I’ve been a team leader, a manager, a grunt, and even a CEO I’ve worked with brilliant programmers and I’ve worked with slugs I’ve programmed in COBOL, FORTRAN, BAL, PDP- 8, PDP-11, C, C++, Java, Ruby, Smalltalk, and a plethora of other languages and systems [Uncle Bob, The Clean Coder]
  52. 52. Mandatory Literature for Software Craftsmen Clean Code Robert C. Martin, 2008 The Clean Coder Robert C. Martin, 2011 http://www.cleancoders.com/ Code-casts for Software Professionals
  53. 53. Measuring Code Quality Source: http://www.osnews.com/story/19266/WTFs_m
  54. 54. Bad Code Wading through code Meet deadline now, clean up later Increasing slowdown over time Better a running mess than nothing Nobody cares (Broken Window)
  55. 55. The Grand Redesign I When the mess in an existing system gets overwhelming…
  56. 56. The Grand Redesign II …the development team will demand a Grand Redesign of the system.
  57. 57. The Grand Redesign III The best and brightest developers will form a new A-Team…
  58. 58. The Grand Redesign IV …which endeavours to redesign the system as a new and shiny green field project.
  59. 59. The Grand Redesign V Unfortunately the A-Team must wade through the old systems code to understand the requirements for the new system…
  60. 60. The Grand Redesign VI …while rest of the developers (=B to Z-Team) have to keep maintaining and add new features to the old system…
  61. 61. The Grand Redesign VII …forcing the A-Team to keep up with the old system‘s changes while building the new system from scratch.
  62. 62. The Grand Redesign VIII Years pass with this race going on. The original A-Team members have long quit on their employer…
  63. 63. The Grand Redesign IX …and the current members demand a redesign because the new system has become such a mess!
  64. 64. Who‘s to blame for Bad Code? Unclear Requirements Last-minute Change Requests Tight Project Schedules Stupid Managers Intolerant Customers
  65. 65. Who‘s to blame for Bad Code? Unclear Requirements Last-minute Change Requests Tight Project Schedules Stupid Managers Intolerant Customers We Programmers!
  66. 66. What is Clean Code? Can be read and enhanced by a developer other than its original author Has unit and acceptance tests Does one thing well Looks like it was written by someone who cares Never obscures the designer‘s intent Each routine you read turns out to be pretty much what you expected Reads like well written prose Provides a clear and minimal API Elegant & efficient Bjarne StroustrupWard CunninghamMichael FeathersGrady Booch
  67. 67. XP Simplicity Rules (by Kent Beck, Ron Jeffries et.al.) Source: http://c2.com/cgi/wiki?XpSimplicityRules
  68. 68. Broken Window Theory
  69. 69. The Boy Scout Rule "Try and leave this world a little better than you found it." (Robert Stephenson Smyth Baden-Powell) "Always leave the campground cleaner than you found it." (The Boy Scout Rule) "Always check a module in cleaner than when you checked it out.”
  70. 70. A famous quote… You are not only responsible for what you do, but also for what you don’t do. [Laotse, 600B.C.]
  71. 71. Would you send an Email like this to your boss?
  72. 72. The Email Metaphor Committing code into a Version Control System is like sending an email to your boss… …with all your co-developers as CC recipients! Get it right before hitting or
  73. 73. Clean Code in a Nutshell WE CARE FOR OUR CODE Other developers can read understand maintain the code we write Changed and added code is safeguarded by Tests We clean up Legacy Code whenever we can The whole team is responsible for the whole code
  74. 74. What is Legacy Code? Legacy code. The phrase strikes disgust in the hearts of programmers. It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal. Although our first joy of programming may have been intense, the misery of dealing with legacy code is often sufficient to extinguish that flame [Uncle Bob, Working Effectively with Legacy Code] To me, legacy code is simply code without tests [Michael Feathers, Working Effectively with Legacy Code]
  75. 75. Dealing with our own Legacy Code Gradually clean up Legacy Code you are working on Include efforts for the following preliminary tasks into your project estimations Cleaning up existing code Creating Unit Tests Not breaking existing functionality is paramount A little cleanup is better than none at all
  76. 76. Let‘s wrap up the „Motivation“…
  77. 77. Names
  78. 78. Don‘t be just smart In general programmers are pretty smart people One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king Professionals use their power for good and write code that others can understand [Uncle Bob, Clean Code]
  79. 79. Another famous quote… With great power comes great responsibility [Uncle Ben, Spiderman]
  80. 80. Reveal your Intent Any Variable/Method/Class name should tell Why it exists What it does How it is used If you need a comment to explain the name, the name is probably ill chosen
  81. 81. Intent Guessing Exercise
  82. 82. What might these classes do?
  83. 83. Meaningful Names Source: http://www.itiseezee.com/?p=83
  84. 84. No Disinformation Do not leave false clues Do not obscure the meaning of code Entrenched vs. intended meaning Inconsistent spelling
  85. 85. Entrenched vs. intended meaning
  86. 86. No Language Mashups
  87. 87. Pronouncable Names class BaseDxoProcessMilestone7600LstBo class Dx2FltrShipmentCustPartyXDto class GyqfaChBppResDao class SegmentG041Data class KnlobiLocation class SwotService
  88. 88. l0O1 should be avoided
  89. 89. No Encodings No member prefixes int m_price; // member variable int g_count; // global variable int s_total; // static member … No Hungarian Notation boolean bBusy; boolean fBusy; //flag int cApples; // count of items float fpPrice; // floating point Student[] rgStudents; // range …
  90. 90. No Unnecessary Context
  91. 91. Interface vs. IInterface No „I“ in front of Interface names Sometimes encoding is necessary to avoid name clash with implementation class ShapeFactory implements IShapeFactory class ShapeFactoryImpl implements ShapeFactory class DefaultShapeFactory implements ShapeFactory
  92. 92. Consistent Lexicon Pick one word per concept findSomething() findsearchSomethingElse() findgetSomethingCompletelyDifferent() findlookOutForPirateShipsOnTheHorizon() findkeepAnEyeOutForAnythingElseSuspicious() Avoid using the same word for two purposes void addElement(List list, Object element) void addRestriction(List rules, Restriction rule) String concatenateaddStrings(String s1, String s2) void appendaddWord(String sentence, String word)
  93. 93. The Scope Rule Methods Methods that are called from far and wide should have short evocative names Methods in small scopes should have long and precise names You should not have to read the body of a method to know what it does - its name should tell you The more complex the behavior of a method, the more generic its name, and the more sub methods should be extracted from it
  94. 94. Long Method Scope = Short Name Component service interface  Public API  Long Scope create(NetsurveyRunDts netsurveyRun) updateContentEncoding (String encoding, Long netsurveyRunId)
  95. 95. Short Method Scope = Long Name
  96. 96. The Scope Rule Variables/Parameters Local variables of a short method or small block can have short names Global variables should have long and self- explaining names
  97. 97. Long Variable Scope = Long Name BTW: A class with 1755 LOC is a hideously long scope…
  98. 98. Short Variable Scope = Short Name Short names are allowed in a short scope… …which doesn‘t mean that long descriptive names are discouraged for a short scope! One-letter names can be tolerated for Counter variables of simple for loops Exception instances in catch blocks for (Cell c : gameBoard) would also be okay in this scope!
  99. 99. The Scope Rule Summary Methods Long scope = Short name Short scope = Long name Variables Long scope = Long name (Short scope = Short name)
  100. 100. Excercise 2
  101. 101. Ongoing Excercise Topic: Trading Card Game Problem domain should be new for most Starting clean on a „green field project“ Pair Programming is mandatory Use TDD only if both partners are used to it! Proven to work well in different languages Did it myself in Java, Groovy and Javascript
  102. 102. The Problem Domain A […] trading card game (TCG) […] is a card game that uses specially designed sets of playing cards […] mass-produced for trading or collectibility, and it must have rules for strategic game play. Acquiring these cards may be done by trading with other players or buying card packs. Source: http://slideshare.net/BjrnKimminich/practicing-advanced-unit-testing
  103. 103. TCG Rules Visual explanation of the rules http://slideshare.net/BjrnKimminich/practicing-advanced-unit-testing/7 Complete textual rules description https://github.com/bkimminich/kata-tcg Click here if you like it… …or here if you don’t!
  104. 104. TCG Rules Preparation (I) Each player starts the game with 30 Health 0 Mana slots Each player starts with a deck of 20 Damage cards with the following Mana costs From the deck each player receives 3 random cards has his initial hand Source: https://github.com/bkimminich/kata-tcg 30 0/0 0 0 1 2 2 2 3 3 3 4 4 4 5 6 6 7 81 3 5 ? ? ?
  105. 105. TCG Rules Preparation (II) One player is randomly chosen to be the starting active player The other player draws a 4th card from his deck to compensate him for not playing the first turn Source: https://github.com/bkimminich/kata-tcg ? ? ? ? ? ? ? p=0,5
  106. 106. 1. The active player receives 1 Mana slot up to a maximum of 10 total slots 2. The active player's empty Mana slots are refilled ?/11 TCG Rules Basic Gameplay (I) Source: https://github.com/bkimminich/kata-tcg ?/0 ?/1 ?/2 ?/10 … ?/1 1/1 ?/2 2/2 ?/10 10/10 …
  107. 107. TCG Rules Basic Gameplay (II) 3. The active player draws a random card from his deck 4. The active player can play as many cards as he can afford. Any played card empties Mana slots and deals immediate damage to the opponent player equal to its Mana cost. Source: https://github.com/bkimminich/kata-tcg 29 -xx = ?
  108. 108. TCG Rules Basic Gameplay (III) 5. If the opponent player's Health drops to or below zero the active player wins the game 6. If the active player can't (by either having no cards left in his hand or lacking sufficient Mana to pay for any hand card) or simply doesn't want to play another card, the opponent player becomes active Source: https://github.com/bkimminich/kata-tcg 0 -1…
  109. 109. 123 TCG Rules Special Rules Bleeding Out: If a player's card deck is empty before the game is over he receives 1 damage instead of drawing a card when it's his turn Overload: If a player draws a card that lets his hand size become >5 that card is discarded instead of being put into his hand Dud Card: The 0 Mana cards can be played for free but don't do any damage either. They are just annoyingly taking up space in your hand Source: https://github.com/bkimminich/kata-tcg 29-1 0 45 6
  110. 110. Trading Card Game – Part 1 Create a two-player hotseat „TCG“ Concentrate on game logic, not on fancy GUI Do not implement any of the Advanced Variations Choose meaningful and adequate names for …packages …classes …methods …variables Only Pair Programming!
  111. 111. Lecture 3 Functions
  112. 112. Functions
  113. 113. Size Matters I
  114. 114. Size Matters II
  115. 115. Bjoern‘s Mousewheel Check™ If I have to scroll down to see the end of a method… …it‘s too long! If a single spin on my mouse wheel is not enough to see the end of a method… …it‘s far too long!! If I have to switch my mouse wheel from precision into speed mode and still can‘t reach the end of a method in one spin… …it‘s beyond fing hope!!!
  116. 116. Function Size Functions should be small Functions should hardly ever be >20 lines Blocks within if/else/while etc. should be 1 line Indentation level in a function should be 1-2 Small size makes sure a function is… …easily readable …easily understandable …doing only one thing!
  117. 117. Function Indentati n Level of 14o
  118. 118. What‘s wrong with this method? It does not do one thing! It should be two methods! findSupplierByCipId(Long id) findSupplierBySctId(Long id)
  119. 119. Single Responsibility Principle Source: http://elegantcode.com/2008/12/22/single-responsibility-principle/
  120. 120. SRP Violation at its best…
  121. 121. Side Effects Side effects are lies!!! A function that promises to do a thing should not do other hidden things
  122. 122. Command Query Separation A Function can do one of below but not both Change the state of an object Return some information about an object Asking a question should not change the answer!
  123. 123. Law of Demeter I A method should only call methods of its own class methods of its parameters methods of associated classes methods of objects created by itself
  124. 124. Law of Demeter II
  125. 125. Law of Demeter III For pure data structures LoD does not apply int leftMargin = config.layout.margins.left; List<Orderline> orderlines = this.getCustomer().getLatestOrder().getLines()
  126. 126. Compose Method Divide your program into methods that perform one identifiable task Keep all of the operations in a method at the same level of abstraction This will naturally result in programs with many small methods, each a few lines long Refactoring Use Extract Method refactorings… …until the rules above are met Original Method has become a Compose Method
  127. 127. What does this method do?
  128. 128. Legibility boost after Compose Method refactoring
  129. 129. Compose Methods are change friendly New!
  130. 130. Limitations of Compose Method Methods with many parameters local variables are hard to refactor into Compose Methods Sub-methods have too many parameters as well Code of sub-methods would not read well
  131. 131. Method Object Create a new class Add an instance variable for each local variable and each parameter of the original method plus the original receiver (if used) Add one method compute() whose body is the body of the original method Replace the original method with one that creates an instance of the new class, constructed with the parameters and receiver of the original method, and invokes compute() Refactor the new class
  132. 132. Demo Method Object Compose Method
  133. 133. Arguments  No input arguments  One input argument  Two input arguments  Three input arguments  Four or more input arguments  Boolean input arguments = obvious violation of SRP!  Enumeration input arguments = even more obvious SRP violation!!!
  134. 134. This should rarely happen…
  135. 135. …and this should never happen!
  136. 136. Parameter Object Replace a long parameter lists with a single object or structure Parameter Object has data members representing the original arguments to be passed in multiple constructors for different use cases
  137. 137. Output Arguments Harder to understand than input arguments Unexpected function behavior Input = Arguments Output = Return Value Often cause readers to do a double-take
  138. 138. Can you spot a Problem here?
  139. 139. Assigning method parameters is bad practice Intention is entirely unclear to the reader Param became obsolete at some point in time? Assignment was an accident? How to prevent this? Put final in front of every method parameter..? No Parameter Assignment
  140. 140. Final on Method Parameters
  141. 141. Final on Local Variables
  142. 142. Final Pros and Cons Pro Con What about runtime optimizations on the pro side? Might be valid for embedded systems. In general, runtime optimization is not an issue!
  143. 143. The Final Dillemma In Clean Code, final… …only hurts legibility a little bit …but is seldom needed to prevent bugs In Bad Code, final… …might help prevent some bugs …but severely hurts legibility
  144. 144. Using Checkstyle over final Checkstyle „Parameter Assignment“ Check
  145. 145. As a team agree on a common approach to either use or not use final in the code you own! In the long run you‘re probably better of agreeing not to use final! Final Conclusion
  146. 146. Specific Bean >> Generic Tuple Avoid generic tuple classes (Pair, Triple, …) in favor of use-case specific data structures
  147. 147. Collections & Maps
  148. 148. Wrapper Classes Wraps an unintuitive structure into an adapter class with a clear and expressive API
  149. 149. Error Handling Use Exceptions over error codes Can be handled immediately or be delegated Error handling separated from the „happy path“ Exceptions should be exceptional Use unchecked Exceptions for aborting errors Use Special Case Pattern for non-aborting error situations
  150. 150. Do not work with null Returning null from a method is bad! Instead… …return empty collection …consider throwing an Exception …consider using java.util.Optional or Special Case Pattern Passing null into methods is even worse! Code becomes cluttered with null checks Development team cannot trust its own code
  151. 151. java.util.Optional (since JDK8) = A container object which may or may not contain a non-null value. Offers methods depending on presence or absence of a value: isPresent()  true if present, false if absent get()  throws NoSuchElementException if absent orElse(T other)  returns value if present, otherwise returns provided other orElseGet(Supplier<? extends T> other)  value if present, otherwise invoke other and return result of that invocation
  152. 152. Optional in Action
  153. 153. Special Case Pattern = A subclass that provides special behavior for particular cases. Useful for… …non-aborting error situations …whenever it might be tempting to return null …other slight deviations from a default handling …particularly when Optional is unavailable or insufficient Customer MissingCustomer UnknownCustomer GlobalCustomer
  154. 154. Excercise 3
  155. 155. Trading Card Game – Part 2 Add a single player vs. computer game mode to your TCG The bot should play smart but doesn‘t have to be an AI Only Pair Programming but with different pairs than last time! One of each previous pair stays, the other will rotate to another partner!
  156. 156. Lecture 4 Comments Formatting
  157. 157. Comments
  158. 158. Comments I Comments are, at best, a necessary evil The proper use of comments is to compensate our failure to express ourself in code Inaccurate comments are far worse than no comments at all [Uncle Bob, Clean Code]
  159. 159. Comments II Comment bad code Clean up bad code Delete bad comments /*Highlighting*/ comments in Eclipse makes them easier to spot and remove if appropriate
  160. 160. HTML in Javadoc I Uncle Bob considers HTML in Javadoc a bad comment because he likes to have it readable in the code… …and there the HTML tags are quite ugly
  161. 161. HTML in Javadoc II On the other hand… …Eclipse has a Javadoc View …exported and frequently read Javadoc from Frameworks or Libraries should probably use HTML formatting
  162. 162. Good Comments Legal Comments Public API Javadoc Informative Comments Explanation of Intent Clarification Warning of Consequences TODO Comments
  163. 163. Legal Comments
  164. 164. Public API Javadoc
  165. 165. Informative Comments I Wait, shouldn‘t we prefer expressive names over a comment? Yes, but in this case one comment prevents duplication in six names!
  166. 166. Informative Comments II
  167. 167. Explanation of Intent
  168. 168. Clarification
  169. 169. Warning of Consequences
  170. 170. TODO Comments
  171. 171. Bad Comments Mumbling Redundant Comments Misleading Comments Mandated Comments Journal Comments Noise Comments Scary Noise Position Markers Closing Brace Comments Attributions and Bylines Commented-Out-Code Nonlocal Comments Too much Information Inobvious Connection Function Headers Javadoc in nonpublic Code
  172. 172. Mumbling I
  173. 173. Mumbling II
  174. 174. Redundant Comments
  175. 175. Misleading Comments
  176. 176. Mandated Comments
  177. 177. Journal Comments
  178. 178. Noise Comments
  179. 179. Scary Noise Copy & Paste Error? Redundant Field? …?
  180. 180. Position Markers
  181. 181. Closing Brace Comments
  182. 182. Attributions and Bylines
  183. 183. Commented-Out-Code
  184. 184. Nonlocal Information
  185. 185. Too much information
  186. 186. Inobvious Connection
  187. 187. Function Headers
  188. 188. Javadoc in nonpublic Code
  189. 189. Demo Comments
  190. 190. Anti-Pattern: UnCamelCasing Splitting class/method names into Javadoc… Providing zero additional information There are different skill levels of this art
  191. 191. Anti-Tool: JAutodoc Well-meant but ill- conceived Eclipse plugin Automates UnCamelCasing in perfection Do not use this or anything like it! http://jautodoc.sourceforge.net
  192. 192. Formatting
  193. 193. Vertical Formatting How long should a source file be? Typical file size ~200 LOC Upper limit ~500 LOC Vertical Openness Blank lines act as visual cues and separate concepts Vertical Density Tightly related lines of code should stick together Vertical Distance Closely related concepts should be vertically close to each other Reader should not have to „tail-chase“ through the code
  194. 194. Some *really* big (non-generated) Class
  195. 195. Horizontal Formatting How long should a line of code be? Upper limit 128 characters „Never scroll to the right“-rule doesn‘t work any more due to ongoing increase of display resolutions One Line = One Statement No Inner Assignments Horizontal Alignment Do not use // to force line breaks 80x25 char 5760x2160 px
  196. 196. OneLine = One Statement
  197. 197. No Inner Assignments
  198. 198. //=:-(*)
  199. 199. Do not overuse Method Chaining
  200. 200. Braces For better legibility use braces even for single- line statements
  201. 201. Inline Conditionals Use ?: operator for simple statements only Do not nest ?: statements
  202. 202. Team Rules Every programmer has his own favorite formatting rules, but if he works on a team, then the team rules [Uncle Bob, Clean Code]
  203. 203. Excercise 4
  204. 204. Trading Card Game – Part 3 Same students as last time should pair up… …but work on the code of another pair!!! Cleanup time! Rename! Refactor! Reformat! Remove redundancy! Present your results to the original code owners
  205. 205. Clean Code Cheat Sheet Names •Intent •Pronouncable •Lexicon •Scope Rule •Disinformation •Encodings •Prefixes Functions •Small •<20 LOC •<4 Arguments •SRP •CQS •Side Effects •final •Error Codes •Output Arguments •Parameter Assignment •null Comments •Good •Bad Formatting •1LOC = <120 char •1Class = <500LOC •1 line per statement •{…} •// Line Breaks •:? •Inner Assignments Tests •Unit Tests •TDD •100% Coverage •Robustness •Stability •Senseless Tests
  206. 206. Lecture 5 Testing Unit Tests JUnit4
  207. 207. Testing
  208. 208. Good reasons to test Source: https://en.wikipedia.org/wiki/Software_testing
  209. 209. Testing Levels Unit Tests Testing individual components (i.e. classes) w/o dependencies Integration Tests Testing the interfaces between different components or subsystems System Tests Testing the completely integrated system in a close-to-production environment Acceptance Tests Source: https://en.wikipedia.org/wiki/Software_testing
  210. 210. Unit Tests
  211. 211. Why create unit tests?
  212. 212. The F.I.R.S.T rule of unit tests F ast I solated R epeatable S elf validating T imely
  213. 213. Fast Unit tests give immediate feedback about the quality of implemented changes
  214. 214. Isolated I Unit tests do not require configuration Simply selecting “Run as…” in your IDE
  215. 215. Isolated II Unit tests have no dependencies on a runtime environment No databases, no web services, no file systems, no ...
  216. 216. Repeatable Unit tests must be automated and repeatable anytime
  217. 217. Selfvalidating Unit tests have a boolean outcome If the specification is violated, they fail
  218. 218. Timely Unit tests are written in a timely manner Ideally before the production code
  219. 219. Separation of Concerns Separate your unit and integration tests
  220. 220. Test Quality Treat your tests as first class citizens Don’t treat them worse than production code Clean Code rules also apply to tests
  221. 221. JUnit 4
  222. 222. Hello World Unit Test
  223. 223. JUnit A programmer-oriented testing framework for Java Originally created by Kent Beck and Erich Gamma on a flight from Atlanta to Zürich Most commonly used implementation of the xUnit architecture http://junit.org
  224. 224. Adding Junit to an Eclipse project
  225. 225. Annotations I = Syntactic metadata available since Java 5.0
  226. 226. Annotations II Execution order of similar annotated methods is not guaranteed! Execution order of similar annotated methods is not guaranteed!
  227. 227. Boolean Assertions Best practice: Use just one logical assertion per test!
  228. 228. Comparison Assertions The expected result always comes first! This is a little bit counter-intuitive.
  229. 229. Messages in Assertions
  230. 230. Demo JUnit
  231. 231. Exception and Border Cases Do not only test the „happy path“ but also Paths where exceptions are expected to occur Border cases of the functionality
  232. 232. Excercise 5
  233. 233. Testing TCG Create unit tests for various classes of your TCG implementation Concentrate on testing logic like Game rules (e.g. does bleedout and mana cap work?) AI (e.g. does it pick the smartest card combos?) Why is it harder/impossible to test the UI?
  234. 234. Lecture 6 TDD Code Kata „FizzBuzz“
  235. 235. TDD Test Driven Development
  236. 236. Test Driven Development Agile Projects embrace change Changing code bears the risk to break existing functionality Clean Code is a lot about refactoring code „I won‘t touch that code!“ TDD will severly reduce the „fear of change“ Test Driven Development by Example Kent Beck, 2002
  237. 237. Red, Green, Refactor RED: Write a failing unit test GREEN: Write production code to make test pass REFACTOR: Remove duplication and improve design* * Tests must still pass after Refactoring!
  238. 238. GreenBarPatterns Fake it ('til you make it) „Do the simplest thing that could possibly work”. This is a baby (tiny) steps approach. Obvious implementation You know what to write. The implementation is obvious. Triangulation Writing more tests to prove the need for further generalization. Searching for an implementation. One to Many When implementing something that works with collections, implement it without collections first.
  239. 239. The Magic TDD Principle As the tests get more specific, the codegets more generic [Uncle Bob] Source: http://cleancoders.com/codecast/clean-code-episode-19-p2/show
  240. 240. Code Coverage I Code Coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. What is a realistic goal for our Code Coverage? Source: https://en.wikipedia.org/wiki/Code_coverage
  241. 241. Code Coverage II
  242. 242. Code Coverage III 100%?!?! OMG!!! WTF?!
  243. 243. Let‘s hear what Uncle Bob has to say about Code Coverage… Source: http://cleancoder.posterous.com/
  244. 244. What is the purpose of this Test?
  245. 245. Behaviour Driven Testing Wrong: Getting obsessed with code coverage Right: Think about behaviour you want to test Code coverage will be automatically satisfactory
  246. 246. Code Coverage Goals Code Coverage is not a managers goal… …it must be our goal! Absolute Code Coverage is not the best KPI Code Coverage progression over time serves as a better indicator Relation of Line Coverage and LOC added must not decrease Overall Block Coverage must approach 100% asymptotically not decrease
  247. 247. Test Quality Tests must be robust and stable Tests must make sense No-op tests Happy path tests only Tests w/o (reasonable) assertions
  248. 248. Single Assert Rule Each test should only do one logical assertion One phyisical assert is perfect Multiple physical asserts make up one logical assert Mixing assertTrue() and assertFalse() can be confusing! Two different patterns are tested so these are multiple logical asserts!
  249. 249. Code Kata TDD Demo with „Fizz Buzz“
  250. 250. Fizz Buzz Kata Write a program that prints the numbers from 1 to 100 But for multiples of three print "Fizz" instead of the number… …and for the multiples of five print "Buzz" For numbers which are multiples of both three and five print "FizzBuzz" Source: http://codingdojo.org/cgi-bin/index.pl?KataFizzBuzz
  251. 251. Excercise 6 Adding some advanced rules to our TCG
  252. 252. Trading Card Game – Part 4 Randori Kata Style Source: http://codingdojo.org/cgi-bin/index.pl?RandoriKata Two people begin solving the exercise live on the digital projector Pilot = Driving the exercise on the keyboard Co-pilot = Keeping rules and quality in view TDD is mandatory! After 7min Timebox… …the pilot goes back into the audience …the co-pilot is promoted to pilot …someone from audience becomes co-pilot
  253. 253. Advanced Rule Healing When playing a card the active player can choose to… …use it to cause damage (Basic Rules) …use it to heal himself Players cannot heal up above 30 health 29 -xx ==+x 31 32 … Source: https://github.com/bkimminich/kata-tcg
  254. 254. Preliminary Design Session How do we plan to integrate this rule? What is a good test to get the TDD loop started? Which classes will we have to change? Are there existing tests that will probably change?
  255. 255. Lecture 7 BDD Test Style Matchers Mocking
  256. 256. BDD Test Style Creating readable, explanative tests
  257. 257. Don’t test APIs, test behavior Source: http://cleancoders.com/codecast/clean-code-episode-22/view
  258. 258. Don’t say test, say should
  259. 259. Think in terms of scenarios Scenario: Refunded items should be returned to stock given a customer previously bought a black sweater from me and I currently have three black sweaters left in stock when he returns the black sweater for a refund then I should have four black sweaters in stock
  260. 260. Structure your tests consistently public void shouldReturnRefundedItems() { // given // when // then } Define test data and behavior of mocks here. Call the code under test here. Verify the expected behavior here.
  261. 261. BDD Test Style Example
  262. 262. Things you don‘t care about You want to prevent specifying things you don‘t care about in your current test… …but sometimes you are still forced to do so We don‘t care how Store internally keeps its stock We don‘t care about the store manager
  263. 263. Test Data Builders Let you create test data conveniently Declare sensible defaults for mandatory fields Syntactic sugar improves legibility
  264. 264. Internals of a Test Data Builder Data can be conveniently specified... Sensible default values Syntactical sugar build() creates actual object …by chaining with-methods
  265. 265. Matchers assertThat(audience, is(paying(attention));
  266. 266. What is Hamcrest? According to project homepage: Provides a library of matcher objects (also known as constraints or predicates) allowing 'match' rules to be defined declaratively, to be used in other frameworks. Typical scenarios include testing frameworks, mocking libraries and UI validation rules. Hamcrest it is not a testing library: it just happens that matchers are very useful for testing. Source: http://code.google.com/p/hamcrest/
  267. 267. Typical usage example Wait! Why don‘t we just stick with good old assertEquals() here? Looks equally fine, aye?
  268. 268. Assertions on Collections Wouldn‘t you prefer this?
  269. 269. Descriptive Error Messages With Hamcrest this will change into:
  270. 270. Combining Matchers
  271. 271. Custom Matchers Hide or combine complex matching logic Improve overall legibility of test & error log
  272. 272. Mocking given(oxygen.isAvailable()).willReturn(true); verify(oxygen, atLeastOnce()).isAvailable();
  273. 273. Types of Test Doubles Dummy objects are passed around but never actually used Fake objects actually have working implementations, but usually take some shortcut Stubs provide canned answers to calls made during the test and may also record information about calls Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive “Mocking” is often used as a general term for all four
  274. 274. Why Mocking? Control dependencies to test classes in isolation Create fake implementations of classes or interfaces Define behavior of fake implementations Verify expected behavior of units under test
  275. 275. Control Dependencies
  276. 276. Control Dependencies
  277. 277. Inject Dependencies Inject dependencies into classes via constructor or setter Avoid constructing dependencies inside a dependent class via new operator Avoid directly referencing static methods from utility and helper classes! Static things can not easily be mocked Requires additional libraries like PowerMock Will perform magic tricks with Java classloading… …and have severe performance impact on your tests!
  278. 278. Dependency Control Example We depend on this… …but there‘s no implementation yet! And: We only want to test this unit!
  279. 279. Setting up a Test with Mockito Runner takes care of initializing all mocks Unit under test… Mocked Dependency …gets initialized normally
  280. 280. Defining and using the @Mock The behavior of the mock is defined within the //given block of the test All undefined methods of a mock do nothing (for void return parameters) return null (in all other cases)
  281. 281. Verifying @Mock behavior Mocks remember all interaction You can verify how often and in which order mocked methods have been called Failed verifications work just like failed assertions Beware: Verifications should not be overused! Concentrate on the unit under test, not its mocks
  282. 282. Excercise 7
  283. 283. Add Hamcrest and Mockito to your classpath Move both above JUnit to avoid strange phenomenons…
  284. 284. Add Favorites for static imports
  285. 285. Trading Card Game – Part 5 Back to Pair Programming Choose your favorite partner  TDD / BDD is mandatory! Use Hamcrest matchers and Builders! Mock if you feel the need for it! Common code baseline to start with https://github.com/bkimminich/kata-tcg
  286. 286. Getting Ready to Code Get the source code https://github.com/bkimminich/kata-tcg/fork or git clone https://github.com/bkimminich/kata-tcg.git Import project into any IDE (with Gradle support) automatically from gradle.build or import sources in tcg-java and setup manually JDK 1.8 with compiler compliance/language level 8.0 JUnit 4, Mockito 1.10, Hamcrest 1.3, System Rules 1.12 Got an implementation in a cool and/or exotic language?
  287. 287. Advanced Rule Minions (I) Let players choose to play cards either as immediate damage Attacks (as in Basic Gameplay) as Minions that are put on the board instead Minions will use the mana cost of their card as Health and Damage value Playing a 0 card will create a minion with 1 Health and 0 Damage Health has to be tracked when they receive damage 29 -xx ==xx Source: https://github.com/bkimminich/kata-tcg
  288. 288. Advanced Rule Minions (II) Each player can have a maximum of 3 Minions on the board at any given time A Minion will sleep in the turn it was put on the board In any subsequent turn each Minion can be used once to deal damage to the opponent player or an opponent Minion 29 -xx xx 29 -xxx Zzz Zzzz Source: https://github.com/bkimminich/kata-tcg
  289. 289. Advanced Rule Minions (III) A Minion fighting another Minion will result in them dealing their damage value to each other simultaneously Sleeping Minions will defend themselves in the same way when attacked by another Minion xx yy-x-y xx yy-x-y Zzz Zzzz Source: https://github.com/bkimminich/kata-tcg
  290. 290. Advanced Rule Minions (IV) Players can choose to play an Attack against a Minion. The attacked Minion will not defend itself in this case, thus the attacking player receives no damage from it When a Minions health drops to or below zero it is removed from the board yy-x x x0 -1 … Source: https://github.com/bkimminich/kata-tcg
  291. 291. Lecture 8 Code Retreat „Game of Life“
  292. 292. The Musician Metaphor
  293. 293. The Superhero Metaphor
  294. 294. Code Retreat A day-long, intensive practice event, focusing on fundamentals of software development and design Provides developers the opportunity to take part in focused practice, away from the pressures of 'getting things done’ Highly effective means of skill improvement Practicing the basic principles of modular and object- oriented design, developers can improve their ability to write code that minimizes the cost of change over time Source: http://coderetreat.org/about
  295. 295. Structure of a Code Retreat (formalized by Corey Haines) Problem: Conway's Game of Life Length of Session: 45 minutes Duration: 8.30am to 5 or 6pm Pair-programming is necessary, as the knowledge transfer contained in that activity is essential to the practice Prefer using Test-Driven Development (TDD) After each session, pairs should be swapped After each session, code must be deleted, not put in a branch, not stashed, just deleted with no trace left Source: http://coderetreat.org/facilitating/structure-of-a-coderetreat
  296. 296. Typical Code Retreat Day Outline 8 - 8.45am : arrival, coffee/breakfast 8.45 - 9am : welcome, introductions, explanation of the problem 9 - 9.45am : Session #1 9.45 - 10am : retrospective, break 10 - 10.45am : Session #2 10.45 - 11am : retrospective, break 11 - 11.45am : Session #3 11.45 - 12pm : retrospective, break 12 - 1.30pm : lunch, socializing 1.30 - 2.15pm : Session #4 2.15 - 2.30pm : retrospective, break 2.30 - 3.15pm : Session #5 3.15 - 3.30pm : retrospective, break 3.30 - 4.15pm : Session #6 4.15 - 4.30pm : retrospective, break 4.30 - 5pm : Closing circle Source: http://coderetreat.org/facilitating/structure-of-a-coderetreat
  297. 297. (Mini-)Code Retreat Agenda 2-3 sessions 45 min developing TDD Pair Programming Clean Code Delete the code 15 min retrospective 15 min break
  298. 298. Conway‘s Game of Life Cellular automaton Invented by mathematician John Conway in 1970 Zero-Player Game Evolution is determined only by the initial state Two-dimensional grid of square cells Each cell can be either alive or dead Each cell interacts with ist 8 neighbors Four rules determine the games evolution All cells evolve simultaneously from one generation to the next Source: http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life
  299. 299. Rule 1: Underpopulation Any live cell with fewer than two live neighbours dies, as if caused by under- population
  300. 300. Rule 1: Underpopulation Any live cell with fewer than two live neighbours dies, as if caused by under- population
  301. 301. Rule 2: Living On Any live cell with two or three live neighbours lives on to the next generation.
  302. 302. Rule 2: Living On Any live cell with two or three live neighbours lives on to the next generation.
  303. 303. Rule 3: Overcrowding Any live cell with more than three live neighbours dies, as if by overcrowding
  304. 304. Rule 4: Reproduction Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction
  305. 305. Example: Glider
  306. 306. Game of Life Examples Blinker Glider Lightweight spaceship (LWSS) Pulsar Glider Gun Source: http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life
  307. 307. Border Behavior: Wall of Death
  308. 308. Border Behavior: Pacman Universe
  309. 309. Spicing up the excercise Shuffling Pairs before every round Using different programming languages Different styles of Pair Programming Different rules from the Object Calisthenics
  310. 310. Time Boxing Developer 1 writes test + code for X minutes. Developer 2 writes test + code for X minutes.
  311. 311. Ping Pong Developer 1 writes new test that fails. Developer 2 writes the code needed to pass the test. Developer 2 writes next test that fails. Developer 1 writes the code needed to pass the test.
  312. 312. Driver & Navigator Driver writes test + code. Navigator reviews each line and considers the strategic direction of work. Switch roles.
  313. 313. Object Calisthenics No if statements No loops Small methods (< 5 lines, 1 line?) No primitive types TDD as if you meant it Top-Down Design Bottom-Up Design Without mouse Tell don't ask – no getters and setters Functional, no state One level of indentation No else One dot per line No abbreviations Everything is small No classes with more than two instance variables Use of first-class collections No talking Source: http://pragprog.com/book/twa/thoughtworks-anthology
  314. 314. Session One Pair Programming Style Time Boxing Object Calisthenics Everything is small 45min programming Code must be deleted afterwards
  315. 315. Session Two Pair Programming Style Ping Pong Object Calisthenics No loops One dot per line 45min programming Code must be deleted afterwards
  316. 316. Session Three Pair Programming Style Ping Pong Object Calisthenics No talking 45min programming Code must be deleted afterwards
  317. 317. Lecture 9 Code Quality Measurement Feedback
  318. 318. Code Quality Measurement
  319. 319. Code Quality Measurement Tools Static Code Analysis FindBugs CheckStyle PMD Code Coverage EMMA Cobertura Quality Management Platform SonarQube Most tools offer IDE plugins!
  320. 320. Static Code Analysis Rule based detection of code smells potential bugs coding standard violations Do not rely solely on these tools! False positives are an annoying issue Rules can often be „cheated“ on „Soft factors“ can not be validated expressiveness of names quality of comments
  321. 321. Fix the problem, not the issue! Issue Problem Issue Problem
  322. 322. Excercise 9 The Final Excercise
  323. 323. Surprise, surprise: Game of Life Develop a complete implementation of Conway‘s Game of Life Create a brief up-front technical design in UML Define a behavior for the universe borders Border of dead cells? Pacman-style infinity? …? Implement the UI in your favorite Rich Client API Swing, SWT, RCP, … Do TDD or at least write good tests along the way
  324. 324. Feedback Follow the Doodle link in your invitation email Please provide at least a star-rating Additional feedback is highly appreciated What did you like best about the workshop? What could have been better? What didn‘t you like at all?
  325. 325. The End Thank you for your attention!
  326. 326. Credits Robert C. Martin, @unclebobmartin (Clean Code, TDD, Bowling Code Kata) Prof. Dr. Frank Zimmermann (Agile Software Development) Sascha Krüger (Unit Testing, Hamcrest, Mockito) Lukas Hinsch (Unit Testing, Hamcrest, Mockito) Sebastian Bergandy, @SebastianBergan (Clean Code, Code Retreat) Gunnar Morling, http://gunnarmorling.de (Code Retreat) Oliver Widder, @geekandpoke (Geek & Poke Cartoons, http://geek-and-poke.com/) Blizzard Entertainment (Kata TCG, Permission of use requested for images) Hearthstone: Heroes of Warcraft® is a trademark or registered trademark of Blizzard Entertainment, Inc., in the U.S. and/or other countries.