Wyboista droga do Dobrego Kodu

Szymon Homa

Jaki jest Dobry Kod?

Pilnuje zasad SOLID?

Jest testowalny?

Dba o zasady Clean Code?

Jasno wyraża intencje?

Jaki jest Dobry Kod?

Jest skoncentrowany na dostarczaniu wartości zgodnie z jego przeznaczeniem.

Pozwala na łatwy rozwój systemu w oparciu o aktualną wiedzę.

Dobiera rozwiązania do potrzeb, nie nagina rzeczywistości.

A może jakiś klucz?

Alistair Cockburn, Hexagonal Architecture

Appl

icatio

nSe

rvice

s

Domain Model

Repo

sitor

ies

Event

Producers

Event

Listeners

GUI A

dapt

ers

Queue Adapters

Queue Adapters

Pers

isten

ce A

dapt

ers

A może jakiś klucz?

Alistair Cockburn, Hexagonal Architecture

Appl

icatio

nSe

rvice

s

Domain Model

Repo

sitor

ies

Event

Producers

Event

Listeners

GUI A

dapt

ers

Queue Adapters

Queue Adapters

Pers

isten

ce A

dapt

ers

Czysty Kod

TDD – testy jednostkowe pisane w większości przypadków bezużywania Test Double

Wyrażający intencje model obiektowy (DDD/RDD)

A może jakiś klucz?

Alistair Cockburn, Hexagonal Architecture

Appl

icatio

nSe

rvice

s

Domain Model

Repo

sitor

ies

Event

Producers

Event

Listeners

GUI A

dapt

ers

Queue Adapters

Queue Adapters

Pers

isten

ce A

dapt

ers

Czysty Kod

TDD – testy jednostkowe pisane z użyciem Test Double wszędzie,gdzie badamy interakcje między różnymi komponentami systemu

Szyte na miarę kontrakty serwisów domenowych, zdarzeń aplikacji, bram itd. (DDD/RDD)

Appl

icatio

nSe

rvice

s

Repo

sitor

ies

Event

Producers

Event

Listeners

GUI A

dapt

ers

Queue Adapters

Queue Adapters

Pers

isten

ce A

dapt

ers

A może jakiś klucz?

Alistair Cockburn, Hexagonal Architecture

Domain Model

„Czytelny” Kod– większość kluczowej logiki powinna być gdzie indziej

TDD – głównie „lekkie” testy integracyjne pokrywające interakcje między warstwami(np. Repository+Pesistence Adapters)

Maksymalne użycie frameworków i narzędzi wspomagających

ATDD/BDD – testy akceptacyjne działające przez punkty wejścia do systemu (np. Application Services, Event Listeners)

Oznaki zatracenia?

Alistair Cockburn, Hexagonal Architecture

Appl

icatio

nSe

rvice

s

Domain Model

Repo

sitor

ies

Event

Producers

Event

Listeners

GUI A

dapt

ers

Queue Adapters

Queue Adapters

Pers

isten

ce A

dapt

ers

Przeładowane Interfejsy.

Zazdrosne Metody.

Długie listy parametrów.

Duplikacja tych samych przypadków testowych w wielu klasach

Skupienie na danych zamiast na zachowaniach.

Zaburzenia hermetyzacji, set/get dla wszystkich.

Nieznajomość wzorców projektowych.

Brak jawnej deklaracji zachowań i oczekiwań.

Złamanie zasad SOLID.

Nadużywanie wzorca Test Double.

Niechęć do małych klas.

Appl

icatio

nSe

rvice

s

Repo

sitor

ies

Event

Producers

Event

Listeners

GUI A

dapt

ers

Queue Adapters

Queue Adapters

Pers

isten

ce A

dapt

ers

Oznaki zatracenia?

Alistair Cockburn, Hexagonal Architecture

Domain Model

Implementacja dodatkowych funkcjonalności, nie używanych przez logikę aplikacji.

Nic nie wnoszące, trudne w utrzymaniu testy jednostkowe.

Budowanie własnych narzędzi w sposób nazbyt ogólny.

Skomplikowany kod.

Budowanie własnych frameworków.

Czy zawsze warto?

Duża zmienność wymagań

Skomplikowana domena problemu

Brak odpowiednich umiejętności w zespole

Proces nieiteracyjny / jedno końcowe wydanie

Dziękuję za uwagę.

Co Dalej?• Andrew Hunt, David Thomas, „Pragmatyczny programista. Od czeladnika do mistrza”, Helion S.A. 2011

• Martin Fowler, Kent Beck, „Refaktoryzacja: Ulepszanie struktury istniejącego kodu”, Helion S.A. 2011

• Robert C. Martin, „Czysty Kod, Podręcznik Dobrego Programisty”, Helion S.A. 2010

• Gerard Meszaros, „xUnit Test Patterns: Refactoring Test Code”, Addison-Wesley 2007

• Martin Fowler, „Patterns of Enterprise Application Architecture”, Addison-Wesley 2002

• Eric Evans, „Domain Driven Design: Tackling Complexity in the Heart of Software”, Addison-Wesley 2003