Agile Software Development In Practice

Agile Software Development in Practice

with Clean Code and Test Driven Development

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/

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

Lecture 1

Organizational Stuff

Agile Software Development

Organizational Stuff

Schedule

• 9 lectures of 180min

• 2/3 head-on presentation

• 1/3 excercises and demos

• Finishing exercises at home is recommended

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…

Agenda I

•Right & Duties

•The Agile Manifesto

•Agile Techniques

•Scrum


•Building a Mars Station

Excercise

Agenda II

• Motivation

• Names

• Functions

• Comments

• Formatting

Clean Code

• Writing a clean Trading Card Game from scratch

Excercise

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

Agenda IV

•Code Kata Fizz Buzz

•Code Retreat Game of Life

Additional Excercises

Icon Legend

Goal

Tool

Quote

Source Code Examples

https://github.com/bkimminich/AgileSoftwareDevelopmentInPractice


Introduction

Targets of efficient Software Development

Source: http://labs.andrae-ag.de/2012/12/scrum-und-das-teufelsquadrat-von-sneed/

Why classic devlopment methods often fail…

Source: http://projectmanagement-ijourneys.com/project-management-illustrated-with-a-tree-and-a-swing/


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

Rights and Duties – Customer

Rights

• Define release content

• Receive agreed scope

• Change requirements

Duties

• Express the requirements

• Define acceptance criteria

Rights and Duties – Developer

Rights

• Independent effort estimation

• Risk estimation

• Define release scope

Duties

• Adhere to release plan

• Adhere to quality criteria

AgileManifesto.org

Source: http://agilemanifesto.org/

Agile Development Techniques

Iterative Process

User Stories

Transparent Estimation Process

Test Driven Development

Regression Tests

Pair Programming

Collective Code Ownership

Continuous Integration

Refactoring

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

User Stories

Functionality that generates business value

Brief description

Estimated by developers

Unit of Work

Task Board I

Task Board II

Source: http://www.axisagile.com/resources/scrumtrooper-images/

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

Planning Poker II



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.

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

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


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

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

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

Scrum

Source: http://www.scrumprimer.org/overview

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

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.


Daily Scrum


Sprint Retrospective


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.


Excercise 1

Building a Mars Station

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


Refactoring

Product Increment

Sprint Review

Sprint Retrospective

Roles

1x Co-Founder & CTO Mars Tech Inc®

3x Product Owner

2x Scrum Master

6x Team

nx Keen observers

Project Timeline

Sprint 0 Preparation

Release 1 Sprint 1

Sprint 2

(Sprint 3)

Deployment of Mars Station Release 1 on the Red Planet

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

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.

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.

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

Clean Code

Lectures 2-4

Source: Martin, R.C. (2008). Clean Code. Prentice Hall http://cleancoders.com/codecast

Lecture 2

Motivation

Names

Motivation

Does Clean Code matter?!

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

Do you know this man?

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]

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

http://www.cleancoders.com/

Measuring Code Quality

Source: http://www.osnews.com/story/19266/WTFs_m

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)

The Grand Redesign I

When the mess in an existing system gets overwhelming…

The Grand Redesign II

…the development team will demand a Grand Redesign of the system.

The Grand Redesign III

The best and brightest developers will form a new A-Team…

The Grand Redesign IV

…which endeavours to redesign the system as a new and shiny green field project.

The Grand Redesign V

Unfortunately the A-Team must wade through the old systems code to understand the requirements for the new system…

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…

The Grand Redesign VII

…forcing the A-Team to keep up with the old system‘s changes while building the new system from scratch.

The Grand Redesign VIII

Years pass with this race going on. The original A-Team members have long quit on their employer…

The Grand Redesign IX

…and the current members demand a redesign because the new system has become such a mess!

Who‘s to blame for Bad Code?

Unclear Requirements

Last-minute Change Requests

Tight Project Schedules

Stupid Managers

Intolerant Customers

