Czego nauczyłem się po 5 latach programowania; Wspominki Soltys Programmer Bot

Wstęp
3 grudnia minie 5 lat od kiedy zacząłem pisać grę Soltys Programmer Bot.
5 lat temu napisałem dwa posty na ten temat moich doświadczeń przy pisaniu tej gry.
- Programmer Bot – wersja Alpha. Moje przeżycia część 1
- Programmer Bot – wersja Alpha. Moje przeżycia część 2
Na moich studiach inżynierskich, na 2 drugim roku trzeba było napisać grę 3D z wykorzystaniem OpenGL. Gołego OpenGL, bez silników graficznych.
Cały rok pisał w C++, ja jak Che Guevara rewolucyjnie postawiłem, że napiszę grę w C#. Wiązało się, że nie będę miał supportu od prowadzących zajęcia, ale opłaciło się podjąć to ryzyko. Dzięki temu, że nie skupiałem na prawidłowej alokacji pamięci udało mi się „dostarczyć” więcej w krótszym czasie.
Kod jest dostępny na GitHub. Uruchomienie tego kodu wymaga jego znajomości. 😀
Gra jest klonem light-Bot. Jeżeli chcesz zobaczyć jaka to była gra to zagraj w light-bot.
Ostatecznie gra zajęła 3 miejsce w konkursie wewnątrz wydziałowym na najlepszą grę roku.
Co sądzę o swoim projekcie po 5 latach?
„Domyślny” dla Visual Studio .gitignore ignoruje pliki .obj
Jak pisałem ten kod to nie używałem systemu kontroli wersji git. Nie pamiętam czy nie używałem systemu kontroli wersji w ogóle czy używałem lokalnego SVNa.
Tak czy siak, po skończeniu poznałem GitHuba.
zrobiłem tak git init
wstawienie pierwszego lepszego .gitignore
, git add .
i potem git commit -am "init commit"
i oczywiście git push origin master
.
Pliki *.obj
są ignorowane w środowisku Visual Studio, gdyż najczęściej oznaczają Object file
plik przechowujący część kodu maszynowego który w następnym kroku zostanie połączony do pliku wykonującego.
Problem w tym, że pliki o rozszerzeniu *.obj
są wykorzystywane przez pliki w formacie Wavefront .obj file
. A to pliki przechowujące modele 3D. Jako że nie posiadam innej kopii niż ta znajdująca się na GitHubie, to znaczy, że straciłem dane.
Niestety to nie koniec złych wieści dla mnie, bo zazwyczaj w koło pliku wykonywanego trzymałem przykładowe poziomy dla mojej gry. Plik wykonywalny i jego katalog jest tworzony przez kompilator, a rzeczy tworzone przez kompilator nie trzyma się w systemie kontroli wersji, więc straciłem także oryginalne plansze.
Learning point
Każdy projekt zaczynaj od git init
i częstych commitów, bo duże commity są niebezpieczne.
Twórz README
Kodu w projekcie jest według Visual Studio Code Metrics (Analyze->Calculate Code Metrics->For Solution
). Lini kodu jest 1738. To nie dużo. Brak komentarzy nie stanowi problemu, aby połapać się co jest czym.
Brak pliku README, boli jeszcze bardziej. Brak informacji, jaka jest struktura plików przechowujących poziomy. Brakuje informacji o danych jakie są potrzebne do uruchomienia aplikacji. Jakie są zależności z zewnętrznymi bibliotekami? Jak to uruchomić? Jak to skompilować?
Learning point
Stwórz README, dla twojego projektu.
Menadżer klasy poziomów
Grzechy, które popełniłem podczas pisania LevelManager
:
- Nazwa klasy
- Założyłem, że wszystkie pliki poziomów istnieją
- brak mechanizmu sprawdzającego czy poziom istnieje na dysku – program wyrzuca nie obsłużony wyjątek.
- Poziomy mogą definiować rozmiar planszy w pierwszej lini, ale inny kod w innej klasie wymaga, żeby wszystkie plansze miały jednakowy stały rozmiar ustawiony na 8.
- Podczas czytania pliku z poziomem, gdy wystąpi jakiś błąd w formacie to wyrzucam swój wyjątek o nazwie
LevelFileException
z którym następnie nic nie robie i wyrzucam go do systemu. - Wbudowany edytor poziomów wymaga aby istniał poziom o nazwie „empty” na dysku, zamiast go stworzyć samemu
Ogólnie
- Wielokrotne zapisywanie się do eventów (bardzo źle)
- Klasy robią bardzo wiele różnych rzeczy na raz, aktualizacja logiki, renderowanie obiektów na scenie.
- Szczególnie w kodzie dotyczącym rederowania sceny, to duża ilość „magicznych wartości”
- Nie robienie
Dispose
na klasach implementującychIDisposable
- Model danych pozbawiony logiki sprawdzającej poprawność danych które przechowują. en:Wiki link
- Używanie Fabryki Abstrakcyjnej), gdzie nie ma to żadnego sensu.
Czego się nauczyłem po 5 latach?
Tworzyć programy bullet-proof. Zakładanie, złych scenariuszy i testowanie ich na swoim oprogramowaniu.