Repozytorium kodu a w nim jeden z najważniejszych artefaktów

hitoria kodu zapisana w repozytorum

Repozytorium kodu to jedno z podstawowych narzędzi programisty, bez którego żaden profesjonalista nie może się obejść. W nim jeden z najważniejszych produktów jaki tworzymy obok głównego aplikacji.

Historia produktu zapisana w repozytorium kodu

Tworząc aplikację z każdym commitem tworzy się historia. Tworzy się ciąg kroków, jakie doprowadziły aplikację do stanu dzisiejszego. To co możemy w tej historii wyczytać jest czasem bardzo cenne. Kiedy? Po pierwsze wtedy, gdy chcemy przypomnieć sobie co zrobiliśmy od wydania ostatniej wersji. Po drugie gdy chcemy poprawić jakiś błąd.

Release Notes z historii commitów

Pracując w zespole większym niż jednoosobowym i wydając kolejne wersje (bez względu czy to jest aplikacja pudełkowa, webowa czy usługa) często potrzebujemy śledzić co w kolejnych wersjach zostało wydane. Historia kolejnych commitów staje się w takiej sytuacji bardzo pomocna – oczywiście przy założeniu, że dajemy przyzwoite nazwy do commitów – i zakładam, że na dzień dzisiejszy mało osób jest tak nierozsądnych aby robić commity bez odpowiednich komunikatów. Można pójść nawet dalej. Jeśli mamy jakiś sensowny automatyczny build to możemy z automatu tagować kolejne wydania wersji i wysyłać listę commitów do osób odpowiedzialnych za to co się dzieje z takim artefaktem jak wydanie wersji później.

Historia jako narzędzie do debugowania

Drugie zastosowanie historii commitów jest dużo ciekawsze z punktu widzenia developera. Ile razy zachodziłeś w głowę dlaczego ktoś napisał kawałek kodu tak a nie inaczej? Dlaczego ktoś zrobił taki błąd? Czasem kawałek kodu potrafi być tak zagmatwany, że nie da się go zrozumieć, czasem tak głupio napisany, że aż niemożliwe, żeby autor napisał takie cudo na trzeźwo. Wtedy przychodzi na ratunek historia i opcja blame lub annotate (w zależności jakich narzędzi używasz). Ta opcja pozwala sprawdzić, kto ostatni dotykał każdej kolejnej linki w kodzie.

Blame i annotate

Dzięki temu bardzo szybko namierzymy osobę, która zostawiła kod w takim stanie. Warto zastanowić się, dlaczego kod został napisany tak a nie inaczej. Czasem wystarczy przeczytać commit message a czase trzeba zapytać osobę, która ostatnia go edytowała. Czasem dowiemy się, że kod powstał w jakiejś pomroczności i to jest po prostu zepsute ale czasem odkryjemy, że były jakieś ważne powód. Czasem to jakieś dziwne wymaganie klienta a czasem dziwne zachowanie frameworka czy biblioteki. Pewnie ktoś stwierdzi, że można wtedy zostawić komentarz – ale komentarze mają tą brzydką cechę, że gniją  a bądźmy szczerzy, kto refaktoryzuje komentarze – to się nie sprawdza.

Do czego jeszcze może się przydać historia?

A choćby do tego, aby raz na jakiś czas pooglądać kod z lotu ptaka i zobaczyć ile pracy i energii włożyliśmy w stworzenie aplikacji puszczając na całym repozytorium narzędzie gource które pięknie wizualizuje kolejne commity w czasie – warto wybrać się w taką wycieczkę.

A Tobie do czego jeszcze przydaje się historia commitów w Twoim repozytorium?

Repozytorium kodu i puste commity

formatowanie kodu

Repozytorium kodu – jedno z najważniejszych narzędzi w arsenale programisty, developera. No właśnie… w ostatnim wpisie pisałem o automatycznym formatowaniu kodu i jak to zautomatyzować. Większość czasu czytamy kod niż piszemy więc to co piszemy musi być czytelny, dlatego kod musi być czytelny, dlatego dobrze go formatować.

Repozytrium kodu i automatyczne formatowanie kodu to same problemy