Who‘s to blame for Bad Code?

Unclear Requirements

Last-minute Change Requests

Tight Project Schedules

Stupid Managers

Intolerant Customers

We Programmers!

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 Stroustrup Ward Cunningham Michael Feathers Grady Booch

XP Simplicity Rules (by Kent Beck, Ron Jeffries et.al.)

Source: http://c2.com/cgi/wiki?XpSimplicityRules

Broken Window Theory

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.”

A famous quote…

You are not only responsible for what you do, but also for what you don’t do.

[Laotse, 600B.C.]

Would you send an Email like this to your boss?

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

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

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]

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

Let‘s wrap up the „Motivation“…

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]

Another famous quote…

With great power comes great responsibility

[Uncle Ben, Spiderman]

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

Intent Guessing Exercise

What might these classes do?

Meaningful Names

Source: http://www.itiseezee.com/?p=83

No Disinformation

Do not leave false clues

Do not obscure the meaning of code

Entrenched vs. intended meaning

Inconsistent spelling

Entrenched vs. intended meaning

No Language Mashups

Pronouncable Names

class BaseDxoProcessMilestone7600LstBo

class Dx2FltrShipmentCustPartyXDto

class GyqfaChBppResDao

class SegmentG041Data

class KnlobiLocation

class SwotService

l0O1 should be avoided

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 …

No Unnecessary Context

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

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)

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

Long Method Scope = Short Name

Component service interface Public API Long Scope

create(NetsurveyRunDts

netsurveyRun)

updateContentEncoding

(String encoding,

Long netsurveyRunId)

Short Method Scope = Long Name

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

Long Variable Scope = Long Name

BTW: A class with 1755 LOC is a hideously

long scope…

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!

The Scope Rule Summary

Methods Long scope = Short name

Short scope = Long name

Variables Long scope = Long name

(Short scope = Short name)

Excercise 2

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

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

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!

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 8 1 3 5

? ? ?

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


? ? ? ? ? ? ?

p=0,5

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)


?/0 ?/1 ?/2 ?/10 …

?/1 1/1

?/2 2/2

?/10 10/10

…

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.


29 -x x =

?

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


0 -1 …

1 2 3

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


29 -1

0

4 5 6

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!

Lecture 3

Functions

Functions

Size Matters I

Size Matters II

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 fing hope!!!

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!

Function Indentati n Level of 14

o

What‘s wrong with this method?

It does not do one thing!

It should be two methods! findSupplierByCipId(Long id)

findSupplierBySctId(Long id)

Single Responsibility Principle

Source: http://elegantcode.com/2008/12/22/single-responsibility-principle/

SRP Violation at its best…

Side Effects

Side effects are lies!!! A function that promises to do a thing should not do other hidden things

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!

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

Law of Demeter II

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()

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

What does this method do?

Legibility boost after Compose Method refactoring

Compose Methods are change friendly

New!

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

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

Demo

Method Object Compose Method

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!!!

This should rarely happen…

…and this should never happen!

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

Output Arguments

Harder to understand than input arguments

Unexpected function behavior Input = Arguments

Output = Return Value

Often cause readers to do a double-take

Can you spot a Problem here?

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

Final on Method Parameters

Final on Local Variables

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!

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

Using Checkstyle over final

Checkstyle „Parameter Assignment“ Check

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

Specific Bean >> Generic Tuple

Avoid generic tuple classes (Pair, Triple, …) in favor of use-case specific data structures

Collections & Maps

Wrapper Classes

Wraps an unintuitive structure into an adapter class with a clear and expressive API

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

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

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

Optional in Action

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

Excercise 3


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!

Lecture 4

Comments

Formatting

Comments

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


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

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

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

Good Comments

Legal Comments

Public API Javadoc

Informative Comments

Explanation of Intent

Clarification

Warning of Consequences

TODO Comments

Legal Comments

Public API Javadoc

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!

Informative Comments II

Explanation of Intent

Clarification

