Autor Wątek: Projektowanie kodu - robicie? Jak?  (Przeczytany 2793 razy)

Offline tbox

  • Użytkownik

# Sierpień 31, 2016, 14:15:41
Póki co od początku projektu nic nie projektowałem, wszystko pisałem z głowy na zasadzie, że po przemyśleniu brałem się za pisanie, ale teraz tak się zastanawiam czy nie lepiej zacząć to projektować, ponoć przyspiesza to później kodzenie
No i nie wiem za bardzo jak się za to zabrać, rysować w zeszycie czy może znacie jakieś aplikacje na PC/telefon (Android)?
A może zostać jednak tak jak było, czyli pisać to co wiem już jak ma wyglądać?
Jak wy to robicie?

Offline Mr. Spam

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

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

  • +6
# Sierpień 31, 2016, 14:34:09
Ja bym nie próbował projektować na siłę, "bo tak jest lepiej". Projektuję swoje rozwiązanie wtedy, kiedy widzę taką potrzebę - bo jest tak skomplikowane, że już "nie mieści się w głowie". Natomiast nieraz zauważyłem, że łatwiej przychodzi mi po prostu zacząć kodować i kod jakoś sam układa się sensownie, a ewentualny projekt robię potem, jako jego dokumentację.

Jak projektować? Moim zdaniem jak najprościej. Jeżeli wystarczą Ci jakieś listy z punktami i podpunktami, to polecam plik tekstowy, dowolny edytor tekstu albo aplikację do notatek (jak mój ulubiony Microsoft OneNote). Jeżeli chcesz rysować diagram klas albo inne diagramy UML, to polecam kartkę i długopis, bo daje największą swobodę, elastyczność formatowania i łatwość użycia w porównaniu ze specjalizowanymi programami do rysowania takich diagramów.

Offline MrKaktus

  • Użytkownik

# Sierpień 31, 2016, 19:21:04
Jezeli system jest tak skomplikowany ze "nie miesci sie w glowie" i trzeba zaczac od projektu, to polecam zaczac od "use cases". Czyli co dokladnie on ma robic, jakie sa ramy jego dzialania, i pod te przypadki uzycia projektowac interfejs i optymalizowac wydajnosc.

Offline Avaj

  • Użytkownik

# Sierpień 31, 2016, 22:13:34
Projektowanie w sensie UML raczej nie ma sensu w przypadku gier, szczególnie tworzonych przez jedną osobę. Takie projektowanie jest dobre w zespole, gdzie każdy ma własne poletko i można szybko spojrzeć na diagram kto się czym zajmuje.

Co do normalnego projektowania i planowania np. architektury kodu, zawsze dobrze jest mieć luźny plan, ale rzeczywistość często weryfikuje i przychodzi czas, że trzeba zrobić refactoring. A refactoring lepiej robić wcześnie, gdy plan może być elastyczny, niż później, gdy już jest etap spaghetti code i refactoring można robić tylko pisząc od nowa :D

Offline Duckshorse

  • Użytkownik

# Sierpień 31, 2016, 23:19:11
Ja tam może się nie znam, bo i doświadczenie mam małe, ale czasem napisanie wszystkiego od nowa nie jest głupim pomysłem. W sensie, że nie ma się czego bać (o ile mówimy o małej skali, bo o większej to już nie mam zupełnie pojęcia :) ). Przy drugim podejściu widać wszystkie popełnione błędy, a nasze pierwsze podejście staje się całkiem dobrym podkładem do już finalnego wykonania.

Offline MrKaktus

  • Użytkownik

  • +1
# Wrzesień 01, 2016, 01:34:37
A refactoring lepiej robić wcześnie, gdy plan może być elastyczny, niż później, gdy już jest etap spaghetti code i refactoring można robić tylko pisząc od nowa :D
Czasami refactoru od 0 sie po prostu nie da uniknac. Przyklad z zycia: wyszedl D3D12 i Vulkan i nagle stary abstraction layer w silniku totalnie nie pasuje. Trzeba caly renderer pisac od zera niestety i jest to gigantyczny task na osobo miesiace :/.

Offline Patrulek

  • Użytkownik

  • +1
# Wrzesień 01, 2016, 13:43:23
A ja z kolei polecam projektować nawet jeśli nie jest to nic dużego i można to skończyć relatywnie szybko. Nie musi to być bardzo szczegółowe projektowanie z różnymi diagramami klas/sekwencji itd, nawet zwykłe use case'y w punktach często dużo dają. Oprócz tego, że się nieco podszkolisz to może Ci to zaoszczędzić później trochę pracy plus nic tak nie motywuje jak odhaczanie zrobionych zadań. Bo rozumiem, że teraz robisz coś na zasadzie: "potrzebuję takiej funkcjonalności, to sobie ją teraz napiszę"? Ok, wtedy też można śledzić swój progres, ale według mnie, to nie to samo.

