Successfully reported this slideshow.
Upcoming SlideShare
×

Presented by Lior Friedman and Gil Zilberfeld at #APIL15

• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

1. 1. 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)
2. 2. 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
3. 3. 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).
4. 4. 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.
5. 5. 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.
6. 6. Runs all the tests Contains no duplicate code Expresses all the ideas the author wants to express Minimizes classes and methods
7. 7. Runs all the tests Follows once, and only once rule Has high cohesion Has loose coupling
8. 8. 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
9. 9. Title Summary Detail
10. 10. Title Summary Details
11. 11. 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.
12. 12. 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
13. 13. 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
14. 14. 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
15. 15. 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
16. 16. 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
17. 17. 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
18. 18. 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
19. 19. The goal Prerequisites Leaves Dependency Arrows The tick
20. 20. Expand Prerequisite Revert Tick a Leaf Commit Changes
21. 21. 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
22. 22. 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.
23. 23. Open source tool for acceptance tests Used for refactoring Create a Gold Standard Start refactoring with small steps
24. 24. 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.
25. 25. Start from the current code Refactor in small steps We’ll do a review at the end
26. 26. 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?
27. 27. 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.”
28. 28. 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
29. 29. 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)