Tytuł oryginalny: The Illusion of Simplicity Prawdopodobnie typ lub Na powierzchni te polecenia wydają się niemal magiczne: naciśnij klawisz Enter, a nagle twój kod zostaje skomponowany, połączony i - czasami - wykonany. Ale pod tą prostotą leży starannie zorganizowany system, zoptymalizowany, aby ułatwić twoje życie jako programisty, a jednocześnie być szybkim i przewidywalnym dla maszyn. go build go run Zrozumienie, w jaki sposób Go obsługuje budowę, uruchamianie i pamięć podręczną kodu, nie jest tylko ćwiczeniem akademickim. To wyjaśnia, dlaczego budowanie stopniowe jest tak szybkie, dlaczego rurociągi CI zachowują się konsekwentnie i dlaczego czasami pozornie trivialna zmiana może wywołać pełną kompilację. Na zakończenie otrzymasz jasny obraz: jak Go rozwiązuje zależności i struktury kodu w pakiety, jak kompilacja i łączenie działa za kulisami, Dlaczego budowa pamięci podręcznej jest tak wiarygodna i Co się dzieje, gdy typujesz go build lub go run? Jeśli kiedykolwiek zastanawiałeś się, dlaczego Go buduje "tylko pracę" lub dlaczego tymczasowy binary wydaje się niemal natychmiastowe, to jest głębokie nurkowanie, które łączy punkty - dla ludzi i maszyn. go run Model mentalny Go Toolchain Na pierwszy rzut oka, , , oraz wyglądają jak oddzielne polecenia, każde z własnym zachowaniem. W rzeczywistości są one tylko frontendami dla Każde polecenie Go przechodzi przez przewidywalną sekwencję: ładuje moduły, rozwiązuje zależności pakietowe, kompiluje pakiety, opcjonalnie łączy je w wykonanie, a czasami wykonuje wynik. Nie mechanika jego budowy. go build go run go test same underlying pipeline what happens to the final artifact Jednym z kluczowych pojęć interakcji jest Każdy plik .go w pakiecie jest traktowany zbiorowo, a sam pakiet jest jednostką, którą kompilator i buduje ścieżkę pamięci podręcznej. Go builds packages, not individual files Modyfikacja pojedynczego pliku w pakiecie może spowodować odbudowę całego pakietu. Pakiety stają się naturalnymi granicami pamięci podręcznej i kompilacji równoległej. Małe, skoncentrowane pakiety mają tendencję do lepszego skalowania w dużych bazach kodów, ponieważ kompilator może ponownie wykorzystać więcej wyników w pamięci podręcznej. Pilotaż jest prosty pod względem koncepcyjnym, ale wysoce zoptymalizowany: Go dokładnie wie, czego potrzeba do kompilacji i co można ponownie wykorzystać, dlatego budowanie wtórne wydaje się niemal natychmiastowe. : organizuje kompilację, łączenie, pamięć podręczną i wykonywanie, więc rzadko musisz martwić się o szczegóły. i Przestaje czuć się jak magia i zaczyna robić przewidywalne znaczenie. smart coordinator go build go run od Dwa projekty budowlane Zrób to.mod Zrób to.mod Zanim Go dotknie Twoich plików źródłowych, musi dowiedzieć się, co zbudować i w jakiej kolejności. i Pliki te określają Przeczytając te pliki, łańcuch narzędzi Go dokładnie wie, które pakiety są częścią Twojego budowania i który kod zewnętrzny należy odebrać, zweryfikować i włączyć. go.mod go.sum module graph Po załadowaniu wykresu modułu, Go ocenia każdy pakiet, aby określić jego zestaw źródłowy. Obejmuje to każdy plik .go należący do pakietu, filtrowany przez znaczniki budowania, system operacyjny, architekturę i wszelkie ograniczenia, które określiłeś. Uruchamianie poleceń na różnych maszynach daje identyczne wyniki, zakładając te same wersje modułów. go build Ważnym elementem współczesnego świata jest rola Dyrektywa w Niniejsza dyrektywa deklaruje minimalną wersję Go, dla której został zaprojektowany moduł. Wpływa na kilka cech budowy: semantykę językową, zachowanie kompilatora, a nawet analizę statyczną. Dyrektywa, semantyka językowa, zachowanie kompilatorów i kontrole mogą się różnić – łańcuch narzędzi egzekwuje to podczas kompilacji. go go.mod go Na końcu tego etapu, łańcuch narzędzi ma : wie, które pakiety kompilować, w jakiej sekwencji i które pliki należą do każdego pakietu.Z tą informacją w ręku, przechodzi do następnego kroku: kompilowanie pakietów i łączenie ich do binarnych, pewni, że nic nie zostanie pominięte lub źle kompilowane. complete, ordered build plan Kompilacja i łączenie w praktyce Gdy Go ma plan budowy z systemu modułowego, zaczyna przekształcać kod w coś, co maszyna może wykonać. Dzieje się to na dwóch różnych etapach: kompilacji i łączenia. Zrozumienie tych etapów jest kluczem do zrozumienia, dlaczego budowania Go są szybkie, deterministyczne i skalowalne. Zestaw jest pakowany Idź do kompilacji Każdy pakiet - niezależnie od tego, czy jest częścią projektu, czy zależnością zewnętrzną - jest traktowany jako niezależna jednostka. Dla każdego pakietu, który jest przechowywany w pamięci podręcznej budowy, oznacza to, że jeśli pakiet nie uległ zmianie od ostatniej budowy, program Go może pominąć ponowne skompilowanie go w całości, nawet jeśli inne pakiety, które od niego zależą, są odbudowywane. one package at a time intermediate artifacts Równoległość jest kolejną zaletą tego podejścia na pakiet: ponieważ kompilator zna wykres zależności, może kompilować jednocześnie wiele niezależnych pakietów, w pełni wykorzystując wielowarstwowe procesory. Linkowanie jest selektywne jest procesem łączenia skompilowanych pakietów w jeden wykonawczy. Pakiety biblioteki nigdy nie łączą się samodzielnie, istnieją wyłącznie jako artefakty wielokrotnego użytku dla innych pakietów. Na jednym projekcie, Go może kompilować dziesiątki pakietów, ale produkować zero binary, jeśli żaden z pakietów nie jest główny! Linkowanie only links main packages into binaries go build ./... Łączenie jest często najdroższym krokiem w budowie, ponieważ obejmuje łączenie wszystkich zależności w jeden wykonawczy, rozwiązywanie symboli i osadzenie metadanych. Co się kończy w binarnym Ostateczny binarny to coś więcej niż tylko skompilowany kod. Obejmuje: Wszystkie uzależnione pakiety, które są dostępne od głównego Tworzenie metadanych, w tym wersji modułu i informacji o kompromisie Instrukcje na poziomie maszyny zoptymalizowane dla platformy docelowej Ta kombinacja jest powodem, dla którego binary Go są samowystarczalne i odtwarzalne: zawierają wszystko, co jest potrzebne do uruchomienia bez polegania na zewnętrznych bibliotekach lub środowiskach czasowych. Z ludzkiej perspektywy sprawia, że wdrażanie jest proste. Tytuł oryginalny: The Build Cache: The Center of Gravity W centrum szybkości i przewidywalności Go jest jego Każdy skompilowany pakiet, każdy pośredni artefakt, a nawet niektóre wyjścia narzędzi są przechowywane w pamięci podręcznej adresowanej do zawartości, co pozwala Go na ponowne wykorzystanie pracy w budowach, poleceniach, a nawet Zrozumienie, jak działa pamięć podręczna, jest niezbędne, aby zrozumieć, dlaczego budowanie Go jest niemal natychmiastowe, nawet w przypadku dużych projektów. build cache go run Czym jest Cache Stores Build cache to coś więcej niż tylko kompilowane binary. Skompilowane artefakty pakietu (pliki .a) dla wszystkich pakietów w wykresie budowy Wyniki testów, w tym informacje o sukcesie w pamięci podręcznej Tymczasowe wyjścia narzędzi potrzebne do wykonania testu go run lub go Cache żyje na dysku (domyślnie w ) i jest całkowicie deterministyczny, co oznacza, że ten sam pakiet skompilowany z tymi samymi wejściami zawsze wyprodukuje ten sam wpis pamięci podręcznej. $GOCACHE Treść adresowana, a nie oparta na timestampie W przeciwieństwie do tradycyjnych systemów budowania, które opierają się na znacznikach czasu plików, Aby określić klucze pamięci podręcznej, każdy klucz pamięci podręcznej jest funkcją: content-based hashing Treść kodu źródłowego Wersja kompilator Wszyscy budują flagi platforma docelowa (GOOS / GOARCH) Istotne zmienniki środowiskowe Ta konstrukcja gwarantuje, że budowy są powtarzalne i zapobiega fałszywym pominięciom pamięci podręcznej z powodu nieszkodliwych zmian, takich jak znaczniki czasowe lub kolejność plików. Cache Invalidation wyjaśnione Nawet przy solidnej pamięci podręcznej, Go może czasami kompilować pakiety. Modyfikacja kodu źródłowego lub budowanie tagów Zmiana flagi kompilatora lub zmiennych środowiska Zmiana nazwy plików w pakiecie System pamięci podręcznej Go jest inteligentny: odbudowuje tylko to, czego naprawdę potrzeba do odbudowy.Nawet niewielkie, niesemantyczne zmiany mogą wywołać rekompilację, jeśli wpływają na hash budowy pakietu, ale w przeciwnym razie pamięć podręczna jest zaufana. Dlaczego cache jest bezpieczne do zaufania Budowa pamięci podręcznej została zaprojektowana tak, aby była przejrzysta i niezawodna: Rzadko trzeba go ręcznie wyczyścić Rekonstrukcja od podstaw produkuje identyczne artefakty idź biegać, idź testować i idź budować wszystkie dźwignie konsekwentnie Właśnie dlatego budowanie stopniowe Go jest tak szybkie: kompilator nigdy nie wykonuje więcej pracy niż to konieczne. Z perspektywy dewelopera czuje się magicznie. Z perspektywy systemów jest to po prostu zoptymalizowany rurociąg, który traktuje artefakty pakietowe jako obywateli pierwszej klasy. Produkcja artefaktów go build Idź budować Przykazanie go build jest końcem pracy łańcucha narzędzi Go. Jego zadanie jest proste do opisania, ale wyrafinowane w wykonaniu: Zrozumieć co W rzeczywistości pomaga przewidzieć jego zachowanie i uniknąć powszechnych niespodzianek. compile packages, link them if necessary, and produce a binary that is correct and reproducible go build Jak zbudować pakiety Handles Kiedy biegniesz na moduł lub pakiet, narzędzie najpierw bada wykres zależności pochodzący Każdy pakiet na wykresie jest sprawdzany pod kątem pamięci podręcznej budowy: jeśli pamięć podręczna zawiera ważny skompilowany artefakt dla pakietu, Go używa go ponownie zamiast kompilowania. go build go.mod Ponieważ idą Dotknięcie pojedynczego pliku wewnątrz pakietu może wywołać przebudowę całego pakietu. odwrotnie, jeśli zależność nie uległa zmianie, nigdy nie jest przebudowana, nawet jeśli inne pakiety na niej polegają. Bardzo dobrze, nawet w przypadku dużych projektów. operates at the package level incremental builds Linking i ostatni binarny Jak wspomnieliśmy wcześniej, tworzy tylko pakiet wykonawczy dla pakietów głównych. Pakiety biblioteki są kompilowane do artefaktów pośrednich, ale nigdy nie są powiązane na własną rękę. Po powiązaniu pakietu głównego, Go łączy wszystkie skomponowane pakiety w jeden binarny. Ten proces również osadza metadane w pakiet wykonawczy, w tym: go build Informacje o wersji modułu Kompromituj hasła (jeśli są dostępne) Konstrukcja metadanych platformowych Domyślnie włączenie szczegółów kontroli wersji jest regulowane przez flag, który domyślnie ustawia się na "automatyczny" i znacznik informacji VCS, gdy pozwala na to kontekst repozytorium (użyj Opuścić lub Więcej szczegółów można znaleźć w dokumentacji . -buildvcs -buildvcs=false -buildvcs=true tutaj To sprawia, że binary Go są samowystarczalne i wysoce odtwarzalne, pozwalając na ich wdrożenie z ufnością bez obaw o brak uzależnień. Skąd się biorą zdjęcia (przepraszam 😀) W przypadku defektu, pisze binarny w bieżącym katalogu, nazwany po pakiecie. nie wytwarza w ogóle binarnego, tylko zapewnia, że pakiet i jego zależności są kompilowane. Flaga lub użycie Tworzenie wielu pakietów w jednym czasie. go build go build -o ./... W systemie Windows wykonawcy mają przy jednoczesnym tworzeniu wielu pakietów głównych (np. ) bez , Go zapisuje jeden binarny na pakiet główny do bieżącego katalogu. .exe ./cmd/... -o Przewidywalne i niezawodne budynki Połączenie kompilacji na pakiet, pamięci podręcznej i selektywnego łączenia zapewnia, że go build jest przewidywalny. Budynki są odtwarzane przez maszyny Niezmieniony kod nigdy nie jest zbędnie odbudowywany Artykuły pośrednie są ponownie wykorzystywane w celu optymalizacji czasu budowy w skrócie , Nie tylko tworzy kod, ale . go build orchestrating a deterministic pipeline that balances human convenience with machine efficiency Komfort bez specjalnych przywilejów go run Idź biegać Jeśli jest koniem roboczym, który produkuje artefakty, które można wdrożyć, Wielu deweloperów myśli o tym jako o „kompilacji i uruchomieniu w jednym kroku”, ale nie jest: pod kapturem wykorzystuje ten sam system budowy jak , jest po prostu zoptymalizowany dla wygody, a nie wytrwałości artefaktów. go build go run go build co W rzeczywistości robi go run Kiedy Ty typujesz (lub listę plików), Go najpierw ocenia pakiet i jego zależności tak samo, jak Wszelkie pakiety kompilowane w pamięci podręcznej są ponownie wykorzystywane, więc kompilator wykonuje minimalną pracę dla niezmienionego kodu. . go run main.go go build links the main package into a temporary binary, executes it, and deletes the binary once the program finishes z punktu widzenia cegieł, To wyjaśnia, dlaczego powtarzające się powołania tego samego programu często wydają się natychmiastowe: ciężkie podnoszenie zostało już zrobione, a tylko łączenie lub zmiana pakietów może wywołać kompilację. go run Dlaczego Czuć się inaczej go run Pomimo tego, że jest to jeden i ten sam gazociąg, może czuć się wolniej w niektórych scenariuszach. Ponieważ wytwarza tymczasowy binarny za każdym razem, łączenie jest powtarzane, nawet jeśli wszystkie zależności są przechowywane w pamięci podręcznej. go run Inną różnicą jest to, że To jest dokładnie punktem: handluje binarnym ponownym użyciem dla łatwości wykonania. Nie musisz myśleć o tym, gdzie umieścić binarny lub jak go nazwać, narzędzie obsługuje go automatycznie. go run does not leave a persistent artifact Kiedy Czy narzędzie jest właściwe - a kiedy nie jest go run Jest idealny do: go run Szybkie eksperymenty lub skrypty Uruchamianie programów jednorazowych bez zakłócania systemu plików Testowanie małych programów interaktywnie Jest mniej odpowiedni do: Produkcja lub rozmieszczenie długotrwałe serwery, w których powtarzane łączenie dodaje nadgłówka Rurociągi CI, w których pamięć podręczna trwałych binarnych jest bardziej wydajna W takich przypadkach zalecany schemat jest , który daje korzyści z pamięci podręcznej, reprodukcyjności i trwałego artefakt bez poświęcania wydajności. go build && ./binary Ukryta poprawność Przejdź do testu Przejdź do testu o Praca opiera się na tych samych zasadach, co i Zrozumienie, w jaki sposób testy wchodzą w interakcję z systemem budowania pomaga wyjaśnić, dlaczego niektóre testy działają natychmiast, podczas gdy inne wywołują przebudowę, i dlaczego podejście Go wydaje się zarówno szybkie, jak i przewidywalne. go test go build go run Ponowne wykorzystanie kompilacji w testach Kiedy biegniesz , Go najpierw określa wykres zależności dla pakietu testowego, w tym wszelkich importowanych pakietów. Podobnie jak z lub Oznacza to, że duże zestawy testowe mogą często rozpocząć wykonywanie prawie natychmiast, ponieważ większość prac kompilacyjnych została już wykonana. go test reused from the build cache go build go run Nawet gdy zaangażowane są wiele pakietów, Go tylko odbudowuje te pakiety, które faktycznie się zmieniły.Połączenie kompilacji na pakiet i pamięci podręcznej zapewnia, że ciągłe testy są szybkie, nawet w dużych projektach. Wyniki testów Caching Oprócz przechowywania w pamięci podręcznej skompilowanych pakietów, należy również Jeśli test przejdzie i żadna z jego zależności lub odpowiednich flag się nie zmieniła, Go może pominąć ponowne uruchomienie testu w całości. caches test results Cache wyników testów ma zastosowanie tylko w trybie listy pakietów (np. lub ). w trybie lokalnym katalogu ( bez pakietu args), pamięć podręczna jest wyłączona. go test . go test ./... go test Takie zachowanie jest kontrolowane przez Na przykład flaga, Niezależnie od tego, jakie wyniki wynikają z wyświetlanych wyników. ( Powtarzanie testów i benchmarków. jest idiomatyczny sposób na ominięcie wyników pamięci podręcznej. zobacz na dalsze szczegóły) -count go test -count=1 -count -count=1 dokumentacji Przechowywanie w pamięci podręcznej wyników testów poprawia produktywność programistów i wydajność CI, szczególnie w przypadku dużych projektów o szerokim zasięgu testowym. . the system should avoid unnecessary work while preserving correctness Cache Invalidation w testach Test może zostać ponownie uruchomiony automatycznie, jeśli: Sam kod testowy się zmienił. Każda zależność od testu uległa zmianie. Flagi wpływające na test zmieniły się. Flagi nieprzechowywane w pamięci podręcznej lub zmienione pliki/env również unieważniają ponowne użycie. W przeciwnym razie Go ufa wynikowi w pamięci podręcznej, wiedząc, że jest Takie podejście zmniejsza „łuszczące się” budynki spowodowane niepotrzebnymi przebudowaniami i podkreśla przewidywalność nad ślepą wygodą. deterministic and reproducible Opcjonalne Handy Snippets Oto kilka przydatnych Innowacje, które wykorzystują zachowanie caching: go test Fresh run: go test -count=1 ./... - jak widzieliśmy wcześniej, to wyłącza pamięć podręczną wyników testów. Stres test: go test -run '^TestFoo$' -count=100 ./pkg - uruchamia TestFoo 100 razy, aby sprawdzić flakiness. Bench stabilność: go test -bench . -count=3 - uruchamia wszystkie wskaźniki 3 razy, aby uzyskać stabilne pomiary. Dlaczego jest to ważne dla deweloperów Z perspektywy dewelopera połączenie pamięci podręcznej budowy i pamięci podręcznej wyników testów tworzy przepływ pracy, który jest natychmiastowy i niezawodny: Drobne zmiany wywołują tylko niezbędne kroki kompilacji. Przechodzące testy rzadko przebiegają ponownie, chyba że coś się zmieni. Deweloperzy mogą szybko iterować bez obaw o ukryty stan. Poprzez traktowanie zarówno pakietów, jak i wyników testów jako artefaktów pamięci podręcznej pierwszej klasy, Go sprawia, że testy są szybkie i przewidywalne, wzmacniając tę samą optymalizację „ludzie + maszyny”, która leży u podstaw. i . go build go run Obserwacja i debugowanie systemu Build Większość czasu system budowy Go robi dokładnie to, czego się spodziewasz, cicho i efektywnie. Kiedy coś się wyłącza, jednak łańcuch narzędzi daje bezpośrednią, niską widoczność tego, co robi. Tworzenie Toolchain Talk Go zapewnia mały zestaw flag, które ujawniają rurociąg budowy bez zmiany jego zachowania: -x drukuje faktyczne polecenia wykonywane podczas budowy.To obejmuje powołania kompilatorów, kroki linkerów i wykonania narzędzi.Jest to najszybszy sposób na odpowiedź na pytanie: "Co właściwie robi teraz Go?" -n pokazuje, co zostanie wykonane bez uruchamiania poleceń. Jest to przydatne, gdy chcesz zrozumieć plan budowy bez wywoływania przebudowy. Praca zachowuje tymczasowy katalog budowy zamiast go usuwać, co pozwala na sprawdzenie plików pośrednich, generowanego kodu i tymczasowych artefaktów wyprodukowanych podczas kompilacji lub łączenia. Te flagi przekształcają łańcuch narzędzi Go z czarnego pudełka w przezroczysty rurociąg.Co ważne, nie wyłączają pamięci podręcznej, po prostu sprawiają, że uderzenia pamięci podręcznej i pominięcia są widoczne. Zrozumieć, dlaczego pakiet został odbudowany Jednym z najczęstszych źródeł zamieszania jest przebudowa pakietu "bez wyraźnego powodu". Pakiet zostaje odbudowany, gdy jakiekolwiek wprowadzenie do jego klucza pamięci podręcznej ulega zmianie. Wpływy obejmują kod źródłowy, znaczniki budowania, flagi kompilatorów, platformę docelową i odpowiednie zmienne środowiska. Zmiany zależności rozprzestrzeniają się w górę poprzez wykres pakietu. Używanie , często można zobaczyć, czy Go ponownie wykorzystał pamięci podręcznej artefakt lub skompilował pakiet, i wywnioskować, dlaczego z kontekstu. Jako pierwsza odpowiedź. -x go clean -cache Przymusowe odbudowy (kiedy tak naprawdę masz na myśli) Czasami naprawdę chcesz ominąć pamięć podręczną. Na przykład podczas walidacji czystej budowy lub debugowania problemów z łańcuchem narzędzi. Przymusowe odbudowywanie pakietów, ignorowanie pamięci podręcznej skompilowanych artefaktów go clean - cache oczyszcza całą pamięć podręczną budowy Te opcje są celowo wyraźne i nieco niewygodne. Go ma na celu poprawne ponowne użycie domyślnego, a ręczne unieważnienie pamięci podręcznej jest wyjątkiem. Unikaj przypowieści opartych na przesądach Ponieważ system budowy Go jest deterministyczny, zgadywanie rzadko pomaga. , , oraz dają ci konkretne dowody na to, co się dzieje, co prawie zawsze wystarcza, aby wyjaśnić zaskakujące zachowanie. -x -n -work Jeśli ufasz temu: budownictwo jest adresowane, pakiety są jednostką pracy, i cache jest bezpieczne do ponownego użycia, Debugowanie zachowania budowania staje się kwestią obserwacji, a nie próby i błędu. Wpływ na realne projekty Wybory projektowe za systemem budowy Go nie są przypadkowe. Najbardziej wyraźnie pojawiają się, gdy przechodzisz poza małe przykłady i zaczynasz pracować nad prawdziwymi bazami kodowymi: ciągłymi rurami integracji, dużymi repozytoriami i przepływami pracy napędzanymi przez edytora. czuć się szybko lokalnie to, co sprawia, że skala Go jest tak dobra w środowiskach produkcyjnych. go build Rurociągi i odtwarzalność Nacisk Go na deterministyczne, adresowane do zawartości budynki sprawia, że są szczególnie odpowiednie dla CI. Ponieważ wyjścia budynków pochodzą wyłącznie z zawartości źródłowej, wersji modułów i wyraźnej konfiguracji, budynki CI zachowują się konsekwentnie w różnych maszynach i środowiskach. Ta przewidywalność sprawia, że Go buduje bardzo przyjazny dla pamięci podręcznej. Niezależnie od tego, czy używasz wspólnej pamięci podręcznej budowy, warstw kontenerowych, czy infrastruktury zdalnego pamięci podręcznej, model kompilacji na poziomie pakietu Go pasuje naturalnie. Monorepos i duże bazy kodów W dużych repozytoriach pamięć podręczna budowy staje się granicą wydajności. Ponieważ pamięć podręczna Go kompiluje pakiety niezależnie, małe, dobrze zdefiniowane pakiety mogą być ponownie wykorzystywane w wielu budowach z minimalną nadwagą. Odwrotna strona polega na tym, że zbyt duże lub ściśle połączone pakiety mogą stać się blokadami. Mała zmiana w bardzo używanym pakiecie może unieważnić dużą część pamięci podręcznej, zwiększając czas budowy w całym repozytorium. Redaktorzy, narzędzia i automatyzacja Ten sam model budowy umożliwia ekosystem narzędzi Go. Edytorzy kodów, serwery językowe, lintery i generatory kodów opierają się na tym samym zrozumieniu kodu na poziomie pakietu. Ponieważ łańcuch narzędzi ujawnia jasny, deterministyczny rurociąg budowy, narzędzia mogą się głęboko zintegrować bez zgadywania lub ponownego wdrażania logiki budowania. To jest jeden z powodów, dla których narzędzia Go czują się wyjątkowo spójne: edytorzy i systemy CI widzą Twój kod w taki sam sposób, jak kompilator.Od autokompilacji po refaktorowanie po zautomatyzowane testowanie, wszystko opiera się na tych samych założeniach dotyczących pakietów, zależności i pamięci podręcznej. Tytuł: Zaufaj modelowi System budowy Go odniósł sukces, ponieważ stanowi wyraźny kompromis: optymalizuje przewidywalność nad inteligencją i wyraźną strukturę nad zachowaniem domniemanym. Na powierzchni wygląda to jak prostota. Poniżej znajduje się starannie zaprojektowany rurociąg, który traktuje pakiety jako jednostkę pracy, zawartość jako źródło prawdy i pamięć podręczną jako funkcję poprawności, a nie hack wydajności. Po internalizowaniu tego modelu wiele codziennych zachowań zaczyna mieć sens.Budowanie jest szybkie nie dlatego, że Go robi mniej pracy, ale dlatego, że unika robienia Praca się. jest wygodne, ponieważ ponownie wykorzystuje tę samą maszynę jak Wykonywanie testów jest wiarygodne, ponieważ wyniki testów są przechowywane w pamięci podręcznej przy użyciu tych samych zasad deterministycznych, co skompilowane pakiety. Niepotrzebne go run go build Dla ludzi oznacza to mniej niespodzianek, szybsze ścieżki zwrotne i narzędzia, które zachowują się konsekwentnie w edytorach kodu, maszynach i systemach CI. Dla maszyn oznacza to powtarzalne budowy, artefakty przyjazne dla pamięci podręcznej i system, który skaluje się naturalnie w miarę wzrostu baz kodowych. Jeśli istnieje jeden sposób, to jest to: system budowy Go nie jest czymś do walki lub pracy wokół. Jest to API na własną rękę - ten, który nagradza zrozumienie. Gdy zaufasz modelowi, łańcuch narzędzi przestaje czuć się magiczny i zaczyna czuć się zaufany, co jest dokładnie tym, czego chcesz od infrastruktury, która buduje kod.
