advanced agile programming workshop
TRANSCRIPT
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 designerI want to pass in an Arabic number and get a Roman numeral backSo 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 customerI 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
Title
Summary
Detail
Title
Summary
Details
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 SellInvalue 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
We’ll do a review at the end
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 goalWe Expand Prerequisite for the goal
What do we need to do to reach the goal
We pick a single prerequisite and try to implement itIf we succeeds – than it’s a leaf and we can tick a leafWhich is followed by commit changes
If we fail – this is not a leafWe revertAnd 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
We’ll do a review at the end
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 nil2. (nil->constant)3. (constant->constant+) a simple constant to a more complex constant4. (constant->scalar) replacing a constant with a variable or an argument5. (statement->statements) adding more unconditional statements.6. (unconditional->if) splitting the execution path7. (scalar->array)8. (array->container)9. (statement->recursion)10. (if->while)11. (expression->function) replacing an expression with a function or algorithm12. (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)