Agile SoftwareDevelopment
inPractice
withCleanCodeandTestDrivenDevelopment
v1.42 (01.09.2015)
Björn Kimminich
https://twit...
Björn Kimminich
2007+
Senior Manager
IT Architecture at
Kuehne+Nagel
Former Developer,
Architect and
Security Officer in
C...
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 exercis...
More Organizational Stuff
Rules of Behavior
•No other work/“work“ done during lectures
•Feel free to interrupt with questi...
Agenda I
•Right & Duties
•The Agile Manifesto
•Agile Techniques
•Scrum
Agile Software Development
•Building a Mars Station...
Agenda II
•Motivation
•Names
•Functions
•Comments
•Formatting
Clean Code
•Writing a clean Trading Card Game from scratch
E...
Agenda III
• Unit Tests
• Junit 4
• Test Driven Development (TDD)
• BDD Test Style
• Matchers
• Mocking
Testing
• Adding a...
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
Agile Software
Development
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-w...
Agile Software Development
Agile Software Development takes into
account the short innovation cycle
Quick customer feedbac...
Rights and Duties – Customer
Rights
• Define release content
• Receive agreed scope
• Change requirements
Duties
• Express...
Rights and Duties – Developer
Rights
•Independent effort
estimation
•Risk estimation
•Define release scope
Duties
•Adhere ...
AgileManifesto.org
Source: http://agilemanifesto.org/
Agile Development Techniques
Iterative Process
User Stories
Transparent Estimation Process
Test Driven Development
Regress...
Iterative Process
An Iteration should not take longer than 2-4 weeks
Each Iteration delivers new functionality with busine...
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...
Planning Poker II
Source: http://www.axisagile.com/resources/scrumtrooper-images/
Test Driven Development
1. Write a failing test
2. Write the (smallest) amount of code to pass the test
3. Refactor
You ar...
Regression Tests
Test Suites contain all class Unit Tests
Suites should be executed
After every finished development task
...
Pair Programming
Two developers program on one computer
One active programmer
One observer
reviewing each line of code
con...
Collective Code Ownership
Abandons any notion of individual ownership
of modules (“my code” vs. “your code”)
Code base is ...
Continuous Integration
Build Server continuously checks out
sourcecode from version control system
Builds software and run...
Refactoring
Disciplined technique for
restructuring existing code
Alters internal structure without
changing external beha...
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 functiona...
Scrum Ceremonies
Sprint planning
the team meets with the product owner to choose a set of
work to deliver during a sprint
...
Daily Scrum
Source: http://www.axisagile.com/resources/scrumtrooper-images/
Sprint Retrospective
Source: http://www.axisagile.com/resources/scrumtrooper-images/
Scrum Artifacts
Product backlog
ordered list of ideas for the product
Sprint backlog
set of work from the product backlog ...
Excercise 1
Building a Mars Station
Goal
Build a Mars Station model with DDR building
blocks using Agile Development techniques
Iterative Process
User Stories...
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
R...
Sprint 0
CTO Mars Tech Inc® shares Vision of the
project with the team
Project is staffed
Product Owner defines first set ...
User Story Examples I
As an astrophysicist I want a
deep space observatory So that I
can study the stars.
As a communicati...
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 ...
Sprint 1-3
Sprint Planning (15min)
PO presents new User Stories
Team estimates effort
Team defines Sprint Backlog
Sprint (...
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?
Ca...
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...
Mandatory Literature for
Software Craftsmen
Clean Code
Robert C. Martin, 2008
The Clean Coder
Robert C. Martin, 2011
http:...
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 no...
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 th...
The Grand Redesign VI
…while rest of the developers (=B to Z-Team)
have to keep maintaining and add new
features to the ol...
The Grand Redesign VII
…forcing the A-Team to keep up with the old
system‘s changes while building the new
system from scr...
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
Into...
Who‘s to blame for Bad Code?
Unclear Requirements
Last-minute Change Requests
Tight Project Schedules
Stupid Managers
Into...
What is Clean Code?
Can be read and enhanced by a developer other than
its original author
Has unit and acceptance tests
D...
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)
"A...
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-...
Clean Code in a Nutshell
WE CARE FOR OUR CODE
Other developers can
read
understand
maintain
the code we write
Changed and ...
What is Legacy Code?
Legacy code. The phrase strikes disgust in the hearts of
programmers. It conjures images of slogging ...
Dealing with our own Legacy Code
Gradually clean up Legacy Code you are working on
Include efforts for the following preli...
Let‘s wrap up the „Motivation“…
Names
Don‘t be just smart
In general programmers are pretty smart
people
One difference between a smart programmer
and a profess...
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 comm...
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...
Entrenched vs. intended meaning
No Language Mashups
Pronouncable Names
class BaseDxoProcessMilestone7600LstBo
class Dx2FltrShipmentCustPartyXDto
class GyqfaChBppResDao
class ...
l0O1 should be avoided
No Encodings
No member prefixes
int m_price; // member variable
int g_count; // global variable
int s_total; // static mem...
No Unnecessary Context
Interface vs. IInterface
No „I“ in front of Interface names
Sometimes encoding is necessary to
avoid name clash with imple...
Consistent Lexicon
Pick one word per concept
findSomething()
findsearchSomethingElse()
findgetSomethingCompletelyDifferent...
The Scope Rule
Methods
Methods that are called from far and wide
should have short evocative names
Methods in small scopes...
Long Method Scope = Short Name
Component service
interface  Public
API  Long Scope
create(NetsurveyRunDts
netsurveyRun)
...
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...
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
name...
The Scope Rule
Summary
Methods
Long scope = Short name
Short scope = Long name
Variables
Long scope = Long name
(Short sco...
Excercise 2
Ongoing Excercise Topic:
Trading Card Game
Problem domain should be new for most
Starting clean on a „green field project“...
The Problem Domain
A […] trading card game (TCG) […] is
a card game that uses specially
designed sets of playing cards […]...
TCG Rules
Visual explanation of the rules
http://slideshare.net/BjrnKimminich/practicing-advanced-unit-testing/7
Complete ...
TCG Rules
Preparation (I)
Each player starts the game with
30 Health
0 Mana slots
Each player starts with a deck of
20 Dam...
TCG Rules
Preparation (II)
One player is randomly chosen to be the
starting active player
The other player draws a 4th car...
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
re...
TCG Rules
Basic Gameplay (II)
3. The active player draws a random card from
his deck
4. The active player can play as many...
TCG Rules
Basic Gameplay (III)
5. If the opponent player's Health drops to or
below zero the active player wins the game
6...
123
TCG Rules
Special Rules
Bleeding Out: If a player's card deck is empty
before the game is over he receives 1 damage
in...
Trading Card Game – Part 1
Create a two-player hotseat „TCG“
Concentrate on game logic, not on fancy GUI
Do not implement ...
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 mou...
Function Size
Functions should be small
Functions should hardly ever be >20 lines
Blocks within if/else/while etc. should ...
Function Indentati n Level of 14o
What‘s wrong with this method?
It does not do one thing!
It should be two methods!
findSupplierByCipId(Long id)
findSuppli...
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...
Law of Demeter I
A method should only call
methods of its own class
methods of its parameters
methods of associated classe...
Law of Demeter II
Law of Demeter III
For pure data structures LoD does not apply
int leftMargin = config.layout.margins.left;
List<Orderline...
Compose Method
Divide your program into methods that
perform one identifiable task
Keep all of the operations in a 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-m...
Method Object
Create a new class
Add an instance variable for each local variable and
each parameter of the original metho...
Demo
Method Object
Compose Method
Arguments
 No input arguments
 One input argument
 Two input arguments
 Three input arguments
 Four or more input arg...
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 repres...
Output Arguments
Harder to understand than input arguments
Unexpected function behavior
Input = Arguments
Output = Return ...
Can you spot a Problem here?
Assigning method parameters is bad practice
Intention is entirely unclear to the reader
Param became obsolete at some poin...
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
gene...
The Final Dillemma
In Clean Code, final…
…only hurts legibility a little bit
…but is seldom needed to prevent bugs
In Bad ...
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
b...
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 th...
Do not work with null
Returning null from a method is
bad! Instead…
…return empty collection
…consider throwing an Excepti...
java.util.Optional (since JDK8)
= A container object which may or may not
contain a non-null value. Offers methods
dependi...
Optional in Action
Special Case Pattern
= A subclass that provides special behavior for
particular cases. Useful for…
…non-aborting error sit...
Excercise 3
Trading Card Game – Part 2
Add a single player vs. computer
game mode to your TCG
The bot should play smart but
doesn‘t ha...
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 ours...
Comments II
Comment bad code
Clean up bad code
Delete bad comments
/*Highlighting*/ comments
in Eclipse makes them
easier ...
HTML in Javadoc I
Uncle Bob considers HTML in Javadoc a bad
comment
because he likes to have it readable in the code…
…and...
HTML in Javadoc II
On the other hand…
…Eclipse has a Javadoc View
…exported and frequently read Javadoc from
Frameworks or...
Good Comments
Legal Comments
Public API Javadoc
Informative Comments
Explanation of Intent
Clarification
Warning of Conseq...
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
preven...
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...
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 dif...
Anti-Tool: JAutodoc
Well-meant but ill-
conceived Eclipse plugin
Automates
UnCamelCasing in
perfection
Do not use this or
...
Formatting
Vertical Formatting
How long should a source file be?
Typical file size ~200 LOC
Upper limit ~500 LOC
Vertical Openness
Bl...
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...
OneLine = 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
[Uncle B...
Excercise 4
Trading Card Game – Part 3
Same students as last time should pair up…
…but work on the code of another pair!!!
Cleanup tim...
Clean Code Cheat Sheet
Names
•Intent
•Pronouncable
•Lexicon
•Scope Rule
•Disinformation
•Encodings
•Prefixes
Functions
•Sm...
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 inte...
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
Selfvalidating
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 ap...
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 At...
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
method...
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 ...
Excercise 5
Testing TCG
Create unit tests for various classes of your
TCG implementation
Concentrate on testing logic like
Game rules ...
Lecture 6
TDD
Code Kata
„FizzBuzz“
TDD
Test Driven
Development
Test Driven Development
Agile Projects embrace change
Changing code bears the risk to break existing
functionality
Clean C...
Red, Green, Refactor
RED: Write a
failing unit
test
GREEN: Write
production
code to make
test pass
REFACTOR:
Remove
duplic...
GreenBarPatterns
Fake it ('til you make it)
„Do the simplest thing that could possibly work”. This is a baby
(tiny) steps ...
The Magic TDD Principle
As the tests get more specific, the
codegets more generic
[Uncle Bob]
Source: http://cleancoders.c...
Code Coverage I
Code Coverage is a measure used in software
testing. It describes the degree to which
the source code of a...
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/
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 cov...
Code Coverage Goals
Code Coverage is not a managers goal…
…it must be our goal!
Absolute Code Coverage is not the best KPI...
Test Quality
Tests must be robust and stable
Tests must make sense
No-op tests
Happy path tests only
Tests w/o (reasonable...
Single Assert Rule
Each test should only do one logical assertion
One phyisical
assert is perfect
Multiple physical
assert...
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 th...
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 ...
Advanced Rule
Healing
When playing a card the active player
can choose to…
…use it to cause damage (Basic Rules)
…use it ...
Preliminary Design Session
How do we plan to integrate this rule?
What is a good test to get the TDD loop
started?
Which c...
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 blac...
Structure your tests consistently
public void shouldReturnRefundedItems() {
// given
// when
// then
}
Define test data an...
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 sometime...
Test Data Builders
Let you create test data conveniently
Declare sensible defaults for mandatory fields
Syntactic sugar im...
Internals of a Test Data Builder
Data can be
conveniently
specified...
Sensible
default
values
Syntactical
sugar
build()
c...
Matchers
assertThat(audience, is(paying(attention));
What is Hamcrest?
According to project homepage:
Provides a library of matcher objects (also known
as constraints or predi...
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
implement...
Why Mocking?
Control dependencies to test classes in
isolation
Create fake implementations of classes or
interfaces
Define...
Control Dependencies
Control Dependencies
Inject Dependencies
Inject dependencies into classes via
constructor or setter
Avoid constructing dependencies inside a
de...
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
initia...
Defining and using the @Mock
The behavior of the mock is defined within
the //given block of the test
All undefined method...
Verifying @Mock behavior
Mocks remember all interaction
You can verify how often and in which order
mocked methods have be...
Excercise 7
Add Hamcrest and Mockito to
your classpath
Move both above
JUnit to avoid
strange
phenomenons…
Add Favorites for static imports
Trading Card Game – Part 5
Back to Pair Programming
Choose your favorite partner 
TDD / BDD is mandatory!
Use Hamcrest ma...
Getting Ready to Code
Get the source code
https://github.com/bkimminich/kata-tcg/fork
or
git clone https://github.com/bkim...
Advanced Rule
Minions (I)
Let players choose to play cards either as
immediate damage Attacks (as in Basic Gameplay)
as Mi...
Advanced Rule
Minions (II)
Each player can have a maximum of 3 Minions on the board at
any given time
A Minion will sleep ...
Advanced Rule
Minions (III)
A Minion fighting another Minion will result in them dealing
their damage value to each other ...
Advanced Rule
Minions (IV)
Players can choose to play an Attack against a Minion. The
attacked Minion will not defend itse...
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 de...
Structure of a Code Retreat
(formalized by Corey Haines)
Problem: Conway's Game of Life
Length of Session: 45 minutes
Dura...
Typical Code Retreat Day Outline
8 - 8.45am : arrival, coffee/breakfast
8.45 - 9am : welcome, introductions, explanation o...
(Mini-)Code Retreat Agenda
2-3 sessions
45 min developing
TDD
Pair Programming
Clean Code
Delete the code
15 min retrospec...
Conway‘s Game of Life
Cellular automaton
Invented by mathematician John Conway in 1970
Zero-Player Game
Evolution is deter...
Rule 1: Underpopulation
Any live cell with fewer than two live
neighbours dies, as if caused by under-
population
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 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/C...
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...
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 ...
Driver & Navigator
Driver writes test + code.
Navigator reviews each line and considers the strategic
direction of work.
S...
Object Calisthenics
No if statements
No loops
Small methods (< 5 lines, 1
line?)
No primitive types
TDD as if you meant it...
Session One
Pair Programming Style
Time Boxing
Object Calisthenics
Everything is small
45min programming
Code must be dele...
Session Two
Pair Programming Style
Ping Pong
Object Calisthenics
No loops
One dot per line
45min programming
Code must be ...
Session Three
Pair Programming Style
Ping Pong
Object Calisthenics
No talking
45min programming
Code must be deleted after...
Lecture 9
Code Quality
Measurement
Feedback
Code Quality
Measurement
Code Quality Measurement Tools
Static Code Analysis
FindBugs
CheckStyle
PMD
Code Coverage
EMMA
Cobertura
Quality Managemen...
Static Code Analysis
Rule based detection of
code smells
potential bugs
coding standard violations
Do not rely solely on t...
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 techni...
Feedback
Follow the Doodle link in your invitation email
Please provide at least a star-rating
Additional feedback is high...
The End
Thank you for your attention!
Credits
Robert C. Martin, @unclebobmartin (Clean Code, TDD, Bowling Code Kata)
Prof. Dr. Frank Zimmermann (Agile Software ...
Nächste SlideShare
Wird geladen in …5
×

Agile Software Development In Practice

53.944 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
0 Kommentare
19 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
53.944
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1.679
Aktionen
Geteilt
0
Downloads
687
Kommentare
0
Gefällt mir
19
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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.

×