Szymon Homa - prezentacja z III edycji konferencji Quality Excites.

1. Wyboista droga do
Dobrego Kodu
Szymon Homa

2. Jaki jest Dobry Kod?
Pilnuje zasad SOLID?
Jest testowalny?
Dba o zasady Clean Code?
Jasno wyraża intencje?

3. 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.

4. A może jakiś klucz?
Alistair Cockburn, Hexagonal Architecture
Domain
Model

5. A może jakiś klucz?
Alistair Cockburn, Hexagonal Architecture
Domain
Model
Czysty Kod
TDD – testy jednostkowe pisane w większości przypadków bez
używania Test Double
Wyrażający intencje model
obiektowy (DDD/RDD)

6. A może jakiś klucz?
Alistair Cockburn, Hexagonal Architecture
Domain
Model
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)

7. 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)

8. Oznaki zatracenia?
Alistair Cockburn, Hexagonal Architecture
Domain
Model
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.

9. 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.

10. Czy zawsze warto?
Duża zmienność wymagań
Skomplikowana domena problemu
Brak odpowiednich umiejętności w zespole
Proces nieiteracyjny / jedno końcowe wydanie

11. 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