Nie, nie chodzi mi o żadne kapłańskie śluby czystości. Od początków mojej "kariery" z programowaniem dręczy mnie jeden problem, burdel w kodzie, oczywiście jest kilka razy lepiej obecnie niż kiedyś, to nie tak że zupełnie pod tym względem nic się nie rozwija, jednak ciągle czuję taki niedosyt i poczucie że im większy kod tym coraz bardziej wszystko wymyka się z pod kontroli i coraz trudniej jest z tym kodem pracować, na początku jest bajka, potem zaczynają się schody i zniechęcenie. Chciałbym się spytać jak wy konkretnie trenowaliście ten aspekt programowania, ja programuje dla przyjemności, tworzę gry dla siebie, jest to moje hobby i też w tym kierunku kładę nacisk na moje pytanie, jak zachować porządek w kodzie gry? Znam oczywiście taką stronę: https://gameprogrammingpatterns.com/ ale to wciąż za mało, chciałbym czegoś więcej, co możecie polecić? Jakieś książki, poradniki yt,tutoriale z internetu?
Pierwszym i najwazniejszym krokiem jest niemutowalnosc :)
Local reasoning i pewnosc, ze pod stolem nic sie nie spierdzieli duzo daje.
Niemutowalność jest istotna, ale to dodatek, który nawet nie zawsze daje się zastosować.
Najważniejsze jest "dziel i rządź" czyli poprawne dzielenie problemu na abstrakcje. (Wtedy i niemutowalność wyjdzie sama, tam gdzie możliwa.)
Chciałbym się spytać jak wy konkretnie trenowaliście ten aspekt programowania, ja programuje dla przyjemności, tworzę gry dla siebie, jest to moje hobby i też w tym kierunku kładę nacisk na moje pytanie, jak zachować porządek w kodzie gry?
Czytałeś jakieś książki o wzorcach projektowych lub czystym kodzie? Większość ogólnych zasad powinna mieć zastosowanie także do gier.
Mi się poprawiła jakość kodu od kiedy zacząłem pisać do niego testy. Piszesz testy?
nawet nie zawsze daje się zastosować.
No chodzi o to zeby wypchnac ta mutowalnosc gdzies na zewnatrz, gdzie jest do ogarniecia. Troche jak ze smieciami - lepiej jak sa gdzies w koszu a nie co trzy kroki jakas puszka albo plastik sie wala.
Książki żadnej nie czytałem, możecie jakieś polecać.
Porada w nieco innym wymiarze, nie X tylko Y: poważny romans z innym językiem (i jego ekosystemem)
Mam swoje porzekadło, że mocno poznając trzeci język, głęboko rozumiesz pierwszy.
http://weitblick.bistum-eichstaett.de/wie-viele-sprachen-du-sprichst-sooft-mal-bist-du-mensch/
stivens napisał(a):
Pierwszym i najwazniejszym krokiem jest niemutowalnosc :)
somekind napisał(a):
Niemutowalność jest istotna, ale to dodatek, który nawet nie zawsze daje się zastosować.
No właśnie, niemutowalność i gry to niekoniecznie muszą iść w parze (nie musi to być wydajne, żeby tworzyć cały czas nowe obiekty i odśmiecać stare)
Czasem lepiej jest panować nad mutacjami, mieć je pod kontrolą, rozumieć, że są częścią układanki, ale z drugiej strony pamiętać o konsekwencjach.
Myślę, że trzeba trochę popisać spaghetti kodu, takiego ze zmiennymi globalnymi i z najgorszymi praktykami, żeby zrozumieć, że jednak mutacje latające po całej apce to nie musi być dobry pomysł (dobrze, żeby to był kod oparty na eventach, czy asynchroniczności, żeby jeszcze boleśniej to odczuć). Ale czy zaraz od razu popadać w drugą skrajność i wszystko robić niemutowalne? Nie zawsze jest taka potrzeba.
"shared mutable state is the root of evil", ale samo "mutable state" nie musi być złem. Tak samo nie musi być złem trzymanie stanu, który się zmienia pod spodem (więc jest mutowalny), ale współdzielenie tego stanu tylko w określonych okolicznościach i w określony sposób.
No rzeczywiście w grach to nie najlepszy pomysł, ale w apkach biznesowych potencjalny koszt niemutowalności jest bardzo niski a zysk bardzo duży. Ja bym wychodził z odwrotnego założenia -immutability by default, mutability when necessary. Tak naprawdę to głównie IO potrzebuje mutowalnosci
Ale co on AAA robi?
LukeJL napisał(a):
stivens napisał(a):
Pierwszym i najwazniejszym krokiem jest niemutowalnosc :)
somekind napisał(a):
Niemutowalność jest istotna, ale to dodatek, który nawet nie zawsze daje się zastosować.
No właśnie, niemutowalność i gry to niekoniecznie muszą iść w parze (nie musi to być wydajne, żeby tworzyć cały czas nowe obiekty i odśmiecać stare)
Czasem lepiej jest panować nad mutacjami, mieć je pod kontrolą, rozumieć, że są częścią układanki, ale z drugiej strony pamiętać o konsekwencjach.
Myślę, że trzeba trochę popisać spaghetti kodu, takiego ze zmiennymi globalnymi i z najgorszymi praktykami, żeby zrozumieć, że jednak mutacje latające po całej apce to nie musi być dobry pomysł (dobrze, żeby to był kod oparty na eventach, czy asynchroniczności, żeby jeszcze boleśniej to odczuć). Ale czy zaraz od razu popadać w drugą skrajność i wszystko robić niemutowalne? Nie zawsze jest taka potrzeba.
"shared mutable state is the root of evil", ale samo "mutable state" nie musi być złem. Tak samo nie musi być złem trzymanie stanu, który się zmienia pod spodem (więc jest mutowalny), ale współdzielenie tego stanu tylko w określonych okolicznościach i w określony sposób.
Tylko w idelogiach są rzeczy 100% dobre i 100% złe - w realnym życiu jest inaczej. Masz plusa
Np takie "lekarstwo" immutabilistów zwykle znane jako "with"
IJabłko jabłko2 = jabłko1.withUpiecz();
Ja też wolę mieć dwa jabłka niż jedno :)
Dwa podejścia:
-
Z wiedzą - jak masz wiedzę wtedy masz większe szanse, że unikniesz problemów wynikających ze sposobu użycia przeglądarki, bazy czy też dodatkowych narzędzi na których docelowo bazujesz. W oprogramowaniu wszystko ma jakiś dodatkowy narzut i wady o których można długo dyskutować. Stąd pracę z komputerem warto postrzegać jak dialog w którym chodzi o korzystne kompromisy z perspektywy celu jaki zamierza się osiągnąć. Wiedza pod tym względem umożliwia podjęcie lepszych i przede wszystkim świadomych decyzji, pozwala wypracować prostsze rozwiązania, unikać rażących błędów itd
-
Natomiast jak nie masz wystarczająco dużo wiedzy, wtedy pozostaje Ci bycie pilnym uczniem. Musisz wtedy uważnie obserwować to do czego prowadzi Cię sam projekt, musisz zadawać sobie pytania o rzeczy które budzą Twoje wątpliwości, musisz uwzględnić kontekst i podejmować próby patrzenia na problem z różnych stron, po to by móc zrozumieć istotę problemu i wiedzieć jak sie do niego ustosunkować.
Co do wzorców i przeróżnych technik to są one w pewnym stopniu pomocne, ponieważ pozwalają spojrzeć na problem z innej strony. Natomiast one nie zastąpią myślenia. Jestem pewien, że ktoś kto nie zna wzorców, zacznie je nieświadomie stosować o ile po drodze zacznie analizować problem oraz cel do jakiego zmierza.
Mi bardzo pomogło patrzenie pod kątem code reusability. Świadomość, że kod będę jeszcze używał w kolejnych projektach, zmusza mnie do myślenia bardziej uniwersalnego. Konkretny system robi to co powinien, nie mniej, nie więcej. Rozwijam sobie bazę (zwał jak zwał, może framework ładniej brzmi) z kodem od kilku projektów. Gdy widzę, że czegoś brakuje lub coś tu nie gra, to modyfikuję ją w taki sposób, by działała poprawnie i dla poprzednich projektów i aktualnych.