Dodatkowo projektowanie ma jak dla mnie ważną cechę: jeśli projekt zaczyna zbaczać z toru (w końcu wszystkiego od razu nie przewidzimy) to być może powinniśmy się znów zastanowić w jakim kierunku powinno to wszystko dalej pójść i pomyśleć o refactoringu zanim utkniemy w bagnie.

Ale o tym co wyżej pewnie też gdzieś już wyczytałeś, a jak ja to robię? Zaznaczam, że też się z tym borykam jeszcze, ale tutaj mogę potwierdzić słowa Rega i MrKaktusa.
Wpadłem na pomysł na pewną aplikację, pierwsze co zrobiłem to rozpisałem sobie w punktach, co powinna ona robić (interakcja z użytkownikiem ogranicza się do minimum, ale sama w sobie wykonuje trochę czynności). Przy czym tutaj starałem się raczej przechodzić od ogółu do szczegółu, tj. mam jakąś funkcjonalność i idę w głąb problemu szukając jego podproblemów i zależności od innych problemów. Przykładowo potrzebowałem monitorować aktywne okno w systemie, zadałem sobie pytania: "jak?", "w jaki sposób?". Timer, i tu schodzimy głębiej, "jaki interwał?", "w jaki sposób zaimplementować?" itd.  Później szukałem zależności, aplikacja powinna coś tylko jeśli aktywne jest konkretne okno. W taki sposób starałem się rozpracować jak największą liczbę funkcjonalności.
Następnie starałem się je dopasować w logiczne moduły z podmodułami: parser XML, komunikacja z systemem itd. Kolejno stworzyłem sobie diagram z zależnościami między modułami. I ok, dzięki temu udało mi się stworzyć podstawową wersję aplikacji. W międzyczasie wpadłem na kilka dodatkowych pomysłów, których wcześniej nie zaprojektowałem. Więc stworzyłem sobie proste gui dla kolejnej wersji i zacząłem kodzić. Złapałem się na tym, że po dodaniu nowej funkcjonalności potrzebna jest mi jednak dalsza analiza i refactor.

Ze swojej strony mogę jeszcze polecić stronkę draw.io na której sobię tworzę diagramy i gui. Powyższe może nie odnosi się w pełni do gier, ale nie samymi grami człowiek żyje :P
« Ostatnia zmiana: Wrzesień 15, 2016, 10:45:20 wysłana przez Patrulek »

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

  • +1
# Wrzesień 01, 2016, 23:36:50
Czytam Wasze wypowiedzi i tak mi teraz przyszło do głowy, że być może to zaawansowani programiści mają już we krwi projektowanie i pisanie dobrego kodu na bieżąco, ale początkujący - którzy dopiero się tego uczą - mogą skorzystać na próbie całościowego zaprojektowania swojego programu przed przystąpieniem do jego pisania. Podobnie może być ze stosowaniem wzorców projektowych czy całej idei programowania obiektowego.

Duckshorse: Odnośnie pisania wszystkiego od nowa zamiast robienia stopniowych poprawek w istniejącym kodzie, kiedy mówimy o dużej skali, to eksperci tacy jak Joel Spolsky często mówią, że pisanie od nowa jest bardzo złym pomysłem. http://www.joelonsoftware.com/articles/fog0000000069.html

Offline lukiz1

  • Użytkownik

# Wrzesień 02, 2016, 09:26:45
Dla tego każdą aplikację powinno się pisać w modułach, oddzielając odpowiedzialność i relacje. Tak by nie trzeba było zmieniać wszystkiego, tylko tą cześć która tego wymaga. Zawsze jest te "ale" wiec Elastyczność = Mniejsza wydajność (choć nie zawsze widoczna)

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Wrzesień 02, 2016, 11:38:24
Ja myślę i myślę aż wymyślę. Rysowanie i rozpisywanie mi nie pomaga natomiast ma sens jeżeli jest to praca w grupie

Offline slowbro

  • Użytkownik

# Wrzesień 04, 2016, 01:17:28
Przy dużych projektach systemów biznesowych normalną rzeczą jest najpierw analiza wykonywana przez analityka, który spisuje dokument analityczny: przypadki użycia, model dziedziny, interfejsy, algorytmy, ekrany, walidacje Potem do tego siada architekt i robi projekt jak poszczególne funkcjonalności będą zrealizowane w systemie. Tworzenie systemu informatycznego jest normalną pracą inżynierską jak budowa samochodu czy domu. Można to także robić to bez projektowania tylko po co.