reklama

Vývoj krabicového projektu - tipy pro začátek

Peter

Vývoj krabicového projektu - tipy pro začátek
« kdy: 16. 02. 2019, 20:10:30 »
Ahojte, chystame jeden projekt, ktory bude najskor v prezentacnej faze, na ktoru chceme nalakat zakaznika. Ako mi bolo poradene v inom vlakne, pri novej firme bez referencii je lepsie prezentovat sa nejakou betaverziou ktora sa neskor upravi podla poziadaviek. Tam smeruje aj moja otazka, akym sposobom taky projekt vyvijat? Spravit zakladny prototyp, a od neho sa budu vytvarat v gite nove branche, a postupne modifikovat? Alebo spravit nejake moduly ktore by mali byt lahko nahraditelne inymi?

Povedzme ze istu predstavu ako by to mohlo vyzerat mame my, no zakaznik povie, ze v domenovom modele mu chyba taky a taky model, a bude treba zmenit aj nejaku tu logiku aplikacie. Ako to navrhnut tak, aby takeho zmeny sli co najjednoduchsie zapracovat? Vdaka za kazdu radu.
« Poslední změna: 18. 02. 2019, 10:28:03 od Petr Krčmář »

reklama


Re:Vyvoj krabicoveho projektu - tipy na zaciatok
« Odpověď #1 kdy: 16. 02. 2019, 20:36:38 »
Architektur si muzes vymyslet milion.
podle toho budes i pracovat s repozitari.

Peter

Re:Vyvoj krabicoveho projektu - tipy na zaciatok
« Odpověď #2 kdy: 16. 02. 2019, 20:57:07 »
Architektur si muzes vymyslet milion.
podle toho budes i pracovat s repozitari.

to ano, ale ak existuje overeny a casto vyuzivany postup, nerad by som vymyslal koleso.

btw. neviete ako sa po anglicky vola takyto typ software, aby som si mohol dohladat dalsie info? Dakujem

Re:Vyvoj krabicoveho projektu - tipy na zaciatok
« Odpověď #3 kdy: 16. 02. 2019, 21:39:43 »
Samostatny proces gui, sada serveru co spolu komunikuji, nebo aplikace nacitajici moduly jako dll/so, nebo microservices,  nebo monolitni program.

RDa

  • *****
  • 659
    • Zobrazit profil
    • E-mail
Re:Vyvoj krabicoveho projektu - tipy na zaciatok
« Odpověď #4 kdy: 16. 02. 2019, 22:36:03 »
Podle me staci, kdyz oddelis datovy model a procesni model. Takze kdyz prijde pozadavek ke zmene v nektere casti, tak to neovlivni nijak kriticky hromadu kodu. Pro uplne novy produkt je pak dobre nedelat implicitni predpoklady ze neco nejak bude - takze to muzes napsat tak, aby to v budoucnu slo rozsirovat bez nutnosti prepsani na hodne mistech.

Jinak receno - pocitej s tim, ze bude potreba pridat nove datove polozky do formulare, pripadne v procesu bude potreba udelat nejaky mezistav, se kterym si nepocital.

Predpokladam, ze delas nejaky druh informacniho systemu, takze bych Ti doporucil treba si precist neco o ERP systemech.

A jak nekdo zminoval microservices a moduly, to je dobra cesta. Rozdelit to na vice nezavislych pod-projektu, nepsat to jako monolit.


Re:Vývoj krabicového projektu - tipy pro začátek
« Odpověď #5 kdy: 18. 02. 2019, 18:25:35 »
prakticky sa neda odpovedat na otazku. pokial od zaciatkuu nevies co robis tak architektura moze vyzerat naozaj akokolvek.

najlepsia rada je - rob vzdy na mieru, nikdy neplanuj dopredu. zbav sa "what if" myslenia a aplikuj yagni.

osobne by som najskor isiel cestou mikrosluzieb a event sourcingu. to je jediny system kde mozes "plugovat" bez obmedzeni. mozes si aj spetne otestovat ako by sa spravala nejaka ficura alebo sluzba takze hned vies ci pokracovat alebo nie, pripadne co upravit a td.

