Autor Wątek: Pisanie kodu, praca nad dużymi produkcjami a zapamiętywanie struktur...  (Przeczytany 1611 razy)

Offline Timati

  • Użytkownik

# Październik 31, 2011, 00:22:53
Witam.

Otóz jestem ciekaw jak radzicie sobie z pracą przy dużych aplikacjach, powyżej 100 k. kodu. Piszecie system fizyki, czatu lub czegoś innego i wiadomo, że nie zapamiętacie jak wszystko działa, jakie są posczególne powiązania np. Z fizyki idzie coś do systemu czatów, albo odwrotnie no to jak to wszystko spisujecie, radzicie sobie z tym.

Tworzycie w PDF jakomś dokumentacje tego wszystkiego i opisujecie dokładnie poszczęgólne rzeczy czy jak... Chciałbym ogólnie wiedzieć jak pracują programiści przy tworzeniu gier.

-Dokumentowanie, opisywanie jak działają określone systemy i jak wygląda taki opis
-Praca nad bugami i ich naprawą
-Dodawanie pomysłów i ich realizacja

Akurat tworze duży projekt i już nie daje rady ze wszystkich i się gubie a więc chce sobie to uporzątkować wszystko jakoś.

Pozdrawiam.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline kapec94

  • Użytkownik

# Październik 31, 2011, 00:29:10
Zwykle Intellisense pamięta za mnie, co jest w danych strukturach/klasach, z czego muszę z zewnątrz korzystać.
A jeśli chcę sprawdzić, jaka jest np. złożoność dawno napisanej przeze mnie funkcji, po prostu czytam jej kod. Można sobie przypomnieć, jak dokładnie działa, nawet jeśli jest zapisana nieczytelnie :)

Offline Timati

  • Użytkownik

# Październik 31, 2011, 00:32:30
A jak ktoś nie pracuje w C++...

Btw. Znacie jakieś kreatory dokumentajci jak ma EtherField np. ?

Offline vashpan

  • Użytkownik
    • Strona

# Październik 31, 2011, 00:54:03
Zwykle Intellisense pamięta za mnie, co jest w danych strukturach/klasach, z czego muszę z zewnątrz korzystać.
A jeśli chcę sprawdzić, jaka jest np. złożoność dawno napisanej przeze mnie funkcji, po prostu czytam jej kod. Można sobie przypomnieć, jak dokładnie działa, nawet jeśli jest zapisana nieczytelnie :)

A ile projektow powyzej 100 000 linii kodu stworzyles/utrzymujesz ? ;)

@Timati: istnieja oczywiscie generatory dokumentacji na czele z Doxygenem. Ogolnie taka dokumentacja to po prostu odpowiednio sformatowane komentarze przy funkcjach/klasach. W wiekszosci przypadkow to wystarczy. Doxygen potrafi wygenerowac bardzo ladna dokumentacje. Chociaz oczywiscie najlepszy kod to taki ktory komentuje sie sam, chociazby swoja nazwa...

Inaczej niz w projektach "standalone" IMO sprawa wyglada przy bibliotekach, kodzie ktory bedzie uzywany przez kogos z zewnatrz, czasem nawet bez dostepu do zrodel. Wtedy na dokumentacje trzeba juz bedzie poswiecic wiecej czasu i np. dodac przykladowy kod, zastosowanie etc.

Przy pisaniu wlasnej gry nie jest to potrzebne ;) W gruncie rzeczy IMO warto pisac jakies wieksze wywody tam gdzie dzialanie jest naprawde niezrozumiale, lub moze zalezec od czegos ( mamy jakies specyficzne warunki brzegowe np. ) -> nadal mowie o kodzie nie-bibliotecznym, uzywanym "wewnetrznie"

Dobra dokumentacja w sumie wymaga osobnego ludka ktory bedzie sie zajmowal tylko tym.

Offline Timati

  • Użytkownik

# Październik 31, 2011, 00:59:07
Znacie programy co wpisuje treść, nagłówki a on sam generuje plik do edycji w tym programie, który mogę exportować do PDF.

A każy nagłówek i styl podstrony itd. mogę ustalić wygląd, czyli każy nagłówek jest niebieski a numer strony w ramce. Tak samo wygeneruje mi tytuł treści.

Offline świrus

  • Użytkownik
    • Tu trolluje

# Październik 31, 2011, 01:02:04
Doxygen, ale do pisania kodu dokumentacja tego typu jest bardzo mało użyteczna.

Offline Timati

  • Użytkownik

# Październik 31, 2011, 01:03:36
Chodzi mi o spis sobie jak działa dany system np. czatów bez czytania kodu.

// A macie coś jak opisałem z PDFem ? Bo ten doxygen ma ubogi interfejs jak patrzyłem sobie http://lambdasoft.dk/Comet/introducing/index.htm#UnimplementedStuffthatweknowabout
« Ostatnia zmiana: Październik 31, 2011, 01:11:55 wysłana przez Timati »

