- regelmäßiges Austauschformat zu praktischen Themen der Softwareentwicklung
- jeden Freitag 12:30 Uhr in der Mittagspause per Webkonferenz
- standardmäßig versuchen wir uns gemeinsam an einer Kata (Timer)
- alternativ nehmen wir uns nach Absprache Spezialthemen vor
- es gibt bei Slack im ICM-VC Workspace auch einen
coding-dojoKanal
weekly meetings, but undocumented
- Data Munging Kata - Part Three
- Data Munging Kata - Part Two
- Data Munging Kata - Part One
- Mars Rover Kata - Teil 3
- Mars Rover Kata - Teil 2
- Mars Rover Kata - Teil 1
- siehe Commit-Historie
- Vorschlag: Medicine Clash Kata
- Kata: Smelly Tic Tac Toe
- Topics:
- Identify code smells (Primitive obsession, Feature envy, Data class, Message chain, Long method, Comments, Long parameter list, Shotgun surgery, Duplicated code, Large class, Divergent change, Data clump, Lazy class, Dead code)
- Apply appropriate refactorings (see table)
Parallel change kata by Pawel Duda and Carlos Blé
Change the class ShoppingCart. The class should be able to handle multiple items instead of the single one it currently supports. Run the tests every time you make a change. The tests must not be red at any time. No compile-errors, no failures. Commit. Refer to the Parallel Change code by Pawel Duda and Carlos Blé.
- TDD-Crashkurs (FizzBuzz-Kata)
- TDD loop:
- red - write a failing test
- green - make it pass
- refactor
- Test anatomy:
- arrange - act - assert (or: given - when - then)
- TDD rules:
- Write only enough of a unit test to fail
- Write only enough production code to make the failing unit test pass (choose the most obvious implementation)
- eliminate duplication (rule of three)
- TDD loop:
- Bank OCR Kata (Tests, Code)
- Retrospective:
- How readable are your test cases? Can you look at them and easily see which digits are being parsed?
- What would happen if the input changed format to 12 digits instead of 9? How well would your code cope?
- Bank OCR Kata (Tests, Code)
- Topics
- Refactor code readability/understandability first
- Use the IDE to refactor quickly and safely
- Stay on the green while refactoring
- Bank OCR Kata (Code)
- Kata: Multiples of 3 or 5 (codewars.com) - Solution
- Bank OCR Kata (Code)
- Bank OCR Kata (Code)
- Bank OCR Kata (Code)
- Themen
- Refactoring: extract class
- Mikado method for refactoring legacy code
- Code smell: primitive obsession
- High cohesion
- Remote mob programming
- Link: mob retreat
- Bank OCR Kata - User story 2
- Free-style Mob mit Timer (5-7 Minuten)
- Bank OCR Kata - User story 1
- TDD ping-pong style
- Kata: Is a number prime?
- 5-7 Minuten Timer für Rollentausch Driver ↔ Navigator
- Thema: Arbeiten mit Legacy Code
- long class
- multiple layers of abstractions in same method / class
- map initialization by anonymous sub-class -> own map builder or Map.of(..)
- interface name prefix
- bad formatted code
- magic values -> replace with constants
- long method -> extract method
- comments about what -> extract method
- unpronounceable variable names
- method with long parameter list -> extract class or introduce parameter object
- throws Exception -> list all types for appropriate handling
- duplicated code
- there are some use case for reflection
- multiple if's with enums -> switch case
- multiple if's -> polymorphism
- in-place retrieval of configuration -> inject configuration values
- in-place parsing of configuration values -> type-save configuration retrieval
- workarounds -> descriptive method names + comments about why
- Agile Technical Practices Distilled
- Effective Java
- Working Effectively with Legacy Code
- Java by Comparison: Become a Java Craftsman in 70 Examples
- Refactoring: Improving the Design of Existing Code (1st ed., Java), (2nd ed., JavaScript)
- Kata: codewars.com - Split Strings
- Lösung: StringSplitTest.java, StringSplit.java
- Themen
- Vorteile von AssertJ gegenüber Basis-Assertions von JUnit
- Kata: codewars.com - Sum of Digits / Digital Root
- Lösung
- Themen
- Order of tests
- Antipattern: Reaching for the gold to soon
- Off-by-one error
- Rekursion
- Kata: codewars.com - Find the odd int
- Themen
- Maven-Projektstruktur
- TDD-Konzepte
- Baby Steps
- Stair Step Tests
- Find The Loophole
- Transformation Priority Premise
- Produktivitätstipps IntelliJ IDEA
- Kata: codewars.com - ATM
- Kata: codewars.com - Sum of positive
- Java Stream API
- Train Reservation Kata - Teil XI
- Geschäftslogik vollständig implementiert
- letzter Commit
- Themen
- Wann Redundanzen auflösen?
- Bug exposing tests
- Detroit vs. London School
- Train Reservation Kata - Teil X
- Themen
IntStream, primitive boxing, unboxing- Reduktion von Konstruktoraufrufen im Test-Setup
- Test-Code-Refactoring
- Builder Design Patttern
- vararg-Methoden
- Train Reservation Kata - Teil IX
- Themen
- kurze Wiederholung AssertJ, Mockito und WireMock
- Trennung von Implementierungs- und Refactoring-Schritt
- Implementierung von Geschäftslogik bei gefühlt nicht optimal strukturierten Geschäftsobjekten
- neue Funktionen in Java Collections (z.B.
Map.compute*(...))
- Link Devs@Home API Testing Mit Consumer Driven Contracts (CDC)
- Link Devs@Home Test-Tools
(Karfreitag)
- Train Reservation Kata - Teil VIII
- JAXenter.de Devs@Home: Einführung in Go – Live-Webinar
- Train Reservation Kata - Teil VII
- Zwischenergebnisse: Commit
- Themen:
- Single Assert Rule
- komplexe Asserts mit AssertJ Conditions
- Train Reservation Kata - Teil VI
- Zwischenergebnisse: Commit
- Themen:
- Geschäfsregeln in Unit-Tests umsetzen
- null vs. empty
- Train Reservation Kata - Teil V
- unser Zwischenstand: KataTrainReservation
- Themen
- manuelle JSON-Verarbeitung aufgrund verletzter Format-Konventionen
- JSON - Bad Practices
- Zahlen als Strings
- Struktur Geschäftsobjekte
- Eingabe vs. Nutzung
- zukünftige Anforderungen
- Train Reservation Kata - Teil IV
- unser Zwischenstand:
- Themen:
- JAX-RS / JSON-P Test-Dependencies
- Konfiguration mehrerer HTTP-Server-Mocks
- Test-Ressourcen einlesen
- JSON - Bad Practices:
- Objekte statt Arrays zur Abbildung von Listen
- Daten im Schlüssel statt im Wert
- JSON-P versus JSON-B
- Java default package
- Train Reservation Kata - Teil III
- unser Zwischenstand:
- Themen:
- Java EE 8
- REST-Client-Implementierung mit JAX-RS 2.1 (JSR-370)
- Testen eines REST-Clients mittels WireMock (JUnit 5 Extension)
- Train Reservation Kata - Teil II
- unser Zwischenstand:
- Train Reservation Kata - Teil I
- unser Zwischenstand:
- Gilded Rose Kata - Teil IV
- Original:
- unser Endergebnis:
- Retrospektive:
- Discussion points about Designing Test Cases
- Did you need to do some refactoring before you could get the code under test at all?
- Did you make mistakes while refactoring that the tests caught?
- Have you tried running the text-based tests to see if they catch refactoring mistakes your tests have missed?
- Did you find any bugs in the code when writing your tests?
- Did you find any omissions or ambiguities in the requirements document?
- Did you miss important tests that you had to add later? Did you go back and run them against the original version of the code?
- How good is the statement coverage of your tests?
- Could you easily identify the cause of failing tests?
- Discussion points about Design and Refactoring
- Were you prepared to argue with the goblin about changing the Item class? How did that decision change your design options?
- When you were refactoring, did you keep in mind the new feature you intended to add?
- Think about the design you ended up for the code. How easy would it be to add other new features? (For example weekly reports on overall stock quality, or support for interactive stocktaking)
- Review your refactoring session in a test run logging tool, (if you used one - see Tools for the Dojo). How large steps did you take? Could you have taken smaller steps?
- Were your test cases good enough to support refactoring or were you worried they missed things?
- Discussion points about Designing Test Cases
- alternative Lösung in C#
- Gilded Rose Kata - Teil III
- unser Zwischenergebnis: GildedRoseTest.java
- Gilded Rose Kata - Teil II
- unser Zwischenergebnis: GildedRoseTest.java, GildedRose.java
- Gilded Rose Refactoring Kata (Anforderungen)
- unser Zwischenergebnis: GoldenMasterTest.java, GildedRose.java
- Themen:
- Legacy Code
- Refactorings
- Golden Master
- Custom Christmas Tree Kata (von codewars.com)
- unser Ergebnis: ChristmasTreeTest.java, ChristmasTree.java
- Bowling Game Kata (Robert Martin)
- unser Ergebnis: BowlingTest.java, Bowling.java
- Backwards Roman Numerals Kata
- Constraint: RegEx
- unser Ergebnis: regex101.com/r/vyMdVX/1, RomanNumerals.java, RomanNumeralsTest.java
- Fazit
- der regulärer Ausdruck kann eine römische Zahl in Gruppen zerlegen und eignet sich zur Validierung von String-Eingaben
- die Zahlenumwandlung selbst würde zu viele Ersetzungsregeln benötigen
- Roman Numerals Kata mit etwas Upfront-Design
- unser Ergebnis: RomanNumerals.java, RomanNumeralsTest.java
- Themen:
- TDD baby steps vs. bigger steps
- Kent Beck: TCR (test && commit || revert)
- IntelliJ IDEA plugin Limited WIP
- How do I break out of nested loops in Java?
- kurze Retrospektive zur "Tic Tac Toe"-Kata (Alternative Lösung)
- Leap Year Kata (Ergebnis)
- Roman Numerals Kata (Zwischenergebnis)
- "Tic Tac Toe"-Kata
- Constraint: Object Calisthenics
- Ergebnis: Git repository
- Fortsetzung Phone Numbers Kata
- Testdaten aus Datei lesen
- Wenn API-Änderungen die Tests kaputt machen (Refactoring-Ansätze) ...
- Abschätzung von Laufzeitverhalten für Verarbeitung großer Datenmengen (O-Notation)
- Performance-Vergleich unterschiedlicher Implementierungen
- Testreihenfolge
- Testnamen
- Vergleich JUnit / AssertJ assertions
- Java Stream API
- Refactorings, wann?
- TripService Kata - Teil 2
- Unser Ergebnis: Source, Commits
- Auflösung: Testing legacy: Hard-wired dependencies: Part 1, Part 2 oder Video
- automatische IDE Refactorings
- JUnit 5 (
assertThrows(),@BeforeEach) - Richtung OOP refaktorieren
- Mockito: Mock-Initialisierung für Klassen mit parametrisiertem Konstruktor
- Methodenlänge
Wir könnten uns hier eine Kata heraussuchen, z.B.:
- Recap: Kata, Dojo, TDD
- Rollen im Pair Programming / Mob Programming
- an der Tastatur: Driver vs. Typist
- Partner: Backseat Driver vs. Navigator vs. Moderator
- Mob: Konsens vs. Vorschläge
- Teststruktur: Arrange-Act-Assert bzw. Given-When-Then
- Umgang mit statischen Methoden beim Testen von Legacy Code
- Zwischenstand: TripServiceTest.java
- Software Craft and Testing Conferences
- Software Craftsmanship
- Was ist eine Code Kata?
- Was ist ein Coding Dojo?
- Test-driven development
- Pair Programming, Mob Programming
- JUnit 5, AssertJ, parametrisierte Tests
- Buch: Agile Technical Practices Distilled
- Fizz Buzz Kata: Fizz Buzz@Clean Code Developer School
- GitHub code repository: Zwischenstand, Final
- Beiträge, Vorschläge, Wünsche jeder Zeit gern
- Train: Fold an array | Codewars
- String Calculator Kata (Roy Osherove)
- Kyu 8 bis 6 Katas mit Stream-API (codewars.com)
- property-based testing (PBT)
- test && commit || revert (TCR)
- docker
- git
- triple stores
- beim DFN sind drei Räume eingerichtet
- Veranstalter-PIN auf Anfrage
Um an dem Meeting teilzunehmen, haben Sie folgende Möglichkeiten:
-
Mit Ihrem Browser unter Windows, MacOS, GNU/Linux: https://conf.dfn.de/webapp/conference/97979820
-
Mit einem SIP/H.323-Raumsystem oder SIP/H.323-Client:
H.323: 004910097979820 SIP: 97979820@conf.dfn.de
-
Mit einem Telefon (nur Audio): Wählen Sie 0049 30 200 97979820
-
Über Skype for Business: 97979820@vc.dfn.de
-
Mobil mit Smartphone: Voraussetzung ist die vorinstallierte Pexip App unter
- Android: https://play.google.com/store/apps/details?id=com.pexip.infinityconnect
- iOS: https://itunes.apple.com/us/app/pexip-infinity-connect/id1195088102
Geben Sie ein: 97979820@conf.dfn.de
Um an dem Meeting teilzunehmen, haben Sie folgende Möglichkeiten:
-
Mit Ihrem Browser unter Windows, MacOS, GNU/Linux: https://conf.dfn.de/webapp/conference/97979821
-
Mit einem SIP/H.323-Raumsystem oder SIP/H.323-Client:
H.323: 004910097979821 SIP: 97979821@conf.dfn.de
-
Mit einem Telefon (nur Audio): Wählen Sie 0049 30 200 97979821
-
Über Skype for Business: 97979821@vc.dfn.de
-
Mobil mit Smartphone: Voraussetzung ist die vorinstallierte Pexip App unter
- Android: https://play.google.com/store/apps/details?id=com.pexip.infinityconnect
- iOS: https://itunes.apple.com/us/app/pexip-infinity-connect/id1195088102
Geben Sie ein: 97979821@conf.dfn.de
Warten Sie, bis Ihr Veranstalter den Meetingraum betreten hat.
Für einen Verbindungstest rufen Sie bitte folgende Webseite auf: https://www.conf.dfn.de/beschreibung-des-dienstes/zugangswege/testcall-service/
Bitte beachten Sie auch die Hinweise zum Datenschutz unter https://www.conf.dfn.de/datenschutz