problem je ze ES je VZDY na mieru a nenajdes teda ziadne realne priklady z ktorych sa mozes inspirovat, takze je to dost o pokus-omyl kym prides k niecomu co ti bude vyhovovat pre tvoje potreby a tona nacitaneho materiali a zhliadnutych prednasok na youtube.

druha vec je ze je to dost zlozite spravit dobre, ludia do ES tahaju zvyky z predoslcyh projektov(hlavne co sa tyka schem, orm, crud a spol.) a na koniec im vznikne tak akurat distribuovany crud system plny zavyslosti a deadlockov.

PS: samozrejme je rozdiel od toho ci krabicove riesenie je SaaS alebo self-hosted.

Re:Vývoj krabicového projektu - tipy pro začátek
« Odpověď #6 kdy: 20. 02. 2019, 12:28:46 »
V pripade krabicoveho softu nesouhlasim s prezentovanymi navrhy na pouziti microservices a eventu.
Tohle dava smysl u distribuovaneho/cloudoveho reseni, u karbicovky bezici na jednom stroji je to k nicemu a prinese to jenom problemy.

Osobne doporucuju  drzet modularitu na urovni zdrojaku a build procesu, spanembohem stary dobry MVC, vysledna binarka muze byt klidne monolit.
Tedy pristup Spring Bootu - ktery modularizuje pomoci IoT a maven builderu, pricemz vysledkem je treba 100 MB "monoliticky" FAT JAR. Nebo Golang, ktery vybleje obri EXE soubor.
V pripade krabicoveho softu zajima modularita developery, end-userovi je to jedno a naopak z DevOps pohledu je jednodussi spravovat a deployovat jeden tucny JAR/EXE, nez se mrcasit s konfiguraci mnoha kooperujicich modulu.

Uz jsem videl par modularnich reseni, jejichz devops zprovozneni byl tak sileny pain, ze ve vysledku se to distribuovalo jako VMWare appliance.

RDa

  • *****
  • 659
    • Zobrazit profil
    • E-mail
Re:Vývoj krabicového projektu - tipy pro začátek
« Odpověď #7 kdy: 20. 02. 2019, 21:12:45 »
najlepsia rada je - rob vzdy na mieru, nikdy neplanuj dopredu. zbav sa "what if" myslenia a aplikuj yagni.

Tohle neni rada ale cesta do pekel. Takove smysleni ma smysl jen v embedded sw kde se hraje za co nejznisi vyrobni cenu hardware protoze je vsechno vyrabeno v obrich mnozstvich a dava to smysl.

Pristup s neomezovanim se na miru se mi vzdy vyplatil pro naslednou udrzbu nebo pridavani novych veci. Oproti tomu kolega co tohle flakal a postupoval podle neceho podobneho vasi rade mel u kazdeho noveho pozadavku problem - samozrejme nikdy se kod neprepsal znova a stal se z toho desny neudrzovatelny bordel. Takze takhle ne, panove :-)

wajta

Re:Vývoj krabicového projektu - tipy pro začátek
« Odpověď #8 kdy: 22. 02. 2019, 09:23:29 »
Hned na zacatku tazatel uvadi, ze predstavu jak bude sw vypadat ma spis on a ne zakaznik.
I kdyz chce vyvijet krabicovy sw, dela to na me dojem, ze se jedna spis o zakazkovou vec, ktera by se eventuelne dala nabidnout i nekomu jinemu.
V takovem pripade by mel ale vedet predevsim zakaznik co chce a dodavatel ho muze pripadne nejak usmernovat, jinak to skonci spatne.
Pokud potrebujete presto neco rychle vytvorit a odprezentovat, zameril bych se vyhradne na to co zakaznik oceni, cili nejaka funkcnost, pripadne libive GUI, ale urcite bych se nezdrzoval architekturou, protoze to co zakaznikovi predvedete a to co mu nakonec prodate bude na hony vzdalene od původního navrhu, takze verzi, na ktere zacnete pracovat po "podani ruky" nebo sepsanim slouvy budete delat na zelene louce.
Takto si podle meho nazoru usetrite vyznamne mnozstvi prostredku a zakaznikovi cas s cekanim.

 

reklama