Offline intoxicate

  • Moderator
    • Jak zrobic gre FPP

# Październik 31, 2011, 09:03:49
First of all jedna struktura kodu i zasady pisania tak by kod potrafily odczytac wszystkie osoby w firmie. Jesli jeden programista pisze 'javowo' a drugi obiektowo a jeszcze inny calkiem inaczej robi sie bajzel.

Wychodze z paru pytan:
- co sie stanie jak wejdzie nowy programista?
- jak szybko bedzie w stanie zaczac pisac?
- jak moge przyspieszyc ten process?

Jesli jest dokument opisujacy zasady (wyglad kodu + sposoby implementacji) a caly kod jest dobrze skomentowany (w taki sam sposob) nowy programista szybko sie ogarnie. Doxygen sie przydaje jak ktos nie chce przegladac setek klas by dowiedziec sie jaka funkcjonalnosc maja

Offline vashpan

  • Użytkownik
    • Strona

# Październik 31, 2011, 09:17:45
Chodzi mi o spis sobie jak działa dany system np. czatów bez czytania kodu.

// A macie coś jak opisałem z PDFem ? Bo ten doxygen ma ubogi interfejs jak patrzyłem sobie http://lambdasoft.dk/Comet/introducing/index.htm#UnimplementedStuffthatweknowabout

Jak to ma ma ubogi interfejs ? ;] Wszystko co opisales potrafi zrobic Doxygen ( czasami z kilkoma uzytkowymi aplikacjami do pomocy ) Bez problemu mozesz sobie taka dokumentacje wyeksportowac do PDF'a ( czy czego tam chcesz... )

Ale to program konsolowy. Nakladka GUI jest tylko "pomoca" co by na szybko sklecic plik konfiguracyjny. Bardziej zaawansowane rzeczy opisujesz mu w pliku konfiguracyjnym. Wszystko masz opisane w manualu...

Offline quaikohc

  • Użytkownik

# Październik 31, 2011, 19:58:21

Ile firm tyle sposobów, ponadto jest bardzo dużo różnego oprogramowania, które ułatwia organizacje pracy. Co do powiązań to najczęściej metody które mają być udostępniane wystawiane są na interfejsy, które najczęściej są w osobnych plikach tak żeby łatwo było je znaleźć. Spoglądasz wtedy na metody w interfejsie i już wiesz mniej więcej jak mogą wyglądać powiązania. Sensowne nazywanie klas, metod itd i dobra organizacja kodu w 80% zastępuje pisanie komentarzy. Jeżeli nie piszesz dużej niezależnej biblioteki czy enginu na którym mają pracować inni, to imo w ogole korzystanie z doxygena to przesada. Możesz sobie wygenerować w vs (lub w dziesiątkach różnych narzędzi do umla) diagram klas (lub inne diagramy) z powiązaniami, żeby widzieć jak zbudowana jest całość - co kto lubi.

Co do bugów i tasków to chyba każda firma korzysta z jakiegoś systemu. Najprostszy to trac + wiki, bugzilla, tfs etc etc.

Imo zacznij od traca, wydzielaj jasno powiązania pomiędzy klasami i modułami, komentuj tylko to co naprawdę tego wymaga. Jeżeli masz okomentowane 70% kodu to zastanów się lepiej jak go przepisać tak żeby nie wymagał komentowania, bo w 90% da się to zrobić.

pozdrawiam

Offline siso

  • Użytkownik

# Październik 31, 2011, 22:33:09
Zwróć uwagę na to co powiedzieli quaikohc i vashpan. Komentarze w kodzie powinny byc tylko tam, gdzie sam kod nie wystarcza do wyjaśnienia swojej zasady działania. Im mniej ich, tym lepiej, bo zawsze wcześniej czy później ich treść rozjedzie się z kodem. Nikomu nie chce się utrzymywać komentarzy, narzędzi do tego nie ma (w sensie: wszystko trzeba robić "na piechotę"), więc lepiej ich nie mieć wcale :)

Co innego idee. Jeśli chcesz stworzyć jakiś system, napisz najpierw jego DDoc'a. Do tego wystarczy zwykły edytor tekstu. Musisz mieć ogólny zarys najpierw, żeby móc wyprowadzić wymagania. Z wymaganiami możesz tworzyć kod. Ważne, by był "pokrojony" na jak najmniejsze części, z których każda opisuje pojedynczą odpowiedzialność. Jeśli uda się zachować taki rozdział, jest mniej problemów z późniejszymi zmianami.

A diagramy? Czasami dobrze jest coś sobie na boczku narysować, ale z jakimiś tam UML-ami jest ten sam problem, co z niepotrzebnymi komentarzami - szybko tracą przestają odpowiadać rzeczywistości.

Powodzenia :)