WRUG wrześniowy o nietestowaniu, pair-programmingu i spore.sh

Pair programming [PL] Marek Kirejczyk

First problem

Zespoły Agilowe powinny się same organizować.

I don't learn that much anymore

Gdy się nie rozwijamy to popadamy w depresje.

Good code review is hard Marek Kirejczyk

Co to jest pair programming?

• 2 osoby siedzą przy jednym komputerze
• pierwsza osoba - reaktor - fizycznie pisze
• druga osoba - nawigator - przygląda się co napisała ta pierwsza
• zadania w parach się zmieniają co kilkanaście minut

Myths - Kilka mitów o Pair programming

1. Zdublowane koszty

2 osoby kodujące razem wnoszą więcej do projektu, niż osobno.

2. Ma sens, ale gdy jest odpowiedni partner

Różne kombinacje przynoszą efekty.
Nie ma idealnej mieszanki!

3. Ludzie nie lubią pair programming

Błąd! Badania potwierdziły, że jest inaczej!
Developerzy lubią pair programming!

4. Pair programming jest tylko do nauki

Różne rodzaje parowania są efektywne.
Nie zawsze, nie wszystkie, ale większość przynosi dobry efekt.

5. Jeżeli będę pracował w parach to nikt mnie nie doceni

Rozwiązanie na docenianie jednostki?
Przypisanie ownerów do konkretnych modułów.

6. Nawigator, który tylko odnajduje syntax error

Dobre parowanie, ma wpływ na design kodowania. Marek Kirejczyk

Zachowania

1. Presja społeczna

Pary więcej spędzają kodując, niż na portalach społecznościowych.
Robią dużo mniej przerw.

2. Negocjacja

Negocjacja pomiędzy dwoma pomysłami, podejściami.
Jest to dużo lepsze, niż wzięcie pierwszego lepszego.

3. Pair review

Ciągle ktoś robi review kodu.

4. Pair learning

W parach uczymy się dramatycznie szybciej niż w pojedynkę.

5. Pair trust (zaufanie)

Para która pracuje razem, ma inny poziom zaufania, zna swoje zalety i wady.
Relacje są lepsze.

6. Pair courage

Para jest bardziej odważna.
Przekłada się to na modyfikację legacy code.

7. Pair debugging

Często jak się debuguje w parach, to czas spędzony na rozwiązaniu bugów,
jest to minimum z czasów spędzonych osobno.

Details

Rotacje!

Nowa para = nowe pomysły.
Aby pobudzić zaznacza się na macierzy

Ping pong pair programming

Najlepiej TDD: jedna osoba pisze niedziałający test, a druga minimalna ilość kodu aby kod przeszedł.

Gdy jest okey, to odwrócenie zadań.

Environment

Więcej miejsca przy biurku!

Types of pairs

• junior & senior
• extrovert & introvert
• Back-end & Front-end - ludzie z chęcią chcą się nauczyć drugiej strony - taka para bardzo szybko realizuje zadania

Przy junior & junior - code review zawsze musi być robione przez seniora.
Większość badań skupia się na 1 sprincie.

Zespół bardzo przyspiesza ale to musi trochę potrwać.

Introducing pair programming at DaftCode

"Fajne, chcemy więcej" - taki był odbiór po realizacji programu pilotażowego.

Cały zespół Daftcode programuje w parach!

Wnioski

Parować się dużo i im szybciej tym lepiej!

Czas trwania prelekcji: 18:33 - 18:55 (10 min pytań)

Pisz kod tak, aby go nie testować [PL] Łukasz "detomastah" Pełszyński

Co to znaczy "pokrycie kodu testami"?

• Wszystkie linie zostały przetestowane, ale nie oznacza, że program działa dobrze.

Stan programu

Stan wszystkich zmiennych, które program ma w pamięci

Wg. Millera ludzie mogę operować na max "9 obiektach" w swojej pamięci.
Średnio 7 obiektów.

Pamięć jako kolekcja FIFO

Co nam pomaga w dużej ilości stanów?

• tworzenie abstrakcji - pomagają one ogarnąć ten chaos

Interakcja szeregowa

Interakcja sprzężona

Bardzo często występuje w programach.
Może wskazywać na naruszenie SRP (single responsibility principle) pojedyncza odpowiedzialność.
Problem z SRP: zasada DRY prowadzi do tworzenie super-obiektów, które możemy wkładać w różne miejsca.

Rozwiązanie problemu z SRP: celowa duplikacja kodu.
Umożliwia wyrwanie się ze spaghetti code.

Interakcja warunkowa

Każdy warunek tworzy nowe stany. Może wskazywać na brak interfejsów.

Interakcja asynchroniczna

• czyli programy działające na wątkach!

Jak zaprogramować algorytm DFS?
Kto z tym zadaniem poradził sobie bez problemów?

Ogólne zalecenia

• Zacząć samodzielnie myśleć
• TRUST NO 1
• Myśleć ekonomicznie
• Dążyć do izolacji - łatwość podczas testowania
• Stosować przetwarzanie wsadowe 😄 - jedno przekazuje drugiemu, programy liniowe
• Nie pozwalać błędom się ukrywać - z góry rzucać wyjątkami
• W ostateczności - zmienić język

Czas trwania prelekcji: 19:07 - 19:32 (12 min pytań)

Pytania

Mutation test coverage - rozwiązuje problem 100 procentowego pokrycia kodu.
Więcej https://pl.wikipedia.org/wiki/Testowanie_mutacyjne

Rozwiązania z komentarzy: Można wymusić implementowanie interfejsu - wystarczy NoMethodError w jakiejś klasie.

Rozwiązania z komentarzy: Można pisać SRP i DRY.

Zarządzanie zmiennymi środowiskowymi przy użyciu spore.sh [PL] Marcin Wyszyński

Na HackerNews "pewien ktoś" opisał coś i się bulwersował, że go nikt nie rozumie. Marcin go zrozumiał i chce zaprezentować narzędzie opisane przez "tego kogoś".

Musimy korzystać z Heroku? Dlaczego, bo tak chce tego Heroku 😄

Różnica między develop a produkcją jest tylko w 1 zmiennej środowiskowej.
I to jest piękne!

spore.sh

• serwer w Node.js
• jest CLI
• w root naszego projektu jest plik konfiguracyjny

Zasada UID

Komunikacja przez SSL i pobieranie konkretnej wartości po uid

Czy powinienem tego używać?

"Wasza decyzja.
Może warto spróbować"

Czas trwania prelekcji: 19:47 - 20:02 (7 min pytań)

Podsumowanie

Świetnie było się spotkać po wakacjach z ekipą z WRUGa.
Inny język = inne doświadczenia.

Dzięki sponsorom (Rebased i EL Passion) mogliśmy wymienić sobie żeton za produkt o równowartości 10zł.

Kolejne spotkanie już za miesiąc!