Dobre praktyki na kursie kolizyjnym

Post on 01-Jul-2015

174 views 5 download

description

Prezentacja ta została stworzona jako tło by móc porozmawiać o paru dobrych praktykach, które są bardzo często źle rozumiane. Skupiam się tu na Design Patterns, TDD i BDD. Sama prezentacja jest bardzo krótka, ponieważ jej rdzeń jest przechowywany na bitbucket w postaci kodu źródłowego (linki są dostępne na slajdach). Temat po raz pierwszy został zaprezentowany na http://spreadit.pl/ w 2014 r.

Transcript of Dobre praktyki na kursie kolizyjnym

Dobre praktyki na kursie kolizyjnym

Szymon Homa

@s2lomon

Design Patterns

Anty-wzorzec: „zbyt duża liczba wzorców projektowych jest szkodliwa”

Design Patterns

Anty-wzorzec: „zbyt duża liczba wzorców projektowych jest szkodliwa”

Design Patterns

Najważniejsza jest idea i meta-informacja zawarta we wzorcu(implementacja jest w zasadzie pomijalna)

Design Patterns

Przykład?

Factory Method Template MethodVS

implementacja

meta-informacja

implementacja

meta-informacja

Design Patterns

Przykład: https://bitbucket.org/szymon_homa/bad_patterns

TDD

If it’s not about a development, it’s not a TDD

Jeśli nie chodzi w tym o rozwój, to nie jest to TDD

TDD

Przykład: https://bitbucket.org/szymon_homa/bad_tdd

BDD

To że używasz Cucumber-a, nie oznacza automatycznie że stosujesz BDD

BDD

Jeżeli nie analizujesz możliwych zachowań wraz ze wszystkimi zainteresowanymi, to nie jest to BDD

BDDAnti – patterns (by Liz Keogh @Lunivore)

1. „Not having the conversations, or forcing language in conversations in order to get automated scenarios.”

2. „Too many scenarios which are functionally equivalent. Overuse of tables instead of unit tests.”

3. „Automating a brand new UI before feedback on that UI, leading to extensive rework of the automation.”

Dziękuję za uwagę.

e-mail: s2lomon@gmail.com

twitter: @s2lomon