Warning of Consequences

TODO Comments

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

Mumbling I

Mumbling II

Redundant Comments

Misleading Comments

Mandated Comments

Journal Comments

Noise Comments

Scary Noise

Copy & Paste Error? Redundant Field?

…?

Position Markers

Closing Brace Comments

Attributions and Bylines

Commented-Out-Code

Nonlocal Information

Too much information

Inobvious Connection

Function Headers

Javadoc in nonpublic Code

Demo

Comments

Anti-Pattern: UnCamelCasing

Splitting class/method names into Javadoc… Providing zero additional information

There are different skill levels of this art

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

http://jautodoc.sourceforge.net/

Formatting

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

Some *really* big (non-generated) Class

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

One Line = One Statement

No Inner Assignments

//=:-(*)

Do not overuse Method Chaining

Braces

For better legibility use braces even for single-line statements

Inline Conditionals

Use ?: operator for simple statements only

Do not nest ?: statements

Team Rules

Every programmer has his own favorite formatting rules, but if he works on a team,

then the team rules


Excercise 4


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

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

Lecture 5

Testing

Unit Tests

JUnit4

Testing

Good reasons to test

Source: https://en.wikipedia.org/wiki/Software_testing

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

Unit Tests

Why create unit tests?

The F.I.R.S.T rule of unit tests

F ast

I solated

R epeatable

S elf validating

T imely

Fast

Unit tests give immediate feedback about the quality of implemented changes

Isolated I

Unit tests do not require configuration Simply selecting “Run as…” in your IDE

Isolated II

Unit tests have no dependencies on a runtime environment No databases, no web services, no file systems, no ...

Repeatable

Unit tests must be automated and repeatable anytime

Self validating

Unit tests have a boolean outcome

If the specification is violated, they fail

Timely

Unit tests are written in a timely manner

Ideally before the production code

Separation of Concerns

Separate your unit and integration tests

Test Quality

Treat your tests as first class citizens

Don’t treat them worse than production code

Clean Code rules also apply to tests

JUnit 4

Hello World Unit Test

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

http://junit.org/

http://junit.org/

http://junit.org/

Adding Junit to an Eclipse project

Annotations I = Syntactic

metadata available since Java 5.0

Annotations II

Execution order of similar annotated

methods is not guaranteed!

Execution order of similar annotated

methods is not guaranteed!

Boolean Assertions

Best practice: Use just one logical

assertion per test!

Comparison Assertions

The expected result always comes first!

This is a little bit counter-intuitive.

Messages in Assertions

Demo

JUnit

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

Excercise 5

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?

Lecture 6

TDD

Code Kata „FizzBuzz“

TDD



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

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!

Green Bar Patterns

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.

The Magic TDD Principle

As the tests get more specific, the

code gets more generic

[Uncle Bob]

Source: http://cleancoders.com/codecast/clean-code-episode-19-p2/show

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

Code Coverage II

Code Coverage III

100%?!?! OMG!!! WTF?!

Let‘s hear what Uncle Bob has to say about Code Coverage…

Source: http://cleancoder.posterous.com/

http://cleancoder.posterous.com/100-test-coverage

http://cleancoder.posterous.com/100-code-coverage-again-3984

What is the purpose of this Test?

Behaviour Driven Testing

Wrong: Getting obsessed with code coverage

Right: Think about behaviour you want to test Code coverage will be automatically satisfactory

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

Test Quality

Tests must be robust and stable

Tests must make sense No-op tests

Happy path tests only

Tests w/o (reasonable) assertions

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!

Code Kata

TDD Demo with „Fizz Buzz“

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

Excercise 6

Adding some advanced rules to our TCG

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

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 -x x = = +x

31 32 …


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?

Lecture 7

BDD Test Style

Matchers

Mocking

BDD Test Style

Creating readable, explanative tests

Don’t test APIs, test behavior

Source: http://cleancoders.com/codecast/clean-code-episode-22/view

