Rozwój Oprogramowania

Jesteś w trakcie zmian w trzech plikach na feature branchu, nic jeszcze nie zacommitowane, gdy kolega pisze o null-pointerze, który wywala produkcję. Standardowy ruch to git stash, checkout na main, poprawka, push, a potem git stash pop w nadziei, że nic w twojej niedokończonej funkcjonalności nie zależało od plików, od których właśnie odszedłeś. git worktree pomija całą tę żonglerkę. Robi checkout brancha z hotfixem do drugiego folderu, obok twojego feature brancha, a oba korzystają z tego samego repozytorium. ...

Otwierasz funkcję, żeby naprawić błąd w jednej linijce, i czterdzieści minut później wciąż śledzisz, która gałąź ustawia którą zmienną. Trzy niepowiązane ze sobą zadania są zespawane w jeden blok, i żadne z nich nie ma nazwy. Pociągasz za jedną nitkę i nie wiesz, które inne się poruszają. To właśnie spaghetti code, i nazwa nie ma nic wspólnego z wcięciami czy stylem nazewnictwa. Opisuje przepływ sterowania: wykonanie skacze między warunkami tak, jak jeden makaron krzyżuje się z każdym innym w misce, a podążanie jedną ścieżką do końca oznacza trzymanie w głowie czterech poziomów if naraz. ...

Testy są zielone od trzech tygodni. Dziś npm test pada na asercji, która nie ma nic wspólnego z tym, co właśnie zmieniłeś, a git log v1.4.0..HEAD pokazuje 340 commitów od czterech osób od ostatniego release’a, o którym ktoś był pewien, że działa. Przeczytanie każdego diffa kosztuje cały dzień. Losowe przełączanie się między commitami idzie szybciej, ale wciąż nie jest planem. git bisect zamienia to w wyszukiwanie binarne. Podajesz mu jeden commit, o którym wiesz, że jest dobry, i jeden, o którym wiesz, że jest zepsuty; narzędzie robi checkout commita w połowie drogi między nimi i czeka, aż przetestujesz właśnie ten commit i zgłosisz wynik. Każda odpowiedź zmniejsza zakres o połowę. 340 commitów da się rozstrzygnąć w maksymalnie 9 testach, bo 2^9 = 512. ...

Robisz pull najnowszego main, a Git zatrzymuje się z CONFLICT (content): Merge conflict in checkout.js. Rozwiązujesz konflikt, a w logu pojawia się commit o nazwie Merge branch 'main' into feature/checkout, leżący na trzech commitach, które faktycznie napisałeś. Cztery commity, jedna prawdziwa zmiana. Kolega, który za miesiąc przeczyta tę historię, nie ma szans rozpoznać, który jest który. git merge i git rebase odpowiadają na to samo pytanie: jak zaktualizować swój branch o zmiany zrobione gdzieś indziej. Zostawiają za sobą bardzo różne ślady, a wybranie złego na wspólnym branchu robi realną szkodę. ...

Co właściwie robi Docker Docker to platforma open source, która pakuje aplikację razem ze wszystkim, czego potrzebuje do działania — kodem, bibliotekami, runtime’em, konfiguracją — w kontener zachowujący się tak samo na każdej maszynie. Przeprowadzka dobrze pokazuje ten kompromis. Masz dwie opcje: Przenosić wszystkie rzeczy luzem, mając nadzieję, że dotrą nienaruszone Zapakować wszystko w uporządkowane, opisane kartony, które łatwo przewieźć Docker robi dokładnie to z aplikacjami: “pakuje” je w kontenery, które zawierają wszystko, co potrzebne do działania. ...