• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Jak prawidłowo podejść do tworzenia dużego programu pod względem obiektowym?

Object Storage Arubacloud
+1 głos
183 wizyt
pytanie zadane 5 czerwca 2020 w C i C++ przez LuQ232 Mądrala (7,200 p.)
Cześć!

Chciałbym was zapytać o radę w jaki sposób podchodzić do tworzenia większej aplikacji. Mam sporą wiedzę odnośnie samego języka jednak mam problem z ułożeniem sobie w głowie jak program ma się łączyć w całość. Co robicie na start zaczynając pracę nad większym programem składającym sie z kilku / kilkudziesięciu klas, bibliotek graficznych itp.?  Tworzycie diagramy UML czy "lecicie na żywioł"?  Jak prawidłowo przemyśleć podział na klasy, żeby potem udało się wszystko połączyć oraz żeby program był łatwy w rozbudowie? Gdzie mogę o tym poczytać? Istnieją jakieś książki poruszające ten temat?

Jeżeli ktoś z was na co dzień pracuje jako programista przy dużym projekcie to jak to wygląda? Kto układa takie plany działania całego programu i jak to wygląda ze strony osoby piszącej kod?

 

Dajcie wszystkie protipy odnośnie poruszonego przeze mnie tematu.

Dziękuję za poświęcony czas!
komentarz 5 czerwca 2020 przez DragonCoder Nałogowiec (36,500 p.)
Teiretycznie po to ma sie dokumentacje, albo bardziej wymagania od klienta, a za reszte jak co k gdzie jestes odpowiedzialny ty. Zeby sie nie pogubic odnosnie encjii/zwiszkow mirdzy klasami oraz co powinno zostac zsimplementowane, wsrto raczej zrobic diagram klas, diagram funkcjonalnosci, use case
komentarz 5 czerwca 2020 przez LuQ232 Mądrala (7,200 p.)
@DragonCoder, Rozumiem. A polecisz może jakieś źródła dla  prawidłowego tworzenia diagramów i use case?
komentarz 5 czerwca 2020 przez DragonCoder Nałogowiec (36,500 p.)
Niestety nie, bo w sql o tym mialem. Ale ja uzywalem po prpstu Wikipedii i DIA

1 odpowiedź

+2 głosów
odpowiedź 6 czerwca 2020 przez DragonCoder Nałogowiec (36,500 p.)
wybrane 6 czerwca 2020 przez LuQ232
 
Najlepsza

Moze bardziej rozlegly wywod, ale na poziomie szkolnym, czyli jak szkola przedstawia tworzenie software w firmach oraz jakich narzedzi przy ucza do tego itd (Niemcy). Uwaga pojawia sie pojecia po niemiecku, bo nie mam pojecia, jak nazywaja sie po polsku a tlumaczenie 1:1 moze byc dziwne. Tresc bazuje na prostych modelach tworzenia software, w tym przypadku waterfall model, oprocz tego podam link, do innego modelu, ktorym w swojej formie jest duzo dokladniejszy, ale przez to trzeba poswiecic tez wiecej czasu.

Calosc opiera sie o tak zwany Waterfall model, w ktorym wystepuja najczesciej 4 fazy, az do oddania softu, ale ten 6 fazowy jest lepszy: (angielkie nazwy)

System engineering, analysis, design, coding, testing, maintenance

https://en.wikipedia.org/wiki/Waterfall_model

