Advanced Agile Programming Workshop

Start with a simple Kata
Writing New code
4 Rules of Simple Design
Code Smells
Refactoring techniques
Mikado Method
Text Test
The Transformation Priority Premise (maybe)

The Romans used letters to represent numbers:
Specifically the letters "I, V, X, L, C, D, and M.“
Each letter has a value:
Numeral Number
I 1
V 5
X 10
L 50
C 100
D 500
M 1000

There were certain rules that the numerals followed:
The symbols 'I', 'X', 'C', and 'M' can be repeated at most 3 times in a row. 'V', 'L',
and 'D' can never be repeated.
As Arabic numbers can be split into their constituent parts (1066 becomes 1 0 6
6), so too can Roman numerals, just without the zero (1066 becomes MLXVI, or
M (1000) LX (60) and VI (6)).
The '1' symbols ('I', 'X', and 'C') can only be subtracted from the 2 next highest
values ('IV' and 'IX', 'XL' and 'XC', 'CD' and 'CM'). The '5' symbols ('V', 'L', and 'D')
can never be subtracted.
Only one subtraction can be made per numeral ('XC' is allowed, 'XXC' is not).

As a games designer
I want to pass in an Arabic number and get a Roman numeral
back
So that I can correctly label my game releases using Roman
numerals
When an arabic number is passed, the correct Roman numeral is
returned.
Make sure all Roman numerals between 1 and 3000 are returned
correctly.

As a customer
I want to be able to convert a Roman numeral to a number,
So that I can buy the correct version of the game
When a Roman numeral is passed, the correct Arabic number is
returned.
Make sure all Roman numerals between I and MMM are returned
correctly.

Runs all the tests
Contains no duplicate code
Expresses all the ideas the author wants to express
Minimizes classes and methods

Runs all the tests
Follows once, and only once rule
Has high cohesion
Has loose coupling

The practice of pretending a piece of function you need is
there in the form you need it
Helps in:
Testability
Cohesion
Encapsulation
Correct coupling
Readability

Hi and welcome to team Gilded Rose. As you know, we are a
small inn with a prime location in a prominent city ran by a
friendly innkeeper named Allison. We also buy and sell only
the finest goods. Unfortunately, our goods are constantly
degrading in quality as they approach their sell by date.

First an introduction to our system:
All items have a SellIn value which denotes the number of
days we have to sell the item
All items have a Quality value which denotes how valuable
the item is
At the end of each day our system lowers both values for
every item

Pretty simple, right? Well this is where it gets interesting:
The Quality of an item is never negative
“Aged Brie” actually increases in Quality the older it gets
The Quality of an item is never more than 50
“Sulfuras”, being a legendary item, never has to be sold or decreases
in Quality
“Backstage passes”, like aged brie, increases in Quality as it’s SellIn
value approaches; Quality increases by 2 when there are 10 days or
less and by 3 when there are 5 days or less but Quality drops to 0
after the concert

Check out the requirements file
Start writing according to the 4 rules of simple design
Use Coding by intentions
We’ll do a review at the end

Start from scratch
Start writing the most beautiful code in the world
If we spot a smell, we’ll direct you to its number
Until you show us the smell has been fixed, you’re blocked

1. Duplicate code
2. God method
3. God class
4. Uncommunicative name
5. Comments
6. Premature generalization
7. Arrow code
8. Embedded constants
9. Too many parameters
10. Feature envy
11. Primitive obsession
12. Middleman
13. Inappropriate intimacy
14. Data class
15. Refused bequest
16. Indecent exposure

A technique to enable multiple programmers to share and
work on the same code base
Good for
Sharing and collaboration
To replace branch and merge based strategies
To achieve true continuous integration

We start with a goal
We draw a dependency graph to help us locate a path to reach
that goals
The graph is build as we progress
The graph is neither the only way, or even the best way

The goal
Prerequisites
Leaves
Dependency Arrows
The tick

Expand Prerequisite
Revert
Tick a Leaf
Commit Changes

We start by writing the goal
We Expand Prerequisite for the goal
What do we need to do to reach the goal
We pick a single prerequisite and try to implement it
If we succeeds – than it’s a leaf and we can tick a leaf
Which is followed by commit changes
If we fail – this is not a leaf
We revert
And Expand Prerequisite of this node
Repeat until finish

We need to add a new type of Item – “Conjured”
“Conjured” items degrade in Quality twice as fast as normal items
For that to work we need to update the update quality
mechanism.
Use the Mikado method.
For now there is no need to change the general architecture of
the code.

Open source tool for acceptance tests
Used for refactoring
Create a Gold Standard
Start refactoring with small steps

Run the installer
Make sure you install to a non-space based folder
Create a new app
Point the program at the exe
Run it once, and approve it.

Start from the current code
Refactor in small steps

TDD Process is great tool for producing high quality code.
Some answers are missing:
Where do we start?
What’s the next step?
When do we stop?

The Transformations are a set of rules that helps us pick a next
step.
A complimentary technique to refactoring
They are a set of rules that helps us change the code behavior
Follows the - from specific to generic path
“As the tests get more specific, the code gets more generic.”

1. ({}–>nil) no code at all->code that employs nil
2. (nil->constant)
3. (constant->constant+) a simple constant to a more complex constant
4. (constant->scalar) replacing a constant with a variable or an argument
5. (statement->statements) adding more unconditional statements.
6. (unconditional->if) splitting the execution path
7. (scalar->array)
8. (array->container)
9. (statement->recursion)
10. (if->while)
11. (expression->function) replacing an expression with a function or algorithm
12. (variable->assignment) replacing the value of a variable.
There are probably more

The Transformations are prioritized
We prefer to use those which are higher on the list
When you write a test you aim for simpler transformation
Used correctly they should help you avoid “rabbit holes”
TDD sometime throws you on a wrong direction
Takes a lot of time and effort to get out of
(with experience you recognize those earlier)

Advanced Agile Programming Workshop

Recommended

More Related Content

Similar to Advanced Agile Programming Workshop (20)

More from AgilePractitionersIL (15)

Recently uploaded (20)

Advanced Agile Programming Workshop