Jakość oprogramowania jest rozbudowaną dziedziną wiedzy, którą każdy programista zna doskonale, ale ilu tak naprawdę stosuje skutecznie? W prelekcji przedstawię zarówno najważniejsze, zweryfikowane praktycznie sposoby podnoszenia i utrzymywania jakości oprogramowania na założonym poziomie, jak również omówię kilka pułapek, w które nadzwyczaj łatwo wpadamy.

1. Dwa sposoby na pisanie
aplikacji bez błędów
Michał Łukaszewski
Software Engineer, Tech Lead

2. SUCHAR TIME!
There are two ways to write error-free programs; only the third works.
- Alan J. Perlis

3. Rodzaje błędów
Błędy
implementacji
Błędy
projektowe
Błędy wymagań

4. Agenda
• Projektowanie
• Testowanie
• Implementacja

5. Projektowanie

6. Zrozumienie wymagań
• „Dlaczego?” zamiast „co?”
• Zrozumienie intencji ważniejsze od listy funkcji
• Odtworzenie aktualnego procesu klienta
• Optymalizacja wymaga wiedzy eksperckiej.

7. Zrozumienie wymagań
• „Dlaczego?” zamiast „co?”
• Zrozumienie intencji ważniejsze od listy funkcji
• Odtworzenie aktualnego procesu klienta
• Optymalizacja wymaga wiedzy eksperckiej.
• Klient nie zna się na Twojej robocie
• nie wie czego od Ciebie wymagać.
• Ale zna się na swoim biznesie.
• W przeciwieństwie do Ciebie.

8. Zrozumienie wymagań
Błędy wymagań

9. Zrozumienie wymagań

10. Zrozumienie wymagań
• Impact mapping
• DDD
• Event storming
• SIWZ

11. Zrozumienie wymagań
„Oprogramowanie szyte na miarę”
Michał Bartyzel

12. Modelowanie
„A model is a simplification which fosters understanding.”

13. Modelowanie
• Modelowanie procesu biznesowego klienta
• Jego rzeczywistości biznesowej.
• Wszystkie modele są uproszczone
• Więc wszystkie modele są błędne
• Ale niektóre są użyteczne
• „Mental model” jako MVP

14. Architektura jako most między modelem, a
kodem
Business
requirements
Architecture Implementation

15. Architektura jako most między modelem, a
kodem
• Model opisuje w przybliżeniu rzeczywistość klienta.
• Architektura opisuje techniczne ramy, na których oprze się model.
• Programista implementuje zachowania w ramach przyjętej
architektury.

16. Architektura jako most między modelem, a
kodem
• Architektura musi być mądra, nie musi mieć mądrej nazwy.
• Ale architektura heksagonalna i czysta architektura naprawdę są super!
• Architektura musi być optymalna biznesowo.

17. Planowanie
Pośpiech jest skuteczniejszym generatorem błędów niż junior na kacu.

18. Szacowanie

19. Szacowanie
• Metody szacowania
• Kosztorysowa (cocomo/cocomo2)
• Bottom-up/Top-down
• Opinia ekspercka
• Szacowanie przez analogię
• Windeband Delphi

20. Szacowanie
• Pewne
• Prawdopodobne
• Wróżenie z fusów

21. Szacowanie
• Szacowanie pewne
• <= 1MD
• Szacowanie prawdopodobne
• 2-3MD
• Wszystko powyżej to wróżbiarstwo
Reguły te nie zmieniają się wraz z doświadczeniem zespołu.

22. Szacowanie
• Sceptycyzm
• Błędy szacowania
• Reguła 8 godzin

23. Szacowanie
• Nie uwzględnia
• Urlopów
• Spotkań
• Realnego czasu pracy

24. Planowanie
• Szacowanie
• Bufory (spotkania, urlopy, zmiany, błędy szacowania)
• Zarządzanie ryzykiem
• Reguła 9 matek
• Kontrola postępów
• Replanning (adaptacja)

25. Projektowanie
• Zbieranie i zrozumienie wymagań
• Modelowanie
• Architektura jako most między modelem, a kodem
• Szacowanie i planowanie.

26. Testowanie i implementacja
Błędy
implementacji
Błędy
projektowe
Błędy wymagań

27. Testowanie
Credits: https://www.sealights.io/blog/making-code-coverage-relevant-for-qa-teams/

28. TDD a rzeczywistość
• „Wszyscy” piszą testy.
• Część pisze testy z sensem.
• A część nawet przed implementacją.
• „To tylko prosta klasa, co tu testować?”.

29. TDD a rzeczywistość
• Testy są często większe niż implementacja.
• Są kosztowne w utrzymaniu.
• Wrażliwe na zmiany implementacji.
• Ciężko uzasadnić ten wydatek w budżecie projektu.

