wtorek, 14 stycznia 2014

Clean code - wprowadzenie część 2


Programowanie to gra zespołowa.
Każdy gra na swojej pozycji najlepiej jak potrafi i pomaga kolegą zespołu z całej swojej mocy, jeśli tego potrzebują. Asertywność jest jednak wskazana.

Uważnie dobieraj słowa, aby nie zostać źle odebranym.
Niektóre słowa mają wiele różnych kontekstów.
Np jeśli zbliża się koniec terminu i PM prosi Cię o przyspieszenie sprinta np o cztery dni.
Odpowiadając, że spróbujesz przyznajesz, że masz jaki nowy plan.Ale czy aby na pewno go masz ?
Jak będą się różniły Twoje działania do działań bieżących ?
Chyba, że duże rezerwy czasowe do pracy po pracy wtedy jeszcze taka odpowiedz ma jakikolwiek sens.
Inaczej jest to okłamywanie siebie i swojego przełożonego.

Mantra:
Pamiętaj : Dobry kod jest łatwy w konserwacji i w prosty sposób modyfikowalny od kątem nowych funkcjonalności.


Jeśli czegoś nie zdążysz zrobić, powiedz to szczerze wcześniej.
Im wcześniej to zrobisz tym więcej czasu dasz zespołowi na podjęcie określonych działań.
Czy chciałbyś żeby kolega z którym umówiłeś się na browara czekał bez końca jak Ty utknąłeś w korku.
Lepiej szczerze przedstawić mu sytuacje. Reaguj od razu niż później tłumacz się bezsensownie - ale przecież był korek a to nie jest zależne ode mnie.

Podobnie wygląda sprawa z naprawą bug'a. Jeśli nie możesz sobie z nim poradzić a spędziłeś już nad nim wystarczająco dużo czasu po prostu śmiało zakomunikuj ten problem.

Dyscyplina zobowiązań
Masz do wykonania konkretny task.
Możesz pokusić się aby pominąć potrzebną już refaktoryzację, pisanie testów itd.
I to jest właśnie to miejsce kiedy poznasz prawdziwego profesjonalistę.
Właśnie w tym miejscu popełniasz duży błąd. W tym momencie już nic nie pójdzie szybciej. Pominięcie refaktoryzacji czy testów nie przyspieszy realnie prac.
Tego uczą lata doświadczenia. Powstały zysk jest złudny.
Poza tym jako profesjonalista powinieneś zachowywać wysokie standardy i być marką dla siebie samego oraz innych.


Umiejętność wyszukiwania własnych błędów jest ważna


Praca z kodem.
 - kod musi działać. Dbaj o szczegóły.
 - rozwiązywać problemy biznesowe. Wychwyć te rozbieżności i skieruj kod na właściwy tor
  - kod musi dobrze dopasowywać się do systemu. Nie może zwiększać jego sztywności czy nieprzejrzystości. Kod musi być zgody z GRASP i SOLID.
 -  być czytelny dla innych. Kolega musi równie dobrze pracować z Twoim kodem jak i swoim.
 - jeśli jesteś zmęczony. Przestań kodować - odpocznij. Wstań jutro wcześniej i dokończ to np z rana. Najgorszy kod to kod który powstał o 3 nad ranem:)
- kod musi mieć dobrze zdefiniowaną strukturę. Późniejsze obejścia (workaround)  stosowane przez zespół będą dużo kosztowały i spowodują wiele nieprzewidzianych problemów.
 - kod wymaga koncentracji. Jeśli istnieje jakaś rzecz, która Cię zdekoncentruje np choroba dziecka, jest duże prawdopodobieństwo, że popełnisz błędy.


TDD rules!
 - pozwala skrócić czas pracy nad projektem chociaż może wydawać się to niedorzeczne.
 - masz pewność, że kod działa.
 - otrzymujesz regresje w pakiecie
 - masz wysokie pokrycie kodu
 - szybko wyłapujesz problemy i braki w implementacji oraz design'ie.

Prawa TDD:
- nie wolno napisać nawet linii kodu jeśli wcześniej nie napisze do tego testu, który nie zostanie zaliczony
 - nie wolno pisać więcej testów niż to naprawdę potrzebne, żeby test nie został zaliczony.
 - nie wolno napisać więcej produkcyjnego kodu niż trzeba aby test został zaliczony 

Tip: pisz w cyklach !

UAT = Testy akceptacyjne
Testy UAT mają za zadanie wprowadzić odpowiednią komunikację, precyzję oraz jasność do Twojego projektu.
Określają poprawne działanie systemu. Są tworzone w przez testerów, programistów a czasem nawet przez udziałowców danego systemu.
Bardzo ważną cechą jest tu automatyzacja.
Testy UAT nigdy nie powinny być wykonywane ręcznie - wysokie koszta!

Tip : Selenium,  Robot Framework
Tip : Acceptance Test-Driven Development (ATDD)
Tip : Cucumber, Fitnesse