Jest jedno ale do tego całego formatowanie, mianowicie standardy. Wyobraź sobie, że lubisz wcięcie na 4 spacje (serio nie interesuje mnie czy wolisz spacje od tabulatorów, to bez znaczenia – wiadomo że taby rulez 😉 ) a współprograista tabulatory. Pobierasz kod z repo i przeformatowywujesz go na jedyny słuszny styl. Zresztą to  nie musi być odwieczna wojna spacje vs tabulatory, wystarczy prozaiczne z pozoru umiejscowienie wąsów w tej samej linni vs w nowej linii. Tak czy inaczej formatujesz na jedyny słuszny styl, robisz swoje i commitujesz. Współprogramista robi dokładnie to samo, pobiera, formatuje na jedyny słuszny styl, robi swoje i commituje. Jak w kołysce newtona (na obrazku powyżej) będziecie się obijać. Ale to nie najgorsze, najgorsze nadejdzie jak trzeba będzie zaglądnąć w historię commitów. Wtedy okaże się, że każdy jeden commit zawiera bardzo dużo zmian a jak zaczniesz przeglądać te zmiany okaże się, że 99% to przeformatowanie kodu.

Historia rzecz święta

Co powie Ci historia zmian w repozytorium jeśli 99% to będzie ping pong pomiędzy dwoma obozami jedynego słusznego formatowania? Taka historia na wiele się nie zda. Będzie po prostu bezużyteczna. Tutaj dochodzimy do sedna automatycznego formatowania kodu. Repozytorium kodu musi być czyste i czytelne tak samo jak kod, dlatego też wszyscy w zespole muszą mieć takie same standardy kodowania. To pozwoli zachować porządek w repozytorium kodu to po pierwsze, pozwoli uniknąć frustracji, że znowu ktoś użył złego standardu, pozwoli wreszcie skupić się na pracy.

Ludzi i interakcje od procesów i narzędzi

Pierwszy punkt agile manifesto… ludzie i interakcje… może warto przedyskutować w zespole wspólne standardy kodowania i ustawić wszystkie narzędzia tak samo. Wtedy będziemy mieli z automatu kod dobrze ustawiony a w historii w repo będzie porządek. Tylko tyle i aż tyle. Proste no nie?

Formatowanie kodu szybko i bezboleśnie

formatowanie kodu

Formatowanie kodu to jedna z podstawowych czynności jaką możemy zrobić w ramach refaktoryzacji. Jest proste i bezbolesne (pod warunkiem, że w Twoim języku programowania nie programuje się białymi znakami*). Daje szybki efekt w postaci czytelniejszego kodu a to jest bardzo ważne, zresztą pisałem już o tym tutaj.

Formatowanie kodu z automatu

Visual Studio posiada bardzo bogaty system dodatków a jednym z podstawowych to Productivity Power Tools a w nim dwa ustawienia, które nas interesują formatowanie kodu i usuwanie niepotrzebnych usingów. Instalacja jest banalnie prosta. W Tools -> Extensions and Updates szukamy power toolsów i instalujemy.

instalacja power tools

A potem ustawiamy dwie opcje, Tools -> Options -> Productivity Power Tools -> Power Commands

To wystarczy aby automatycznie formatować kod przy zapisywaniu pliku. Proste? Banalnie proste. Od teraz przed zapisem pliku Visual Studio automatycznie będzie formatować nasz kod i juz będziemy kroczek bliżej do trochę bardziej czytelnego kodu.

Jak formatować istniejący już kod

 

Co jeśli mamy już dużo kodu? Co jeśli chcemy sformatować wszystkie pliki w istniejącym – całkiem sporym projekcie? Nie trzeba otwierać każdego pliku w projekcie, wystarczy odpalić ReSharper-a czyli prawdopodobnie najlepsze narzędzie do refaktoryzacji. Później wystarczy mając wybrane na drzewku solution z menu wybrać ReSharper -> Edit -> Code Cleanup i patrzeć jak się samo robi 🙂 Preste? Banalnie proste. Tak posprzątany kod to dobry początek. Jeśli w zespole macie jakieś standardy kodowania, jeśli wąsy wrzucacie na koniec linii albo do nowej linii to te wszystkie rzeczy ustawisz w Resharper -> Settings -> ……. -> Code Style i oczywiście można ustawić różne ustawienia dla różnych języków.

resharper settings

 

*) programowanie białymi znakami to według mnie jeden z gorszych pomysłów bo konia z rzędem temu kto znajdzie błąd w programie jak mu kod wydrukujemy. Konia z rzędem temu kto szybko w najprostszym edytorze znajdzie spacje zamienione na tabulatory albo tabulatory na spacje. Czego nie widać nie powinno być elementem języka programowania i basta. Mamy dosyć problemów z domeną aby jeszcze dorzucać do pieca. Nie zmienia to faktu, że dobrze się tak programuje – nie trzeba tych cholernych nawiasów sadzać tyle, ale co z tego jak się gorzej utrzymuje.

