Druga część serii z wykładów przeprowadzanych przez BLStream dla studentów informatyki ZUT w ramach Business Hours.

1. Jak dobrze zacząć projekt
techniczna organizacja zespołu
Łukasz Roszak
Hubert Taler

2. AGENDA
 Zarządzanie kodem źródłowym
 Testowanie aplikacji na różnych poziomach
 Ciągła integracja
 Projektowanie struktury aplikacji

3. TEST JOEL’A

4. The Joel Test: 12 Steps to Better Code
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

5. KORZYSTAJCIE Z UMIAREM

6.  Każdy element dodany od procesu obciąża go
 Nie wszystko trzeba wdrożyć od początku
 Proponuj usprawnienia w czasie sprint retrospective
 Załóż wiki i trzymaj ją aktualną!

7. SYSTEM KONTROLI WERSJI

9. Nie tylko dla zespołów
 Historia zmian
 Praca nad wieloma zadaniami jednocześnie
 Odtwarzanie działającej wersji
 Wyszukiwanie przyczyn błędów

10. A co dla zespołów
 Codzienne wrzucanie kodu jako backup
 Łatwa synchronizacja z innymi developerami
 Łatwe łączenie zmian
 Współbieżna praca nad kodem

11. Podstawowe pojęcia
 Branch – nazwana „wersja” repozytorium, na której pracujemy i
wykonujemy zmiany nie ingerując w inne „wersje”.
 Commit – zbiór zmian w plikach
np „Added filter option in list header”.
 Merge – połączenie zmian wykonanych w innych branchach.
 Konflikt – sytuacja, kiedy w różnych branchach zmieniono te same
fragmenty plików.

12. Gdzie trzymać repozytorium?
 Aplikacja webowa zbudowana nad repozytoriami Git i Mercurial
 Dodatkowy, wygodny interfejs do przeglądania repozytorium
 Łatwo wprowadzić code review poprzez pull request

14. CODING GUIDELINES

18. Coding guidelines
 Kod wygląda, jakby pisała go jedna osoba
 Nawet bez dokumentu powinniśmy trzymać się konwencji dla
danego języka programowania
 Ustalamy zasady demokratycznie
 Dokumentujemy je i w razie potrzeby aktualizujemy

19. Co ustalamy
 Konwencje:
 Nazewnictwo zmiennych, metod, klas, przestrzeni nazw
 Formatowanie składni
 Umieszczenie plików w odpowiednich miejscach
 Obsługa wyjątków
 Komentarze:
 Samodokumentujący się kod
 Nie komentuj złego kodu, przepisz go!
 Wykorzystaj narzędzia (audyt i automatyczne formatowanie)

20. Przykłady?
https://docs.nuget.org/contribute/coding-guidelines

21. BRANCHING POLICY

22. Branching policy
 Definiujemy:
 główne branche ( master, stable itp. )
 nazewnictwo tworzonych branchy roboczych
 Wiemy, gdzie szukać działającego/produkcyjnego kodu
 Możemy współpracować nad różnymi zadaniami
 Zapewniamy stabilność głównego kodu

23. Źródło: http://nvie.com/posts/a-successful-git-branching-model/

24. Źródło: http://nvie.com/posts/a-successful-git-branching-model/

25. Źródło: http://nvie.com/posts/a-successful-git-branching-model/

26. TESTOWANIE APLIKACJI

27. Po co testujemy?
 Znajdujemy błędy
 Zwiększamy jakość produktu
 Poprawiamy proces
 Nie jest możliwe udowodnienie, że aplikacja nie ma błędów

28. TASK FLOW

29. Task flow
 Definiuje możliwe stany i przejścia pomiędzy nimi dla każdego
zadania
 Pokazuje bieżący stan prac nad zadaniem
 KISS - "Keep it simple, stupid„

31. TESTY MANUALNE

32.  Akceptacyjne, funkcjonalne, smoke, eksploracyjne itp.
 Plany, scenariusze, przypadki i dane testowe
 Wszystkie błędy zgłaszamy w spójny sposób
 Wersja aplikacji
 System, przeglądarka, środowisko na jakim rzeprowadzono test
 Kroki do odtworzenia
 Rezultat
 Oczekiwany rezultat

33.  Tester i programista to różne osoby
 Nieprzetestowane oznacza nie zrobione
 Szacując zadania uwzględniać należy testowanie

34. TESTY JEDNOSTKOWE

35. Test jednostkowy (ang. unit test)
Metoda testowania tworzonego oprogramowania poprzez
wykonywanie testów weryfikujących poprawność działania
pojedynczych elementów (jednostek) programu.

37. FIRST, czyli dobre testy jednostkowe
 Fast
 Independent
 Repeatable
 Self-validating
 Timely

38. Skrajności są złe

39. TEST DRIVEN DEVELOPMENT

40. TDD – pojedyncza iteracja
1. Myślimy o najmniejszej jednostce kodu jaki potrzebujemy
2. Piszemy test jednostkowy, który go używa
3. Uruchamiamy test ( TEST FAILED )
4. Piszemy kod
5. Uruchamiamy test ( TEST PASSED lub wracamy do 4)
6. Wracamy do 1

41. Wady i zalety
 Wymaga dyscypliny
 Daje niemal 100% pokrycie kodu testami
 Produkuje minimalny wymagany i często optymalny kod
 Dobre podejście, kiedy nie piszemy interfejsu użytkownika

42. AUTOMATYZACJA TESTÓW

43. Automatyzacja testów
 Nie eliminuje testów manualnych.
 Można automatyzować wszystko ( np. przygotowanie danych ).
 Automatyzacja ma swój koszt.
 Testy jednostkowe, to już przynajmniej częściowa automatyzacja.
 Automatyczne testy GUI z wykorzystaniem Selenium, Calabash itp.

45. TESTY USABILITY

46. Testy usability
 Sprawdzają, czy aplikacja jest przyjazna dla użytkowników.
 Optymalizujemy aplikację pod docelowe potrzeby użytkowników.
 Wykonuje się je na makietach aplikacji.
 Wykonują ją przeważnie graficy ( wolą być nazywani UX ).

47. DZIĘKUJĘ ZA UWAGĘ
Chętnie odopwiem na wszystkie pytania