Don’t say test, say should

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

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.

BDD Test Style Example

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

Test Data Builders

Let you create test data conveniently

Declare sensible defaults for mandatory fields

Syntactic sugar improves legibility

Internals of a Test Data Builder

Data can be conveniently specified...

Sensible default values

Syntactical sugar

build() creates actual

object

…by chaining with-methods

Matchers

assertThat(audience, is(paying(attention));

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/

Typical usage example

Wait! Why don‘t we just stick with good old assertEquals() here? Looks equally fine, aye?

Assertions on Collections

Wouldn‘t you prefer this?

Descriptive Error Messages

With Hamcrest this will change into:

Combining Matchers

Custom Matchers

Hide or combine complex matching logic

Improve overall legibility of test & error log

Mocking

given(oxygen.isAvailable()).willReturn(true); verify(oxygen, atLeastOnce()).isAvailable();

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

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

Control Dependencies

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!

Dependency Control Example

We depend on this…

…but there‘s no implementation

yet!

And: We only want to test

this unit!

Setting up a Test with Mockito

Runner takes care of

initializing all mocks

Unit under test…

Mocked Dependency

…gets initialized normally

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)

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

Excercise 7

Add Hamcrest and Mockito to your classpath

Move both above JUnit to avoid

strange phenomenons…

Add Favorites for static imports


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

https://github.com/bkimminich/kata-tcg/releases/tag/v1.3.1



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?

https://github.com/bkimminich/kata-tcg/fork



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 -x x = = x

x


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 -x x x

x

29 -x x

x

Zzz Zzzz


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

x x

y y -x -y

x x

y y -x -y

Zzz Zzzz


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

y y -x

x x 0

-1 …


Lecture 8

Code Retreat „Game of

Life“

The Musician Metaphor

The Superhero Metaphor

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

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

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.30 - 4.15pm : Session #6


4.30 - 5pm : Closing circle Source: http://coderetreat.org/facilitating/structure-of-a-coderetreat

(Mini-)Code Retreat Agenda

2-3 sessions

45 min developing TDD

Pair Programming

Clean Code

Delete the code

15 min retrospective

15 min break

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

Rule 1: Underpopulation

Any live cell with fewer than two live neighbours dies, as if caused by under-population

Rule 2: Living On

Any live cell with two or three live neighbours lives on to the next generation.

Rule 3: Overcrowding

Any live cell with more than three live neighbours dies, as if by overcrowding

Rule 4: Reproduction

Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction

Example: Glider

Game of Life Examples

Blinker Glider

Lightweight spaceship (LWSS)

Pulsar

Glider Gun Source: http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

Border Behavior: Wall of Death

Border Behavior: Pacman Universe

Spicing up the excercise

Shuffling Pairs before every round

Using different programming languages

Different styles of Pair Programming

Different rules from the Object Calisthenics

Time Boxing

Developer 1 writes test + code for X minutes.

Developer 2 writes test + code for X minutes.

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.

Driver & Navigator

Driver writes test + code.

Navigator reviews each line and considers the strategic direction of work.

Switch roles.

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

Session One

Pair Programming Style Time Boxing

Object Calisthenics Everything is small

45min programming

Code must be deleted afterwards

Session Two

Pair Programming Style Ping Pong

Object Calisthenics No loops

One dot per line

45min programming


Session Three

Pair Programming Style Ping Pong

Object Calisthenics No talking

45min programming


Lecture 9

Code Quality Measurement

Feedback

Code Quality Measurement

Code Quality Measurement Tools

Static Code Analysis FindBugs

CheckStyle

PMD

Code Coverage EMMA

Cobertura

Quality Management Platform SonarQube

Most tools offer IDE plugins!

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

Fix the problem, not the issue!

Issue

Problem

Issue

Problem

Excercise 9

The Final Excercise

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

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?

The End

Thank you for your attention!

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.

Agile Software Development In Practice

Education

Transcript of Agile Software Development In Practice