Umarł GitLab niech żyje git czyli co zrobić zepsuje się git

git sie zepsul co robic

Git to repozytorium kodu a repozytorium kodu to jedno z podstawowych narzędzi pracy programisty. Dzisiaj pół internetu pisze, że GitLab – serwis do hostowania repozytoriów git – zaliczył poważną wpadkę. Trudno, zdarza się ale jakie można z tego wyciągnąć wnioski?

Single Point Of Failure

Centralne repozytorium kodu ma tą wielką zaletę, że jest centralne. SVN-y, SourceSafe-y i inne tego typu repozytoria kodu mają wielką zaletę – jedno źródło prawdy. To też najsłabsza strona – bo jak padnie serwer to nie ma nic. Na komputerach programistów pozostanie wprawdzie kod źródłowy ale bez jakiejkolwiek historii. Na ten wypadek warto mieć zbudowany odpowiedni plan backupu a właściwie kilku backupów – w chmurze, w szafie ogniotrwałej, offsite. Warto by było od czasu do czasu sprawdzić czy z backupu da się cokolwiek odzyskać. Generalnie w sytuacji awarii serwera odgrzebujemy backup, przywracamy repozytorum i pracujemy dalej no chyba, że padł sprzęt a my nie mamy zapasu, wtedy zamawiamy nowy, przywracamy co trzeba i pracujemy dalej. Już po kilku godzinach lub dniach spokojnie sobie pracujemy. Czy nie da się tego jakoś usprawnić?

Git na ratunek!

Dzisiejsza awaria GitLaba przeraziła całkiem sporą część internetu. Nie ma się co dziwić, bo wyobraź sobie, że nagle nie masz dostępu do swojego repozytorium. Mi się taka akcja zdarzyła w najgorszym możliwym momencie – w czasie wdrożenia przy sporej presji czasowej. Nagle repozytorium git-owe padło a dokładniej padł vpn do serwera ileś tam kilometrów dalej. Dwie osoby pracują nad kodem – wiadomo, ostatnie poprawki – czas ucieka, zmęczenie doskwiera a tu co? mamy ręcznie kod mergować? Na szczęście git to rozproszone repozytorium kodu a nie jak wspomniane w pierwszym akapicie „centralne repozytoria”. Rozproszone repozytorium oznacz tyle, że masz lokalną kopię całego repozytorium na komputerze. To oznacz, że bardzo szybko możesz postawić inne repozytorium. W moim przypadku sprowadziło się to do założenia repozytorium na bitbuckecie (bo tam można za darmo hostować prywatne repozytorum) a potem wykonania dwóch komend:


    git remote add backup git@bitbucket.org:.../.....git

    git push backup master

To spowodowało, że w chmurze pojawiła się pełna kopia repo i mogliśmy spokojnie pracować dalej. Cała operacja trwała może 5 minut razem z założeniem konta i wysłaniem danych.

Czy awaria gita to jakaś tragedia?

No właśnie, wracając do samej awarii gitlab-a (ale i innch, githuba, bitbucket-a i tych wszystkich tajnych firmowych „bezpiecznych” repozytoriów), jeśli tylko nasze repozytorium jest rozproszone to w 5 minut jesteśmy wstanie postawić kopię i pracować dalej. Taka awaria będzie dla nas mikro przeszkodą a nie tragedią blokującą pracę na godziny a czasem nawet na dni. To jest siła posiadania kopii repozytorium lokalnie…

… z małym zastrzeżeniem, jeśli regularnie commitujemy i regularnie pushujemy do zewnętrznego repozytorium.

 

Sprzątaj swój kodzik nieustannie czyli o ciągłej refaktoryzacji.

refaktoryzacja to proces ciągły

Siadam do kodu i piszę… i piszę… i piszę… a potem save, commit, push. Done? No, nie bardzo. Jeśli pracujesz w TDD, to dobrze wiesz co to jest: red, green, refactor. REFACTOR!, REFAKTORYZACJA! Czyli moment kiedy po prawie skończonej pracy porządkujemy kod. To  sprowadza się do posprzątania śmieci, usunięcia zbędnych zmiennych, metod i klas oraz wprowadzenia abstrakcji tam gdzie trzeba – ogólnie doprowadzenie kodu do stanu używalności – do stanu jaki chciałbyś sam zastać jak będziesz z nim pracować. Jeśli nie pracujesz w TDD to pewnie i tak sprzątasz twórczy bałagan – tylko nie nazywasz to refaktoryzacją. No chyba, że tego nie robisz; to może pora zacząć.

