Dwa sposoby na pisanie aplikacji bez błędów
Download as PPTX, PDF1 like1,787 views
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.
Dwa sposoby na pisanie aplikacji bez błędów
- 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
- 4. Agenda • Projektowanie • Testowanie • Implementacja
- 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.
- 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.
- 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
Editor's Notes
- #25: NASTĘPNY SLAJD: PODSUMOWANIE
- #26: PODSUMOWANIE
- #40: Trzeba pamiętać, że ważną cechą CA jest to, że nawiązuje do wcześniejszych opracowań Wujka Boba, z SOLID na czele
- #49: "Eagleson's Law: Any code of your own that you haven't looked at for six or more months might as well have been written by someone else." - Alan Eagleson
- #50: "Eagleson's Law: Any code of your own that you haven't looked at for six or more months might as well have been written by someone else." - Alan Eagleson