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

Prowadzi nas to do kolejnej kwestii: jest czas i miejsce na różne style kodowania. Większa część tej książki jest poświęcona tworzeniu łatwego w utrzymaniu, czystego kodu, więc moje przywiązanie do robienia tego we „właściwy” sposób jest jasne, niemniej niedbały kod również ma pewną wartość.

Pisanie kodu o dobrej architekturze wymaga starannego przemyślenia i ma swoje przełożenie na czas. Więcej nawet – utrzymanie dobrej architektury w trakcie życia projektu wymaga mnóstwa wysiłku. Musimy traktować naszą bazę kodu tak, jak dobry harcerz traktuje swoje obozowisko, zawsze próbując zostawić ją po sobie w trochę lepszym stanie, niż ją zastaliśmy. Ma to sens, jeśli przez długi czas będziemy żyć z tym kodem i nad nim pracować. Tak jak wspomniałem wcześniej, projektowanie gier wymaga jednak mnóstwa eksperymentów i poszukiwań. Szczególnie w początkowym stadium pisanie kodu, o którym wiadomo, że ostatecznie trafi do kosza, jest czymś powszechnym.

Jeśli po prostu chcemy dowiedzieć się, czy jakiś pomysł dotyczący rozgrywki w ogóle ma sens, pieczołowita dbałość o jego architekturę znaczy, że poświecimy więcej czasu, nim rzeczywiście pojawi się on na ekranie i będziemy w stanie uzyskać jakąś informację zwrotną. Jeśli okaże się, że pomysł się nie sprawdza, czas poświęcony na stworzenie eleganckiego kodu, który usuniemy, będzie stracony.

Prototypowanie – wklepanie kodu, który z ledwością działa wystarczająco dobrze, by można było uzyskać odpowiedź na pytanie projektowe – to całkowicie zasadna praktyka programistyczna. Istnieje jednak bardzo poważne zastrzeżenie. Jeśli piszemy niskiej jakości kod jednorazowego użytku, musimy mieć pewność, że będziemy w stanie go usunąć. Widziałem, jak kiepscy menedżerowie raz za razem grali w następującą gierkę:

Szef: „Hej, mamy ten pomysł, który chcielibyśmy wypróbować. Chodzi nam tylko o prototyp, więc nie musisz tego robić porządnie. Jak szybko mógłbyś to złożyć do kupy?”.

Programista: „Cóż, jeśli przytnę tu i tam, podaruję sobie testy, odpuszczę dokumentację i przymknę oko na tony błędów, wstępny kod mogę dostarczyć w ciągu kilku dni”.

Szef: „Znakomicie!”.

Mija kilka dni:

Szef: „Hej, ten prototyp jest świetny! Czy mógłbyś poświęcić kilka godzin na jego lekkie doczyszczenie, tak żebyśmy mieli już gotowy produkt?”.

Musimy się upewnić, że ludzie korzystający z jednorazowego kodu rozumieją, że nawet jeśli wygląda, jakby działał, nie można go zachować i trzeba go przepisać. Jeśli istnieje szansa, że koniec końców zostanie on z nami na dłużej, w ramach samoobrony możemy napisać go od razu porządnie.

Istnieje jeden trik gwarantujący, że nasz prototypowy kod nie będzie musiał stać się prawdziwym kodem. Polega on na napisaniu go w języku innym niż język wykorzystywany przez naszą grę. Dzięki temu trzeba będzie go przepisać, zanim trafi do rzeczywistej gry.