Dlaczego kod nie refaktoryzowany ssie?

Ile razy ktoś marudził na kiepski kod? Jak to jest, że taki kod powstaje? Sam się przecież nie pisze. To my go takim robimy. Czasem nie ma czasu, żeby sprzątnąć bo deadline albo jakakolwiek inna wymówka, ot po prostu nie refaktoryzujemy. Czasami po prostu nie mamy chęci i energii; to jednak nikogo nie zwalnia z obowiązku refaktoryzowania od czasu do czasu. Przecież koniec końców to  my w przyszłości będziemy z tym kodem najwięcej obcować. Zawsze można coś zwalić na innych członków zespołu. Im większy zespół tym łatwiej ale czy na pewno o to chodzi? Jesteśmy dorośli… trzeba po sobie posprzątać. Jaki jest sens trzymania 10 pustych linii pomiędzy metodami? To nie jest kartka papieru gdzie kiedyś coś dopiszemy. Nic tak nie rozprasza jak wtedy, gdy przewijając kod widzisz raz większe a raz mniejsze dziury w kodzie. Do tego jakieś kawałki kodu wykomentowane. Serio? Przecież nawet nie wiadomo czy to jeszcze działa. Co to robiło. Wywal te komentarze i wywal puste miejsca i niech to jakoś wygląda. Na początek tyko tyle i aż tyle. Dzisiaj po otwarciu 690 linijkowego pliku zacząłem wywalać takie puste miejsca. Jak skończyłem zostało ich 615. Nie usunąłem wszystkich pustych linii bo to by było bez sensu.

Najprostsza refaktoryzacja – puste linie

Puste linie są świetnym narzędziem do poprawienia czytelności kodu gdy oddzielają metody, gdy oddzielają usingi od namespace-a czy logiczne kawałki kodu od siebie. Wtedy ich użycie jest bardzo zasadne. Kod ma się dobrze i łatwo czytać a takie wolne miejsce pozwala coś zaznaczyć . Edytory kodu nie mają (na szczęście) pogrubiania czy ustawiania różnych fontów dla kawałków kodu (wyobrażasz sobie pół metody boldem bo to jest ważniejsze pół metody?). Wolna linia jest naszym narzędziem.

A wracając do wątku… po wyczyszczeniu tego jednego pliku odpaliłem te same reguły na całym solution i okazało się, że 120 plików się zmieniło. Jak dobrze, że są automaty, które potrafią usprawnić ten proces 🙂

A jak to jest w innych branżach?

W piekarni, cukierni, kuchni robi się bałagan. To jest naturalny efekt uboczny procesu przygotowania produktu. Tu się coś wysypie, tam się wyleje. Nie da się utrzymać kuchni bez jednego brudka, bez jednej skazy podczas gotowania,ale naturalne jest, że po skończonej pracy wszystko się sprząta. Nie zostawia się na kiedyś. Nikt nie mówi, jutro. Jak się zostawi syf to potem się zalęgnie robactwo i będzie coraz trudniej doprowadzić lokal do stanu używalności. Zresztą, czy ty jako klient swojej ulubionej restauracji wolisz, aby sprzątali na kuchni codziennie czy może nie sprzątali w ogóle a raz na pół roku (jak wynegocjują z klientami sprint na sprzątanie) robili miesiąc wielkiego, gruntownego sprzątania? Myślisz, że tak sobie wymyślam? Zobacz jak pracują kucharze w MasterChefie gdzie gotują amatorzy a jak w Top Chefie gdzie gotują zawodowcy. Pomimo skrajnie skromnych ilości czasu w Top Chefie na ugotowanie czegokolwiek – oni ciągle sprzątają. Gotują i ciągle, dbają o to aby było czyściutko – to się nazywa ciągła refaktoryzacja w kuchni. To nie jest zryw przed końcem czasu, to jest ciągły proces, ich druga natura. Talerz leży do wydania a stanowisko prawie jak nietknięte. W MasterChef-ie natomiast jest więcej czasu a mimo tego często na stanowiskach jest… bałagan. Jest bałagan, bo uczestnicy nie mają we krwi ciągłego sprzątania swojego warsztatu no i jak już dzieło jest skończone to nie ma czasu aby doprowadzić stół do porządku. To jest różnica pomiędzy profesjonalistami a amatorami.