30. TDD a rzeczywistość
Code coverage jako największy bait w historii programowania.

31. Specification as example
• Test jednostkowy nie jest testem.
• Jest specyfikacją.
• Czyli dokumentacją.
• Opisuje oczekiwane zachowania.
• API
• Sprawdza obsługę błędów.

33. Specification as example
• Test nie jest testem.
• Jest specyfikacją.
• Czyli dokumentacją.
• Opisuje oczekiwane zachowania.
• Sprawdza obsługę błędów.

34. Testy jako miara jakości kodu.
• Kod, który się nie zmienia nie wymaga zmiany testów
• Prosty kod wymaga prostych testów
• Proste testy prostego kodu są szybkie
• Problem z odcięciem zależności jako flaga spartolonego projektu
• Prawo Demeter i Dependency Injection, ftw!
• Specyfikacja zawsze pokrywa kod w 100%

35. Testy wspierają utrzymanie jakości kodu.
• Nie tylko testy jednostkowe:
• Lintery
• Analiza statyczna
• Regularne profilowanie
• Automatyzacja
• per Pull Request
• Testy funkcjonalne
• Testy integracyjne
• Blokowanie zmian wprowadzających regresję jakości.
• Code Review jako bezwymiarowa ocena jakości kodu.

36. Testowanie
• TDD -> BDD -> ...
• Specification as example
• Testy jako miara jakości kodu

37. Implementacja

38. SOLID jako droga wojownika

39. S
O
L
I
D
ingle Responsibility Principle
pen Close Principle
iskov substitution principle
ependency inversion principle
nterface segregation principle

40. SOLID jako droga wojownika
• SOLIDny kod to kod czysty, prosty i stabilny.
• SOLIDny kod łatwo uczynić kodem bezpiecznym.
• SOLIDny kod świetnie się rozwija minimalizując ryzyko regresji.
• SOLIDny kod banalnie się testuje.
• SOLIDny powinien być kod, ale i architektura.

41. SOLID jako droga wojownika
SOLID to sposób myślenia o projektowaniu i implementacji.

42. Programowanie defensywne
• Agresywna technika programowania
• Optymalna dla projektów o długim czasie życia
• Bronisz kodu przed błędami

43. Programowanie defensywne
• YAGNI!
• Konstruktor jako jedyny punkt wstrzyknięcia zależności
• Tylko niezbędne zależności
• Minimalna ilość metod publicznych
• A każda z nich – finalna.

44. Dla kogo powstaje kod (i dokumentacja)?
• Kodujesz dla przeciwnika

45. Dla kogo powstaje kod (i dokumentacja)?
• Kodujesz dla przeciwnika

46. Dla kogo powstaje kod (i dokumentacja)?
• Kodujesz dla innych programistów.

47. Dla kogo powstaje kod (i dokumentacja)?
• Kodujesz dla innych programistów.
“Any fool can write code that a computer can understand. Good
programmers write code that humans can understand.”
– Martin Fowler

48. Dla kogo powstaje kod (i dokumentacja)?
Wszystkie techniki czystego kodu obniżają koszt utrzymania, nie
wytworzenia.
• Wszystkie „skróty i hacki” obniżają koszt wytworzenia, ale mogą doprowadzić
do śmierci projektu/kodu na dłuższą metę.

49. Dla kogo powstaje kod (i dokumentacja)?
Kod wyspecyfikowany (np. testami) jest przenaszalny pomiędzy
programistami.
• Chroń swoje stanowisko robiąc dobrą robotę
• Nie kod, który tylko ty rozumiesz

50. Good enough
• Proces wytwarzania oprogramowania to (technicznie) nieograniczona
ilość iteracji cyklu Deminga.
• Lepsze jest gorsze.
• Refactoring jako stały proces towarzyszący
• Nie akcja naprawcza!

51. Good enough

52. Implementacja
• SOLID jako droga wojownika
• Programowanie defensywne
• Dla kogo powstaje kod (i dokumentacja)?
• „Good enough”

53. Mniej błędów gdy
• Sumiennie zebrane wymagania.
• Rozumiesz wymagania.
• Masz dobry model (wystarczające przybliżenie).
• Architektura jest optymalna biznesowo.
• Szacowanie, planowanie, kontrola postępów.
• Specyfikacja „zamiast” testowania.
• Stała kontrola jakości kodu (CI + analiza statyczna + automatyzacja).
• Dobry projekt kodu (SOLID, programowanie defensywne).
• Czytelny kod („twój kod opowiada historię”).
• „Good enough”.

54. Lectures
• https://www.fs.blog/2017/06/all-models-are-wrong/
• http://ocramius.github.io/blog/when-to-declare-classes-final/
• https://ocramius.github.io/extremely-defensive-php/
• https://martinfowler.com/articles/feature-toggles.html