Potem jest zielone światło i ktoś próbuje napisać GameManagera. Prawdopodobnie do przechowywania wielu GameStates, może do przechowywania kilku GameObjects, nic wielkiego, naprawdę. Słodki, mały menedżer.
Wiesz, kiedy to czytałem, miałem w głowie małe alarmy. Obiekt o nazwie „GameManager” nigdy nie będzie słodki ani mały. I ktoś to zrobił, aby wyczyścić kod? Jak to wcześniej wyglądało? OK, żartujmy na bok: nazwa klasy powinna być wyraźnym wskazaniem tego, co robi klasa, i to powinno być jedno (aka: zasada pojedynczej odpowiedzialności ).
Ponadto możesz nadal mieć obiekt taki jak GameManager, ale najwyraźniej istnieje on na bardzo wysokim poziomie i powinien zajmować się zadaniami na wysokim poziomie. Prowadzisz katalog przedmiotów do gry? Być może. Ułatwienie komunikacji między obiektami gry? Pewnie. Obliczanie kolizji między obiektami? Nie! Z tego powodu nazwa Menedżera jest niezadowolona - jest zbyt szeroka i pozwala na wiele nadużyć pod tym sztandarem.
Szybka reguła dotycząca wielkości klas: jeśli napotkasz kilkaset wierszy kodu na klasę, coś zaczyna się nie udać. Bez nadgorliwości, wszystko ponad, powiedzmy, 300 LOC jest dla mnie zapachem kodu, a jeśli przekroczysz 1000, powinny zadzwonić dzwonki ostrzegawcze. Wierząc, że w jakiś sposób łatwiej jest zrozumieć 1000 linii kodu niż 4 dobrze ustrukturyzowane klasy po 250, każda oszukasz siebie.
Gdy czas staje się problemem, nie ma sposobu, aby napisać osobną klasę lub podzielić tego gigantycznego menedżera na podrzędne.
Myślę, że dzieje się tak tylko dlatego, że problem może rozprzestrzeniać się do punktu, w którym wszystko jest kompletnym bałaganem. Praktyka refaktoryzacji jest naprawdę tym, czego szukasz - musisz ciągle ulepszać projekt kodu w małych krokach .
Co sugerujesz, aby temu zapobiec?
Problem nie jest technologiczny, więc nie powinieneś szukać rozwiązań technologicznych. Problem w tym, że w twoim zespole jest tendencja do tworzenia monolitycznych fragmentów kodu i przekonanie, że w jakiś sposób korzystne jest w średnim / długim okresie takie działanie. Wydaje się również, że zespołowi brakuje silnej przewagi architektonicznej, która sterowałaby architekturą gry (a przynajmniej ta osoba jest zbyt zajęta, aby wykonać to zadanie). Zasadniczo jedynym wyjściem jest przekonanie członków zespołu, że takie myślenie jest złe. Nikomu nie sprzyja. Jakość produktu pogorszy się, a zespół spędzi jeszcze więcej nocy na naprawie.
Dobrą wiadomością jest to, że natychmiastowe, wymierne korzyści z pisania czystego kodu są tak wspaniałe, że prawie wszyscy programiści bardzo szybko zdają sobie z tego sprawę. Przekonaj zespół, aby pracował przez chwilę w ten sposób, a wyniki zrobią resztę.
Trudność polega na tym, że rozwijanie wyczucia tego, co stanowi zły kod (i talent do szybkiego wymyślania lepszego projektu), jest jedną z trudniejszych umiejętności do nauczenia się w rozwoju. Moja sugestia opiera się na nadziei, że w zespole jest ktoś wystarczająco starszy, kto może to zrobić - o wiele łatwiej przekonać ludzi w ten sposób.
Edycja - trochę więcej informacji:
Ogólnie rzecz biorąc, nie sądzę, aby twój problem ograniczał się do tworzenia gier. U jego podstaw leży problem inżynierii oprogramowania, stąd moje komentarze w tym kierunku. To, co może się różnić, to natura branży tworzenia gier, nie jestem pewien, czy jej wyniki i termin są zorientowane bardziej niż inne rodzaje rozwoju.
Jednak, szczególnie w przypadku tworzenia gier, przyjęta odpowiedź na to pytanie na StackOverflow dotycząca wskazówek dotyczących „szczególnie architektury gier” mówi:
Przestrzegaj stałych zasad projektowania obiektowego ....
To jest dokładnie to, co mówię. Kiedy jestem pod presją, również piszę duże fragmenty kodu, ale wywierciłem sobie w głowie, że to dług techniczny. To, co zwykle działa dla mnie dobrze, to spędzić pierwszą połowę (lub trzy czwarte) dnia na produkcji dużej ilości kodu średniej jakości, a następnie usiąść i pomyśleć o tym przez chwilę; Zrobię trochę projektowania w mojej głowie lub na papierze / tablicy, o tym, jak nieco poprawić kod. Często dostrzegam powtarzający się kod i jestem w stanie zmniejszyć całkowitą liczbę wierszy kodu, rozkładając różne elementy, jednocześnie poprawiając czytelność. Tym razem zainwestowane pieniądze zwracają się tak szybko, że nazywanie tego „inwestycją” brzmi głupio - dość często wybieram błędy, które mogłyby zmarnować połowę mojego dnia (tydzień później), gdybym na to pozwolił.
- Napraw rzeczy w tym samym dniu, w którym je kodujesz.
- Będziesz zadowolony, że zrobiłeś to w ciągu kilku godzin.
Dojście do przekonania, że powyższe jest trudne; Udało mi się to zrobić dla własnej pracy tylko dlatego, że ciągle doświadczałem efektów. Mimo to wciąż trudno mi usprawiedliwić poprawianie kodu, gdy mogę więcej rezygnować ... Zdecydowanie rozumiem, skąd pochodzisz. Niestety, ta rada jest może zbyt ogólna i niełatwa do zrobienia. Jednak mocno w to wierzę! :)
Aby odpowiedzieć na konkretny przykład:
Clean Code wuja Boba wykonuje niesamowitą pracę, podsumowując, jak wygląda kod dobrej jakości. Zgadzam się z prawie całą jego zawartością. Tak więc, kiedy myślę o twoim przykładzie klasy menedżera LOC na 30 000 osób, nie mogę się zgodzić z częścią dotyczącą „dobrego powodu”. Nie chcę zabrzmieć obraźliwie, ale takie myślenie doprowadzi do problemu. Nie ma dobrego powodu, aby mieć tak dużo kodu w jednym pliku - to prawie 1000 stron tekstu! Wszelkie korzyści związane z lokalizacją (szybkość wykonywania lub „prostota” projektu) zostaną natychmiast unieważnione przez deweloperów, którzy całkowicie zapadną w pamięć, próbując poradzić sobie z tą potwornością, i to nawet zanim omówimy połączenie itp.
Jeśli nie jesteś przekonany, moją najlepszą propozycją byłoby wziąć kopię powyższej książki i przejrzeć ją. Zastosowanie tego rodzaju myślenia prowadzi do tego, że ludzie dobrowolnie tworzą czysty, zrozumiały kod, który ma ładną strukturę.