Poznań, , Artur Otrzonsek

Poznań, 28.10.2014, Artur Otrzonsek
Insert Client/Partner logo Clean Code, TDD, Mockito Poznań, , Artur Otrzonsek

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito
1 Please discover "Update Agenda" in your Capgemini Tools to get all the agenda slides and to refresh them; there is also a layout without picture in the background available Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Jak zmierzyć jakość kodu
Source: „Clean Code”, Robert C. Martin Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Dlaczego czytelność kodu jest ważna?
Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Wpływ bałaganu w kodzie na wydajność zespołu
Źródło: „Clean Code”, Robert C. Martin Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Ciągła poprawa kodu jest możliwa!
„Wprowadzaj do repozytorium kod lepszy niż ten, który z niego pobrałeś” Źródło: Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Nazywamy wszystko – róbmy to dobrze
Zmienne Metody Używaj znaczących nazw Katalogi Argumenty Pliki Klasy Pakiety Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

int g; // suma godzin pracy
Zmienne int g; // suma godzin pracy int sumaGodzinPracy; Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Metody Metody powinny być krótkie (~20 linii kodu)
Tylko jeden poziom abstrakcji w metodzie Dekompozycja złożonej metody na mniejsze Pomaga dokumentować kod Czytelne sygnatury metod Max 3-4 parametry Szczególnie uciążliwe są parametry o tych samych typach Argumenty przełączające Parametry boolean, enum często wskazują na to, aby dodać nową metodę Unikać powtarzającego się kodu DRY (Don’t Repeat Yourself) Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Metody - długa lista parametrów
public List<User>findUsers(Long countryId, Long stateId, boolean isActive, boolean isAdmin, boolean isChief, boolean isCustomer, boolean isForeigner, String countryCode, String stateCode, String streetName, int minAge, int maxAge, …) {...} public List<User>findUsers(UserSearchParameter searchParameter) {...} Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Metody - długa lista parametrów - wywołanie
public List<User> users = findUsers(1L, null, true, false, false, false, false, "PL", null, null, 20, 50, …) {...}; Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Metody - długa lista parametrów
class UserSearchParameter { private Long countryId; private boolean active; // getters and setters } class UserSearchParameterBuilder { private UserSearchParameter searchParameter = new UserSearchParameter(); public UserSearchParameterBuilder onlyActive() { searchParameter.setActive(true); return this; } public UserSearchParameter build() { return searchParameter; Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Testy jednostkowe Dokumentują kod i ułatwiają zrozumienie jego działania Ułatwiają refaktoryzację kodu Kod testów nie jest kodem drugiej kategorii! Powinny być czytelne Będą zmieniane w trakcie zmian kodu produkcyjnego Tylko jedna koncepcja jest testowana w jednym teście Czyste testy powinny być zgodne z zasadą „F.I.R.S.T.”: Fast (szybkie) Independent (niezależne - nie powinny zależeć od siebie) Repeatable (powtarzalne w każdym środowisku) Self-Validating (samodzielnie sprawdzające wynik) Timely (napisane „o czasie”, przed kodem produkcyjnym) Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Tylko jedna koncepcja jest testowana w jednym teście
public void testShouldReturnEmptyListWhenUserHasNoRoles() { // given userController.addUser(createUser(USER_MAIL)); User user = userController.findUser(USER_MAIL); // when List<Role> roles = userController.findRoles(user.getId()); // then assertTrue(roles.isEmpty()); } Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Komentarze Kod powinien sam się opisywać
Znaczące nazwy, krótkie metody, itd.. Komentowanie kodu staje się przestarzałe Po zmianie kodu najczęściej komentarz pozostaje niezmieniony Są przydatne gdy wyjaśniają coś czego nie da się czytelnie opisać w kodzie Przykłady złego komentowania: Przeczytanie komentarza zajmuje więcej czasu niż analiza kodu Komentarz jest nieaktualny Zawiera powtórzone informacje które można wyczytać z kodu Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

TDD – trzy podstawowe prawa
Zabronione jest pisanie kodu produkcyjnego do czasu zaimplementowania testu. Test rozwijamy do momentu aż wykryje pierwszy błąd w kodzie produkcyjnym. Poprawiamy kod produkcyjny do momentu naprawy niedziałającego testu. Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

TDD – zalety Pewność Odwaga Dokumentacja Zarys, projekt
Dziesiątki testów napisanych codziennie, setki w tygodniu, a tysiące w roku Wszystkie te testy zostaną odpalone w trakcie refaktoryzacji kodu Odwaga Reakcja na zmianę w „czyimś” kodzie Dokumentacja Każdy napisany test opisuje działanie jakiejś funkcjonalności Zarys, projekt Testy wymagają izolacji, a to wymusza implementację zgodną z Clean Code Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Mockito Twórcą projektu jest Szczepan Faber
Powstał w odpowiedzi na uciążliwe korzystanie z mocków podczas budowy testów Reprezentuje odmienne podejście typu spy test bardziej naturalne, prowadzi do przejrzystego kodu Proste i przejrzyste API Czytelne komunikaty o błędach Bardzo dobra dokumentacja Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

Mockito, przechwytywanie argumentów

Poznań, , Artur Otrzonsek

Podobne prezentacje

Prezentacja na temat: "Poznań, , Artur Otrzonsek"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

Poznań, , Artur Otrzonsek

Podobne prezentacje

Prezentacja na temat: "Poznań, , Artur Otrzonsek"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres