- Motorola Edge 50 Fusion - jó fogás
- iPhone topik
- Samsung Galaxy Watch7 - kötelező kör
- Bemutatkozott a Poco X7 és X7 Pro
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Android alkalmazások - szoftver kibeszélő topik
- Redmi Note 10S - egy a sok közül
- Itt egy pár fotó az iPhone 17 sorozatról
- Több újítással támad a Xiaomi Redmi 3s
- Garmin Venu X1 - vékony, virtuóz, váltságíjas
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
válasz
ArchElf
#5303
üzenetére
Esetleg el lehet nevezni "_OLD" utótaggal a régit. Úgyis csak egyet és a legfrissebbet kell a hatóság felé küldeni, ha kell. A válasz sima bullshit - egyszerűen nem akarják megcsinálni és így terelnek. Nem a fájlelnevezés volt a kérdés, hanem az, hogy megoldható-e, hogy ne törölje. A válasz: persze. Ennyi.
-
#5276
stevve
veterán
Sk8erPeter
#5272
válasz
Sk8erPeter
#5272
üzenetére
A refaktorálás jó dolog, de tudni kell abbahagyni, mert a végén sosem leszel kész vele.
Én is ismerem az UML-t és ha kérik, használom is(projektvezetők sokszor kérnek legalább sequence diagramot, használati esetet). Aki használja, biztosan előnyére használja, nem hobbiból. Viszont egy projektbe belekényszeríteni, időt, erőforrást pazarolni rá, azt nem szeretem.
Ahogy cucka is írja, egyre többen vannak, akik az agilis fejlesztés felé hajlanak és nem a vízesés hülyeségei felé, így az UML is kezd az ügyfél és a projektvezető, rendszertervező közötti kommunikáció irányába eltolódni. Természetesen egy utólag generált class diagram mindig jól jön, főleg ismeretlen kódnál.
A patternekről hasonlóan vélekedek, mint cucka. Ezek nem kőbe vésett dolgok, ráadásul sok már obsolate is a GOF-ból, ami mellé viszont számtalan érkezett az idők során. Én leginkább példák alapján tudom megjegyezni ezeket, de ez egyéni dolog.
Sok suliban már tanítják legalább, de az nem túl hasznos, hogy vizsgán fejből kell tudni az UML-t, holott a diák még egy dekorátort nem írt meg. Mondjuk ez nem az UML hibája. Persze vannak alapvető elvek is a minták mellett, mint a DRY, a DIP vagy a SOLID, amiket jó megfontolni és jó volna oktatni.Amúgy mindenkinek köszi, hogy ezt ilyen jól meg tudjuk beszélni.
Nagyon jó több nézőpontot látni. 
-
#5269
stevve
veterán
Sk8erPeter
#5268
válasz
Sk8erPeter
#5268
üzenetére
Nem, én személy szerint továbbra sem használom, csak helyeseltem, hogy érteni hozzá hasznos, de az ideális eset, amikor egy megbeszélésen mindenki egyből érti az UML-t, amit felvázolunk, még nem állt elő eddigi pályafutásom során, viszont kis skiccek, sémák alapján mindent el lehet magyarázni.
Egy bonyolult rendszernél meg inkább káosz lesz belőle, meg pókháló.
-
-
Igen, bár én ezt elvont formában értettem.
A kódból generált XML doksiknak még kevesebb értelmét látom, mint a többinek. Én úgy értettem, hogy a kód fejlesztőknek szól és úgy kell megírni (komment nélkül), hogy abban el lehessen igazodni, jól lehessen olvasni. Ehhez kellenek olyan szakik, akik nem csak működő, de olvasható kódot is tudnak produkálni. Jól felépített, lazán csatolt, stb."Itt már nem biztos, hogy az automatikusan generált osztálydiagram elég, mert az nem fog semmit jelenteni a többi fejlesztő számára a lib használatát illetően. "
Ebben igazad van, ez tényleg kivétel, itt nincs mit tenni, valahogy le kell írni.
A különböző UML diagramokat valóban tudnia kell olvasni egy fejlesztőnek, mert lehet rá szükség, Ezt ki is felejtettem az előbb. Jó is, hogy írtad.
"Ami igazából a mondanivalóm, az az , hogy az UML teljesen alkalmas ezen megbeszélések alkalmával információátadásra, ideiglenes dokumentációként."
Abszolút így van. Ideális esetben mindenki érti és könnyű így megbeszélni, hogy közben táblán, bárhol rajzolgatunk. Csak sajnos sokszor a jelmagyarázattal kell kezdeni, ami elég időrabló.
A dekompozíciós részben is egyet értek, az iterációs, de még inkább az agilis fejlesztés is végül úgyis visszatér az adatokhoz, de ha eleve aspektus orientáltan kezdünk hozzá, akkor hamarabb lesz bemutatható funkció halmaz, mint az első körös csak tervezéssel. Sajnos itthon ez nem elterjedt még sok helyen.
-
Teljesen érthető álláspont. Jó néha a nézeteket ütköztetni, mert abból lehet tanulni.
Én sem 1-2 fős csapatokról beszéltem, bár ez nem jött le abból, amit írtam. Én a következőket alkalmazom - természetesen úgy, hogy ma Magyarországon nem gyakorlat a vízeséstől eltérő projektvezetés, hiszen legtöbbször előre rögzített doksikért fizetnek, azok jelentik az első mérföldköveket és azokat lobogtatják másfél évvel később is bőszen.
"Persze a dokumentáció mennyiségének növekedésével a szoftverfejlesztés időtartama kitolódik."
Ezért látom én úgy, hogy a minimális jelenthet 0 közeli állapotot is ezeknél, vagyis a kód maga a dokumentáció. Ezt a fenti modell tükrében nem lehet kivitelezni, ám sok doksi gyártható utólag, menet közben is, generálva. A lényeg, minimális legyen a fejlesztők által dokumentálásra fordított idő, így az UML jó része is kimarad a fejlesztőknek - ez legyen a projektvezető vagy rendszerszervező.
Olyan projektnél, ahol modulokat építünk egybe, írtam is, hogy a kapcsolódási pontokhoz kell valamiféle támpont, az pedig lehet UML is akár. Minimális áldozat, de előre legyártani ezt is éppoly veszélyes, mint egy rendszertervet. Jobb pár meetinget tartani a többi fejlesztővel és kódba belemenni, esetleg már bemutatható, legalább mock interfészekről beszélni. Rengeteg példa van arra, hogy a rendszer változott, csak a doksikban nem vezették át.
A használati eset és az activity diagramm legyen a projektvezető dolga szintén. Nem fogom ezzel a fejlesztőket terhelni, mert nekik ehhez nem sok közük van közvetlenül. Ez max. arra jó, hogy csekkolni lehessen, hogy a feladatok hol tartanak, mi van még, de erre a prototípusok, release-ek is megfelelnek és abból legalább lát is valamit az ügyfél.
Class és szekvencia utólag generálandó szerintem, különben erőforrást köt le huzamosabban, ami nem jó. Igen, erre gondoltam, hogy ez lényegesen eltérhet a kiindulási állapottól. Szerintem több modul esetén is simán működhetnek a mock interfészek vagy a sűrű release-ek. Ezek specifikációját viszont nem feltétlenül szükséges UML-ben megadni.
"A diagramok egy része az implementáció megkezdése előtt születik, más részük közben, megint más részük utólag. Természetesen elkerülhetetlen a változás, mert nem lehet minden eshetőséget lefedni a fejlesztés során. "
Én is így látom. Előre nem lehet kőbe vésni még nem látható dolgokat. A fejlesztő, architect nem jós.
"Sajnos rossz gyakorlat az, hogy a dokumentációt fejlesztés után készítik el, és a fejlesztés gyakorlatilag ad-hoc módon történik: a fejlesztők egymás között ledumálják ki mit csinál, aztán probléma van, amikor össze kell hegeszteni a dolgot egy egésszé."
Nem lehet egyenlőséget tenni az ad-hoc fejlesztés és az utólag dokumentálás között. Ismét megemlítem, hogy a legjobb dokumentáció maga a kód - abban nincs és nem is lehet összebeszélés, háttéralku. Ilyet egyébként sem lehet megengedni, de egy class diagram mégis akkor lehet teljes, ha a kész/félkész kódból generáljuk.
Amit itt írsz, pont a kis csapatokra vonatkozik (leosztják egymás között a feladatokat, megy a susmus, stb.), de nagyobbaknál is jól működhet az, hogy nem egy bizonytalan és régi rendszerterv és UML-ek alapján fejlesztenek, amiket nem tartanak karban, hanem az igények szerint és a haladást maga a termék jelenti. Így az ügyfél is hamarabb lát belőle valamit és így jobban is tud gondolkodni, mint ábrák alapján.
"El kell fogadni, hogy a dokumentáció a fejlesztés szerves része, és mint említettem, nagyobb projekteknél a kommunikáció folyamatossága érdekében elkerülhetetlen rossz vagy éppen jó."
A régi szemlélet szerint igen. A vízesés modellben máshogy el sem lehet képzelni a fejlesztést, de maga a modell eleve csak rossz példaként lett régen is megemlítve, amikor felkapták. Ha a levelezést nem tekintjük dokumentációnak, akkor a kommunikációhoz nincs szükség rendszertervre, UML-re és egyebekre. Nem kell kizárni, mert lehet, hogy azt valaki annyira vágja, hogy azonnal lát mindent, de sok esetben a kód, az alkalmazás sokkal hasznosabb forrás.
Nem mondom, hogy ez a szuper és ultimate módszer, meg így kell mindenkinek, de én így látom. Az agilis és egyszerű, letisztult fejlesztést részesítem előnyben és ez nem csak idea.
Egy példa még a végére:
Régi vesszőparipám az, hogy sok projekt az adatbázis megtervezésével indul, holott ez a rész 90% eséllyel szinte azonnal megváltozik. Ha a "dekompzíció" és a funkciók mentén haladunk, akkor elemi feladatokkal gyorsabban lehet bemutatható alkalmazást készíteni, mint a legnagyobb falattal szöszmötölni.Természetesen ehhez befogadó projektvezetés és ügyfél is kell.
Hű, de hosszú lett. bocs.
-
#5249
stevve
veterán
Sk8erPeter
#5247
válasz
Sk8erPeter
#5247
üzenetére
UML: Több nézet van. az én szempontom az, hogy az UML arra jó, hogy utólag - vagy előre, de fenntartásokkal - olyanok, akik nem értenek a kódhoz (rendszerszervezők, projektvezetők) láthassák, milyen folyamatok, esetek, stb. fordulhatnak elő az alkalmazásban.
Egy fejlesztőnek az UML lényegtelen. Ha előre megrajzolt, akkor úgyis változik, ha meg utólag generálom, azt nem magamnak teszem.
Éppen ezért szerintem egy fejlesztőnek igen kevés haszna származik az UML-ek olvasgatásából. (persze ha egy nagy rendszer csatlakozási pontjait, szervereket akarok látni, az más, most a kódra, alkalmazásra értek mindent). Én így látom. Sőt! Kicsit tovább is megyek és azt mondom, nem adat és adatszerkezet alapú szemléletben kellene már gondolkodni. Ha én egy másik fejlesztővel beszélek, rajzolunk ugyan, de nem UML-t, hanem dobozkákat, folyamatokat, ahogyan az a kódban vagy felületen meg is lesz valósítva. Ebben az UML inkább hátráltatna, mint egy gyors skiccelés. A gyakorlat nálam nem igazolja az UML vélt erejét. A sikerélmény szükséges az érdeklődés fenntartásához, de ha rögtön nekiáll valaki superclassokat írni és később akarja megtanulni az elveket, nehezebb lesz. Mellette lehet mórickázni, de ugye ismert a mondás: elmélet nélkül nincs gyakorlat és fordítva. Legalábbis akkor, ha az ember komolyan foglalkozik valamivel. Garázs szintű fejlesztéshez, meg számológéphez nem kellenek nagyon elvek, de nem szabad ott ragadni.
-
-
válasz
Geriman25
#5231
üzenetére
Milyen nyelv érdekel?
Ha C#, akkor íme pár könyv:
Head First C#
Pro C# 2010 and the .NET 4 Platform
C# 4.0 in a Nutshell
Essential C# 4.0De végül is ami fontos, hogy kicsit először csak olvass a .NET működéséről és az alapokról, az OO működéséről, közben pár móricka példával el lehet kezdeni a gyakorlást. Ha már néhány dolog jól megy, akkor irány a net, ott aztán ezer és ezer példa van, de azért óvatosan velük, mert nem mind jó kód!
-
Igen, a 24 órás könyvek nem alkalmasak arra, amit a címük sugall, főleg nem 24 óra alatt.
Geriman25:
Érdemes egyébként még a tanulás elején ilyen varázsszavakra rákeresni, mint principle, GOF, design pattern, composition és kicsit elméletben elsajátítani néhány nézetet. Persze ezek egyike sincs kőbe vésve, az agilitás és az egyszerűség legyen mindig szem előtt. -
válasz
tamas60
#5192
üzenetére
UML-t írtam vagy nem az az ismétlés tárgya (mármint elírás)? Az UML az a fajta dokumentáció, amiben platformfüggetlenül lehet folyamatokat, használati eseteket, stb. szemléltetni viszonylag könnyen értelmezhető módon. A rendszerszervezők és projektvezetők szeretik doksikba betenni helykitöltés miatt és az ügyfelet ezzel vakítani, de a jelentősége szerencsére csökken a fejlesztésben.
-
válasz
tamas60
#5188
üzenetére
Én fejlesztőként csak azt tudom mondani, hogy a megrendelőnek csupán elképzelései vannak. Van, aki ért esetleg hozzá és tudja, hogy miben és hogyan - ezek sajnos legtöbbször inkább csak szakbarbárok, akinek azt nehezebb elmagyarázni, miért nem lát jól ezt vagy azt, de a megrendelők többsége nem tudja sem a módszert, sem a technológiát, sokszor a funkcionalitásban is az első pár release után jut eszébe még több dolog. Ezért kell kommunikálni és ezért kell agilis módszertanokat használni.
Eddigi pályafutásom során az előre rögzített, megbeszélt rendszerek, az elkészült rendszerterv (amiből a megrendelő megint semmit nem ért, mint ahogy UML-t se általában) és szerződések merevsége ellenére is sokszor nagy mértékben változtak az átadható állapot eléréséig. Ergo, az ügyfél nem tudja, mit akar, de van elképzelése, amiről meg kell kérdezni. Én így látom.
Csak azért, mert ő a megrendelő és kvázi ő adja a pénzt hó elején, nem szabad mindent benyelni, amit mond, hanem érvekkel megmutatni, ha esetleg valahol jobbat is ki lehet hozni - már ha olyan, hogy nyitott valamennyire, de ez már más kérdés.
-
-
Dolgozni nem éri meg elkezdeni, akkor már inkább OKJ, de azok ugyebár 2 évesek általában. Én például annak idején úgy csináltam, hogy elkezdtem az OKJ-s programozós képzést, de első évben felvételiztem és felvettek, úgyhogy azt ott is hagytam. A lényeg, hogy ne ess ki a gyakorlatból, meg a suliból... szóval se punnyadás (
), se valamilyen helyettesítő meló - szerintem.A Gábor Dénest meg én kerülném... csak pénzkidobás.
-
Attól függ...
Az MVVM szemlélet nagyon hasznos, csak sajnos itthon valahogy a principle és design pattern alapú fejlesztés helyett a garázs fejlesztés megy. Mindkettő használható, de WPF-ben könnyebb látványos alkalmazást írni, mint WinForms-ban, nem beszélve a data binding-ról, az MVVM előnyeiről és még kb. ezer dologról.
-
"Kösz a sok hasznos választ"
Ennyi hsz-szel ne legyél amatőr...
Nem vagyok java fronton otthon, de talán le kellene zárni a kapcsolatot használat után és nem foglalna semmit - vagy legalábbis nem ezer évig nyitva tartani. Megnyit, crud, get, stb. és bezár. Sehol nem látok lezárást, a várakoztatás meg ezek talán arra jó, hogy lejárjon a session. Ha tévedek, akkor ez van.
-
válasz
ArchElf
#4786
üzenetére
A legegyszerűbb egy tábla, ahol tároljuk a csomag metaadatait, valamint idegen kulcsokkal a csomagban szereplő termékeket és egy árat, ami a csomagra jellemző. Mivel nyilvánvalóan karban kell tartani a csomagokat, ez a legjobb, mert csak össze kell kattintgatni a csomagot felületen és beárazni.
-
Ezt jó hallani. Ez egy nagyon jó példa a refaktorálás pozitív hatásaira. Sajnos vállalati keretek között sokszor nem hagynak időt ilyesmire, pedig kellene.
Akkor csak simán másik kön 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Gigabyte RTX 2070 8GB / Beszámítás OK!
- AKCIÓ!!! GAMER PC: i7-12700KF +RX 9060XT/9070/9070XT +16-64GB DDR4! GAR/SZÁMLA!!!
- Manli RTX 3070 8GB - 13 hónap garancia / Beszámítás OK!
- AKCIÓ!!! DDR5 GAMER PC: RYZEN 7 8700F/9700X/9800X3D +RX 9060XT/9070/9070XT +16-64GB DDR5! GAR/SZÁMLA
- Gainward RTX 2060 Pegasus 6GB Csavarmatricás! / Beszámítás OK!
- Bomba ár! Dell Latitude 7390 2in1 - i7-8G I 16GB I 256SSD I 13,3"FHD Touch I HDMI I Cam I W11 I Gar
- Lenovo ThinkPad X270 (16) - i5-7300U, 16GB, 512GB SSD, 12" FULL HD
- Ultimate előfizetés új fiókra akár 2105 Ft/hó áron! Azonnali, automatizált aktiválással, csak Nálam!
- Újszerű Apple Macbook Air 15,3" M3 8C CPU/10C GPU/16GB/256GB-(MC9E4MG/A) Ezüst -3 év gari
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
Állásajánlatok
Cég: FOTC
Város: Budapest