techniczna organizacja zespołu
TRANSCRIPT
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