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

Ostatnimi czasy mam poczucie, że jeśli istnieje jakakolwiek metoda, która jest w stanie coś poradzić na te ograniczenia, to jest nią prostota. Obecnie za pomocą kodu usilnie staram się napisać najczystsze, najbardziej bezpośrednie rozwiązanie danego problemu. Po zapoznaniu się z kodem tego rodzaju, dokładnie rozumiemy, co on robi i nie jesteśmy w stanie wyobrazić sobie żadnego innego rozwiązania.

Staram się poprawnie ująć struktury danych i algorytmy (mniej więcej w tej kolejności), a następnie ruszyć dalej. Zauważyłem, że jeśli jestem w stanie zrobić coś w prosty sposób, powstaje mniej kodu. Znaczy to, że mniej kodu musi zostać załadowane do mojej głowy, aby go zmienić. Często działa on szybko, ponieważ po prostu jest tu niewielki narzut i niewiele kodu do wykonania. (Choć z pewnością nie zawsze tak jest. W niewielkiej ilości kodu można upakować sporo pętli i rekursji).

Zauważmy jednak, że nie twierdzę, że napisanie prostszego kodu zabiera mniej czasu. Można by sądzić, że tak jest, ponieważ finalnie dostajemy mniej kodu, ale dobre rozwiązanie nie powstaje dzięki przyrastaniu kodu, ale dzięki jego destylacji.

Blaise Pascal zakończył jeden ze swych znanych listów w następujący sposób: „List ten jest dłuższy jedynie dzięki temu, iż nie miałem czasu napisać go krócej”².

Inny cytat pochodzi od Antoine’a de Saint-Exupery’ego: „Wydaje się, że doskonałość osiąga się nie wtedy, kiedy nie można już nic dodać, ale raczej wtedy, gdy nie można nic ująć”³.

Mówiąc wprost, zauważyłem, że za każdym razem, gdy wracam do któregoś rozdziału tej książki, staje się on krótszy. Niektóre rozdziały stają się krótsze o 20%, nim zostaną ukończone.

Rzadko stawia się przed nami elegancki problem. Zamiast tego dostajemy stertę przypadków użycia. Chcemy, aby X robiło Y, gdy Z, a W, gdy A i tak dalej. Innymi słowy, mamy do czynienia z długą listą różnych przykładowych zachowań. Rozwiązanie wymagające najmniejszego umysłowego wysiłku polega na prostym zakodowaniu tych przypadków użycia, po jednym na raz. Jeśli przyjrzymy się początkującym programistom, zauważymy, że często zachowują się w następujący sposób: masowo produkują mnóstwo logiki warunkowej dla każdego przypadku, który przyjdzie im do głowy.

Nie ma w tym jednak nic eleganckiego, a kod napisany w takim stylu wali się, gdy pojawiają się dane wejściowe choćby odrobinę różne od tych, jakie pojawiały się w przykładach rozważanych przez programistę. Gdy myślimy o eleganckim rozwiązaniu, często mamy na myśli takie, które ma charakter ogólny: odrobina logiki, która nadal może poprawnie obsłużyć wiele przypadków użycia.

Odnalezienie takiego rozwiązania przypomina poniekąd dopasowywanie wzorców czy rozwiązywanie zagadki. Trzeba wysiłku, aby w różnorodności przypadków użycia odnaleźć leżący u ich podstawy ukryty porządek. Gdy uda nam się tego dokonać, uczucie jest niesamowite.