techniczna organizacja zespołu

Jak dobrze zacząć projekt techniczna organizacja zespołu

Łukasz Roszak

Hubert Ta ler

AGENDA

Zarządzanie kodem źródłowym

Testowanie aplikacji na różnych poziomach

Ciągła integracja

Projektowanie struktury aplikacji

TEST JOEL’A

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?

KORZYSTAJCIE Z UMIAREM

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ą!

SYSTEM KONTROLI WERSJI

Nie tylko dla zespołów

Historia zmian

Praca nad wieloma zadaniami jednocześnie

Odtwarzanie działającej wersji

Wyszukiwanie przyczyn błędów

A co dla zespołów

Codzienne wrzucanie kodu jako backup

Łatwa synchronizacja z innymi developerami

Łatwe łączenie zmian

Współbieżna praca nad kodem

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.

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

CODING GUIDELINES

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

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)

Przykłady?

https://docs.nuget.org/contribute/coding-guidelines

BRANCHING POLICY

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

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

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

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

TESTOWANIE APLIKACJI

Po co testujemy?

Znajdujemy błędy

Zwiększamy jakość produktu

Poprawiamy proces

Nie jest możliwe udowodnienie, że aplikacja nie ma błędów

TASK FLOW

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„

TESTY MANUALNE

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

Tester i programista to różne osoby

Nieprzetestowane oznacza nie zrobione

Szacując zadania uwzględniać należy testowanie

TESTY JEDNOSTKOWE

Test jednostkowy (ang. unit test)

Metoda testowania tworzonego oprogramowania poprzez

wykonywanie testów weryfikujących poprawność działania

pojedynczych elementów (jednostek) programu.

FIRST, czyli dobre testy jednostkowe

Fast

Independent

Repeatable

Self-validating

Timely

Skrajności są złe

TEST DRIVEN DEVELOPMENT

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

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

AUTOMATYZACJA TESTÓW

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.

TESTY USABILITY

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

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