How to demo?

Use Case, Kryteria akceptacji, Przypadki testowe – jest wiele sposobów na to, żeby zdefiniować wymagania i zweryfikować poprawność ich implementacji.

Ich wyszukane nazwy mogą być jednak odstraszające, klienci mogą nie być zachwyceni, że muszą się czegoś nowego nauczyć. Dlatego podoba mi się określenie “How to demo?”.

Opisz co musiałbym zrobić z systemem, żeby udowodnić Ci, że Twoje wymaganie zostało zaimplementowane?

Na przykład historyjka

Logowanie do systemu:
wchodzę na stronę główną, wpisuję poprawne dane do logowania, po kliknięciu zaloguj widzę spersonalizowaną stronę startową (spersonalizowana, to taka, która mówi ‘witaj, Grzegorz’, o ile zalogował się Grzegorz)

Proste, prawda?

Oczywiście UMLowiec powie, że trzeba w tym Use Casie dodać alternatywne, błędne ‘przebiegi’. Ja jednak powiem, że załatwią to osobne historyjki:

Nieudane logowanie do systemu
wchodzę na stronę główną, wpisuję niepoprawne dane do logowania, system pokazuje formularz logowania z dodatkowymi informacjami:
- błędna para login/hasło
- zapomniałeś hasła? (to jest link)

i dalej,

Przypomnienie hasła
Po kliknięciu “zapomniałeś hasła” klient jest proszony o podanie adresu e-mail na który się zarejestrował, oraz kodu z obrazka. Gdy email jest w bazie, a kod prawidłowy klient dostaje e-mail z wygenerowanym, tymczasowym hasłem

następnie:

Logowanie przy pomocy tymczasowego hasła

Dalej sam już dasz sobie radę.

Myślę, że takie układanie historyjek jest szybkie, poza tym klient nie musi się tego uczyć – wystarczy, że przy odrobinie naszych wskazówek nauczy się oddzielać zadania od siebie, aby historyjki były krótkie (a przez to proste).
Oczywiście zdarzają się skomplikowane zadania biznesowe – jednak zaprawieni i wytrenowani w łatwiejszych przypadkach możecie z przyjemnością zagłębić się w ten nowy wymagający i fascynujący (mam nadzieję) temat.

Dlaczego warto się przesiąść na GITa (1 reason inside)

Wiele już na ten temat zostało powiedziane. Poza tym mówienie i pisanie nie przekonuje tak bardzo jak mogłoby się blogerom wydawać. Sam jestem tego przykładem, gdyż wysiłek poświęcony na wdrożenie i poznanie SVN’a w mojej poprzedniej firmie sprawiał, że nie chciało mi się podejmować kolejnego tylko po to, żeby mieć “fajniejszy” system kontroli wersji.

Jednak wraz ze zmianą pracy zmuszony byłem opuścić niektóre dobrze znane mi rejony. Musiałem poznać GIT’a. Wejście w ten temat miałem łatwe, gdyż infrastruktura już stała (podobna do SVNa z centralnym repo) i z aktywnym wsparciem moich nowych kolegów zacząłem powoli uczyć się nowego systemu.

Nie trwało długo zanim zacząłem swobodnie poruszać się po podstawowych tematach. Zacząłem intensywniej używać branch’y (za co w SVNie bałem się zabrać), jednak najbardziej zakochałem się w poleceniu git stash.

Jest to taki schowek, do którego można wrzucić aktualne zmiany. Może, zamiast zagłębiać się w teorię, opowiem o przypadkach w jakich się przydaje.

Załóżmy, że pracujesz na głównej gałęzi (jesteś zielony i nie przekonałeś się do używania branchy). Masz wprowadzone edycje do kilkunastu plików, aż tu nagle trzeba wprowadzić niecierpiącą zwłoki zmianę do repozytorium. Zmiana jest drobna, ale nie zrobisz ‘push’a z tymi wszystkimi zmianami. Wtedy robisz:

git stash
#znów masz czystą kopię roboczą
#wprowadzasz zmiany
git add .
git commit
git push
git stash pop
#przywracasz swoje zmiany

Pracujesz dalej, aż tu nagle przydałoby się zrobić commit. Jednak boisz się, że sytuacja się powtórzy i coś trzeba będzie wprowadzić do repo i z pushem pójdzie wszystko. Zatem przydałoby się przenieść zmiany do osobnej gałęzi:

git stash
git branch jakas_nazwa_galezi
git checkout jakas_nazwa_galezi
git stash pop
git commit -a

Oczywiście warto zacząć używać gałęzi, gdyż jest to bardzo silne i pomocne narzędzie. Git stash jest tylko małym pomocnikiem do pracy z branchami, ale jakże sympatycznym.

Jeśli do tej pory nie używałeś GITa – spróbuj już dziś, choćby dla zabawy.

Utrzymanie jakości kodu

Właśnie uświadomiłem sobie, że utrzymanie wysokiej jakości kodu to jest ciągła praca.

Wiem, że brzmi to może jak banał, ale to nie jest jakaś wytyczna ustalona raz na początku projektu. Zrozumienie tego zajęło mi 4 lata. Nie możesz się umówić, że od teraz, od tego projektu, od tej funkcji będziesz pisał kod wysokiej jakości.

Możesz umówić się, że będziesz pisał kod o jakości najlepszej na jaką Cię w tym momencie stać.

Continue reading