Zacznij od 2 prostych pojec:

  • #systemengineering#
    • Lastenheft: czyli tak zwana specyfikacja klienta, w ktorej opisuje co dokladnie chce miec w swoim projekcie (funkcjonalnosci, moze jakies gui juz czesciowo stworzene, moze chce ekstra dokumentacje tylko dla usera, jakies systemy zabezpieczen itd itd.)
    • kalkulacja projektowa (kosztorys itd) 
    • work breakdown structure
    • netzplan (jest to lista zadan, ktora ma okreslony czas wykonania, dzieki czemu mozna ustalic kiedy teoretycznie powinnien skonczyc sie projekt, jakie zadania mozna wykonac rownolegle w czasie itd). To sa te nazwazniejsze, cala resta jak lista terminow itp, mozna odczytac z netzplan.
    • w przypadku gier dalbym tutaj jeszcze GDD
  • #analysis#
    • Pflichtenheft: to takze specyfikacja, ale od strony firma, jest wiec to dokument w ktorym jest opisane jakie elementy softu i jakimi metodami chce stworzyc je firma, oraz czy pewne czesci sytsemu moga zostac wgl stworzone tak, jak wymaga tego klient, oprocz tego jest podawany tez szacowany czas pracy itd. I ogolnie to jest dokument, ktory jest podstawa umowy miedzy klientemm, a  firma i w razie czego, gdybys cos bylo nie tak z programem, brakowalo czegos, a jest w tym dokumencie, to klient moze wytoczyc proces itd. Ale mniejsza z tym.
    • Model produktu: tutaj moga to byc jakies modele CAD, jakies plany plytek PCB itd, wymienic mozna sporo
    • Model GUI
    • i czasami juz powstaje istrukcja obslugii odnosnie programu, aczkolwiek nie jest to najlpeszy pomysl na poczatek, tzn mozna stworzyc i pozniej edytowac, zeby zobaczyc co sie zmienilo itd.
  • #Design#
    • UML: doslownie kazdy rodzaj diagramu, use-case, life-diagram, class-diagram, table-diagram, entity relationship model itd. Mozna tu wymienic wiele rzeczy, wszytsko zalezy co sie robi, innych diaramow uzyjesz w przypadku bazy danych, innych gdy tej bazy danych w projekcie nie ma, bo wtedy zrezygnujesz z table model oraz ERM. Wiec tutaj musialbys zglebic troche temat. To czego na pewno bys nie ominal to use-case, jezeli robisz jakis program, bo ona pokazuje interakcje systemu, czy uzytkownika z pewnymi funkcjonalnosciami systemu lub ze wszystkimi. Tutaj mam DIA, ale pewnie jakies edytory online bylyby lepsze, jezeli jezdzisz lub chcesz edytwac cos na tablecie itd. Lista:
      • class diagram
      • component diagram,
      • deployment diagram
      • object diagram
      • package diagram
      • use case
      • activity
      • state machine
      • sequence/life
      • interaction overwiev
      • communication
      • jest ich pewnie wiecej, wiec najlepiej jak wejdziesz w standard UML i zobaczysz pelna liste, to sa akurat te ktorych ja musialem uzywac
    • Nassi-Shneiderman-diagram, jak dla mnie najbardziej wkurzajace diagramy ze wszytskich, poniewaz nie spotkalem dobrego i fajnego softu do nich. Ale slyszalem, ze jest soft, ktory potrafi nawet dobrze wygenerowac kod z nich, ale wtedy wszytsko musi byc piko bello zrobione, kazdy znak itd zgodnie ze standardm. Ja akurat pod reka mamhttps://structorizer.fisch.lu/
  • #Coding#
    • No i tutaj jest juz impelemntacja calego projektu bazuja glownie na tych diagramach, bo po to je stworzyles, zeby nie musiec myslec podczas kodzenia, czy to ma byc tak, czy siak, czy owak. MAsz digram, widzisz, ze to i to dziala tak czy tak i tyle.
    • Pokusze sie o stwierdzenie, ze tutaj tez moze powstac dokumentacja, ale odnosnie opisu funkcji (parametry jakie przcjmuja, odbjasnienei, kiedy sie jej uzywa itd) i pozniej jest to pewnie klejone w calosc razem z diagramami, ale o tym pozniej.
  • #Testing#
    • Blackbox test
    • Whitebox test
  • #maintenance#
    • Oddanie gotowego programu + pielegnacja

Odnosnie samego podejscia i czy z takim sie spotkasz, to szczerze watpie :D wiele osob, ktore pracuje nie widzialo w pracy na oczy tych diagramow z UML. Jest to raczej mocno techniczne podejscie, ktore zabiera mnostwo czasu, bo stworzenie samych diagramow, zabiera sporo czasu. Oczywiscie w tym przypadku dokumentacja jest bardzo duza i dokladna, ale czy zawsze jest to potrzebne tego nie wiem. Oprocz tego na dole zostawiam link do innego modelu, czyli V-Modell, ktory jest rozwinieta wersja Waterfall model i jest na 100% lepszy do implementacji oraz umozliwia skoki miedzy fazami w projekcie.

https://en.wikipedia.org/wiki/V-Model

komentarz 6 czerwca 2020 przez LuQ232 Mądrala (7,200 p.)
Bardzo dziękuję za tak rozległą wypowiedź. Idę po kawe i zabieram się do czytania :)

Podobne pytania

+1 głos
2 odpowiedzi 312 wizyt
pytanie zadane 9 kwietnia 2016 w Rozwój zawodowy, nauka, praca przez Silverwind Użytkownik (730 p.)
0 głosów
0 odpowiedzi 190 wizyt
pytanie zadane 6 stycznia 2017 w Ogłoszenia, zlecenia przez VitGryfny Użytkownik (620 p.)
0 głosów
1 odpowiedź 2,056 wizyt
pytanie zadane 5 czerwca 2016 w Rozwój zawodowy, nauka, praca przez tomo9300 Nowicjusz (140 p.)

92,762 zapytań

141,686 odpowiedzi

320,499 komentarzy

62,106 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...