Profesjonaliści powinni od początku wiedzieć, że takie rzeczy się automatyzuje.
Ponadto dobrą praktyką jest aby cześć scenariuszy testowy już podczas tworzenia implementacji przeprowadził sam programista. Odciąża on wtedy zespół QA.

Tip : Automatyzuj testy w formie czytelnej dla osób nie związanych z oprogramowaniem.

Nie przekonałem Cie jeszcze do testów akceptacyjnych ?
Masz tu przykład:
Kolega pracuje nad jakąś logiką biznesową w projekcie X.
Po jakimś czasie inny człowiek z firmy musi przejąć utrzymanie projektu X wraz z poprawieniem nowo wykrytych błędów.
Mając tylko skąpą dokumentację samo wdrożenie się w projekt, o ile to w ogóle możliwe potrwa tygodnie. W tym czasie ten człowiek rzyga już wszystkich. Logika jest pokręcona. Algorytm zupełnie niezrozumiały. Dokumentacja jak to często bywa nie była na bieżąco uaktualniana. Jednym słowem jedna wielka kupa gówna. 
Czy znasz ten stan ?:)

Jako receptę na taki przypadek proponuje właśnie testy akceptacyjne.
Nie ma znaczenia w jakiej technologii i jakim narzędziem zostaną stworzone.
Ważne jest to natomiast aby one istniały.

I tak wracają do naszego przykładu, zamiast zastanawiać się jak np działa logika  przetwarzania jakiś billingów puszczam sobie test Selenium.
Widzę cały przypadek uwieczniony przez samego autoram, lub osoby kompetentnej z QA.
Patrzę gdzie klikał i  jakich danych oczekiwał. Zamiast czytać nieaktualną dokumentacje, mam teraz przypadek wyjęty  prosto z życia aplikacji.
Ładnie zaprojektowany i odpowiednie przetestowany przypadek, który pozwala mi szybko zrozumieć istotę problemu oraz przyspieszyć implementacje i poprawę błędu.
Super !

Tip : Staraj się tworzyć testy UAT w każdej iteracji (sprint)
Tip : CI uruchamia testy UAT
Tip : Task uznaje się zakończony jeśli przejdzie wszystkie  testy w tym UAT i integracyjne
Tip : Staraj się testować wszystko. Proś o pomoc kogoś z QA jeśli masz jakiekolwiek wątpliwości.
Tip : Regresją testów UAT - sprawdź czy nie zepsułeś działającej już funkcjonalności (maszyna CI)
Tip : SRP, MVC dla GUI jako dobra praktyka


Testy jednostkowe - a testy akceptacyjne

Testy jednostkowe są pisane przez programistów dla programistów.
(O dobrych praktykach pisania testów dowiesz się w następnych postach)

Testy akceptacyjne są pisane przez nieprogramistów - dla nieprogramistów.
Są formalnymi dokumentami opisującymi jak powinien zachować się system w danej zasymulowanej  sytuacji.

Tip : Nie wiesz jak się za to zabrać mam na myśli testy UAT (cucumber, selenium + junit integration)) ?
Poproś kogoś bardziej doświadczonego lub sam o tym poczytaj.


Pracuj tak aby team QA był bez pracy.
Pamiętaj jednak, QA jest integralną częścią Twojej drużyny.
Podział testów znajdziesz w tym poście.

Spotkania na stojąco (stand up meeting)

Agenda:
- co będę dzisiaj robił
- co zrobiłem wczoraj
- co mi przeszkadza

Czas spotkania powinien być krótki max 15 minut. Każdy z uczestników odpowiada na pytanie z agendy.

Spotkania planujące iteracje
Omawiamy:

 - wybrane pozycje backlogu, realizowane w następnej iteracji
 - szacujemy pracochłonności tych pozycji
 - ocena oraz wartość biznesowa danej pozycji
 - szkic testów akceptacyjnych
 - każdy kandydat z backlogu może być odrzucony lub zaakceptowany
 - nad każdą pozycją dyskutujemy góra kilka minut w przypadku skomplikowanych problemów należy zebrać tylko ludzi 'zainteresowanych' i stworzyć odrębne spotkanie
 
Retrospekcja iteracji i demonstracja produktu
Następuje po końcu każdej iteracji.
Członkowie zespołu wymieniają się poglądami co poszło dobrze a co źle.
Jaki element sprintu możemy przyspieszyć, co ulepszyć  i w jaki sposób to osiągnąć.

Ślepa droga.
Pewnie każdy z nas nie raz spotkał się z takim stanem w swoim dewelopmencie.
Tutaj ważna jest umiejętność rozpoznawania tego typu sytuacji  oraz odwaga aby się z takiej drogi wycofać.
Otwarty umysł to klucz.
W razie ciężkich problemów poproś o radę kogoś bardziej doświadczonego z zespołu.

Tip : Lokalna burza mózgów


cdn.





















Brak komentarzy:

Prześlij komentarz