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)