Читать книгу Programowanie gier - Robert Nystrom - Страница 18

Zanim będziemy mogli zmienić kod w celu dodania nowej funkcjonalności, naprawienia błędu czy z dowolnego innego powodu, który sprawił, że odpaliliśmy nasz edytor, musimy zrozumieć, co robi istniejący kod. Nie musimy rzecz jasna znać całego programu, ale musimy załadować wszystkie jego istotne fragmenty do naszego mózgu ssaka naczelnego.

To dziwne, ale jest to dosłownie proces OCR.

Zwykle staramy się prześliznąć się przez ten krok, ale często jest to najbardziej czasochłonny element programowania. Jeśli uważamy, że stronicowanie jakiejś ilości danych z dysku do pamięci RAM jest powolne, spróbujmy przestronicować je do naszego mózgu za pośrednictwem pary nerwów wzrokowych. Kiedy cały poprawny kontekst znajdzie się już w naszej pamięci, zastanawiamy się przez moment i dochodzimy do rozwiązania. Czasem możemy przez dłuższą chwilę poruszać się tam i z powrotem, ale często jest to proste. Kiedy już zrozumiemy problem i fragmenty kodu, których dotyczy, samo kodowanie okazuje się trywialne.

Przez chwilę stukamy naszymi mięsistymi palcami w klawiaturę, aż na ekranie pokażą się światełka we właściwych kolorach. I po wszystkim, prawda? Chwila, moment! Zanim napiszemy testy i prześlemy kod do inspekcji, często czeka nas trochę czyszczenia.

Czy powiedziałem „testy”? O, rzeczywiście! Ciężko jest napisać testy jednostkowe jakiegoś kodu gry, ale duża część bazy kodu znakomicie nadaje się do testowania.

Upchnęliśmy w naszej grze jeszcze trochę kodu, ale nie chcemy, aby kolejna osoba, która się tu pojawi, potknęła się o zmarszczki, które pozostawiliśmy w źródle. Wyłączywszy przypadki minimalnych zmian, chcąc zintegrować nasz kod i wygładzić cały program, czeka nas odrobina reorganizacji. Jeśli zrobimy to poprawnie, kolejna pojawiająca się osoba nie będzie w stanie stwierdzić, kiedy został napisany jakiś wiersz kodu.

Nie będę się nad tym w tym miejscu rozwodzić, ale naprawdę warto w większym stopniu polegać na testach automatycznych (jeśli jeszcze tego nie robimy). Czy naprawdę nie mamy nic lepszego do roboty i za każdym razem chcemy sprawdzać różne rzeczy ręcznie?

Krótko mówią, diagram przepływu dla programowania wygląda jakoś tak:

Rysunek 1.1. Dzień pracy programisty w pigułce

Teraz, gdy o tym myślę, fakt, że z tej pętli nie ma wyjścia, wydaje mi się odrobinę niepokojący.