- A Microsoft feltalálta az olcsó AI-t
- Autodesk - Revit
- Közel 1 billió dollárt vesztettek a big tech óriásai
- Megrendszabályozza a Pornhubot az EU
- Milyen program, ami...?
- Musk szerint az AI már jövőre okosabb lesz a legokosabb embernél
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Amazon Prime Video
- Kaspersky Antivirus és Internet Security Fórum
- Az MSI RadiX AXE6600 tesztje – router, játékosoknak
-
IT café
Új hozzászólás Aktív témák
-
modder
aktív tag
Hali,
Az UML előnye nem is az 1-2 fős projekteknél ütközik ki, ahol a fejlesztő egy személyben a business analyst, az architect, a manager, a tesztelő is. Bár kifejezetten hasznos.
Amikor több: 5-10-20 fős fejlesztői csapatot kell koordinálni, akkor bizony a fejlesztési módszertanokkal együtt az UML-t is használni kell. Ezek együttesen segítenek mind a szoftver, mind a szoftverfejlesztés minőségét javítani. Persze a dokumentáció mennyiségének növekedésével a szoftverfejlesztés időtartama kitolódik.
Néhány példa, hogy mikor előnyös:
UML activity diagram: Egy nagyobb cégnél a fejlesztők nem találkoznak az ügyféllel közvetlenül, de tudniuk kell mit várnak el a szoftvertől. Ennek lekommunikálásának egyik leghatékonyabb módja pl. egy UML activity diagram.
UML use-case diagram: Az UML activity diagramot az ügyfél beszámolója alapján elkészített use-case-ből generálják. Máris van egy dokumentum, amihez tudnak a fejlesztők fordulni, ha kérdésük van a program flow-val kapcsolatban, és nem kell a BA-t csesztetni.
UML class diagram: szerintem erre gondoltál, amikor azt mondtad, hogy ez úgyis változik, hiszen a belső struktúra az, amit először nem lehet a legjobban eltalálni. Ugyanakkor egy nagyobb projektben szükség van rá interfészek deklarálásához, mert különböző komponenseket különböző fejlesztők készítenek el, tudniuk kell, hogyan csatlakoznak ezek egymáshoz.
UML szekvenciadiagram: Ennek előfeltétele az UML class diagram, megmondja, hogy a komponensek vagy osztályok hogyan kommunikálnak egymással. Ez egy specifikáció a tesztelők számára, akik nem ismerik teljes mértékben a szoftver belső működését, de felismerik, ha az üzenetváltások nem a specifikáció szerint alakulnak.
UML kommunikációs diagram: Más fejlesztők által létrehozott komponensek hogyan kommunikálnak majd egymással. Ennek szerepe lehet architektúra tervezésnél, és mérvadó lehet a kommunikáló komponensek interfészeinek kialakításánál.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. 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é. Erről legtöbbször nem a fejlesztő tehet, mert a határidő mindig valamikor tegnap.
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 példákból pedig látható, hogysajnosa fejlesztőnek is részesülnie kell belőle....szerintem
-
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.
[ Szerkesztve ]
-
Gülredy
tag
Sziasztok!
Egy olyan kezdőnek, aki már tanult programozási nyelveket, (c,c++, c#, java, delphi, assemly, php/mysql) de mégsem "mestere" egyiknek sem, milyen nyelvet ajánlanátok megtanulásra?
A problémám oka az, hogy félévente új programnyelvet tanultunk, így eléggé összekeveredtek bennem a dolgok.
A célom az lenne hogy egy olyan nyelvet megtanuljak, ami eléggé keresett munkavállalás szempontjából, de viszont nem túl szerteágazó, és nehéz! Értem ez alatt, hogy elkezdtem a java-t újratanulni, erre minél többet olvasok róla, annál többféle van: JavaSE Java EE Java Applet Java script stb... és ahogy nézegettem majdhogynem mindegyik különbözik egymástól, ha nem is teljesen, de részlegesen igen, ami nehezebbé teszi, de javítsatok ki ha nem így van, és csak én értelmeztem félre az egészet! Ráadásul a könyvek nagy része is egyszerre többel is foglalkozik, ami még jobban megnehezíti a dolgom.Ahogy nézegettem állások között, a legelterjedtebb amit keresnek c, c++ és a Java meg a php.
Szóval ti mit ajánlotok, melyikkel kezdjem?
Előre is elnézést a furcsa kérdésért!
-
modder
aktív tag
Igaz, hogy a kód lehet jó dokumentáció, de ehhez a kód jól dokumentáltsága is szükséges, amiből aztán jó dokumentáció generálható. Nem Javadoc, mert az nem mutat semmit, de pl. Doxygen (vagy fizetős vállalati eszközök). -- ezt csak megjegyzésben írtam, tegyük fel, hogy ez adott.
Jól kifejtetted, a teljesség igénye nélkül néhány dolog ami még eszembe jut.
Mint mondtad, különböző modulok kapcsolódási pontjához hasznos a dokumentáció. Tegyük fel, hogy egy library-t megírt egy fejlesztő, aminek a használata szükségessé válik a projekt egy előrehaladottabb fázisában. 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. ilyen esetben, akár a hivatalos fejlesztői dokumentációban is megjeleníthető legalább valami kollaborációs diagramra szükség lesz, amit a fejlesztőnek kell létrehozni. -- te is hasonlóra gondoltál?
Egy kis csoportról beszélve, akik egy modulon dolgoznak, pedig szintén nem árt, ha ismerik az UML-t. Egy megbeszélés alkalmával rögzített program flow-t lehet rögzíteni akár papírra, így az adott iterációban vissza lehet hivatkozni rá. Kvázi ez egyenlő azzal, hogy nem kell fejben tartani. Ez egy informális dokumentáció, de UML-t használva még kevesebb hibához is vezethet, mint egy "móriczkarajz"
A használati eset és az activity diagramm legyen a projektvezető dolga szintén.
Ebben igazad van, de valakinek (a szoftverfejlesztőnek) el kell tudni olvasni azt.Rengeteg példa van arra, hogy a rendszer változott, csak a doksikban nem vezették át.
Igen, sajnos a dokumentációt is karban kell tartani. Ha már automatikusan generált doksit említettem, ezt lehet a buildelési fázishoz is kötni. Viszont elvetemült öltet lenne minden iterációban újravizsgálni a dokumentációt is.Egyetértek azzal, hogy nem kell túldokumentálni mindent, és jól működik általában a szoftverfejlesztés formális és informális megbeszélések alapján. 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.
Dekompozició elve:
Minden dekompozició legvégül egy adatbázis tervhez vezet, de tényleg fölösleges az egész rendszert megtervezni adatbázis szinten az elején. Tulajdonképpen az iteratív szoftverfejlesztés pont erről szól, nem? Nem lehet úgy végigcsinálni egy szoftverfejlesztést, mint egy hidat: terv -> implementáció -> kész
-
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.
-
modder
aktív tag
válasz
Gülredy
#5256
üzenetére
Hali!
Az a baj ezzel a kérdéssel, hogy nem objektív, hanem meggyőződésből eredő válaszokat kapsz majd, ezért hogy jó nyelvet válassz magadnak meg kell fontolnod pár dolgot.
Először döntsd el, hogy milyen típusú alkalmazást szeretnél fejleszteni pl. hagyományos desktop, webes alkalmazás (website), webes kliens oldali, háttérben futó rendszerszintű programok, mobil nevezzük ezeket rétegeknek. Majdnem minden mainstream programnyelv lefedi ezeket a rétegeket, azonban a választás segít eldönteni, hogy milyen információkat keress.
Én azt ajánlom, hogy ha eldöntötted, hogy milyen réteget és programnyelvet választasz, akkor ragadj hozzá, és szerezz róla magabiztos tudást, majd mehetsz a többi rétegre is ismerkedni velük.
Áttekintés rétegenként
1) Desktop alkalmazás:
Egyértelműen C# és .NET. Azért, mert a legelterjedtebb a Windows. Olyan technológiákat használ, amiket átültetheted kapásból mobilra is, ha arra szeretnél orientálódni.
Emellett nekem még tetszik a C++-ban Qt. A Qt egy grafikus könyvtár és egy előfordító. Linuxra KDE ebben íródott, Nokia telefonokon lesz elérhető.2) Webes alkalmazás:
ASP.NET és webes technológiái, Java EE és webes technológiái, PHP, illetve szaporodik a Ruby on rails. PHP-ból sok a munka, sok a programozó is, szerintem nem fizetik meg annyira. Az első kettő közül mindegyik piacképes tudást ad, viszont rettentő sok technológia épül rájuk.3) Webes kliens:
Flash... hát nem tudom, nekem nem szimpi. Silverlight elterjedőben, keresett. Emellett egyre nagyobb tudást igényelnek a kliens oldali JavaScript könyvtárak, HTML5 ilyesmi.4) Rendszer:
c++ unix/linux alapon, windows alapon .net, c++. Emellett az operációs rendszerek nagyon átfogó ismerete, és oprendszer api kőkemény ismerete.5) Mobil:
Java: Android; .net: windows mobile; C++ Qt: nokia; Objective-C: iPhone, Ipad.6) Grafikai program:
Ha játékot akarsz írni, akkor C++ és OpenGL vagy C# és XNA.Üzleti megfontolások, mivel szakíthatsz a legtöbbet?
Szerintem Webes szerver oldali platformokkal, de sok idő beletanulni, azonban ezen a vonalon szép karriert lehet csinálni. (ASP.net, Java EE)Mivel juthatsz legkönnyebben a piacra?
Web: kliens + PHP; Manapság még android vagy iPhone fejlesztési gyakorlattal.Ez a lista a teljesség igénye nélkül született, és az én objektíven szubjektív megítélésem
-
modder
aktív tag
Nem tudom milyen a kódból generált XML doksi. Amit én használtam az a Doxygen, ami feloldja az asszociációkat a jól dokumentált Osztályok és függvények között, majd ezt egy jól érthető HTML vagy PDF formátumban kimenti osztálydiagramokkal együtt. Sőt, léteznek olyan szoftverek is, amik pusztán a kód olvasásából megértik az együttműködéseket, és az alapján generálnak diagramokat. Ezzel felváltható a kézzel megírt végleges fejlesztői dokumentáció egy része is. Nyilván az olvasható, jól dokumentált kód erény, de nem lesz ettől rendszerszinten áttekinthető.
Most mindannyian sokkal okosabbak lettünk
-
-
modder
aktív tag
Köszi
Igen, előnye a C# technológiáknak, hogy mobilra is adaptálták őket sőt, nem akarok hülyeséget mondani, de talán még iPhone-ra is lehet .net-ben fejleszteni. Nem gondoltam, de kábeltelevíziós set-top-boxokra is bizony .net-ben fejlesztenek.
Én pedig még annyit fűznék hozzá, hogy manapság sajnos egy programnyelv ismerete már nem azt jelenti, hogy bekérek a parancssorból és kiíratok. Nagyon komoly és összetett technológiákat kell ismerni a piacképes tudáshoz adott rétegen belül is. Olyanok, mint az említett WCF, WPF, vagy amit mostanában tanulgatok Java EE platformon JPA, JSF és megannyi sok csúnya 3-4 betűs mozaikszó
-
nvyktor
aktív tag
Kiegészíteném...
x nyel 24 óra alatt akkor jó, ha olyan nyelvet tanulsz, amihez hasonlóban már van tapasztalat, pl. c-php, vagy mysql-mssql. Tehát ahol az utasítások, szerkezet hasonló, csak esetleg más a szintaxis.
Tök nulláról nehéz.
Vannak olyan könyvek is, amelyek magára a gondolkodásmódra nevelnek, meg arra, hogy hogyan építsd ki a fejlesztő, tesztelő környezetedet.
Összességében minden könyv arra való, hogy alapokat adjon, egy konkrét feladatot nem lehet megoldani velük. Ötleteléshez jók.
Én is BASIC-kel kezdtem. ZX Spectrumon...
Védd a fákat! Egyél hódot...
-
nvyktor
aktív tag
válasz
Jim Tonic
#5264
üzenetére
Addig a pontig, amíg nem használsz előre definiált dolgokat, tárolt eljárásokat, miegymást alig van különbség, hiszen mindkettő SQL.
Néhány apróbb eltérés van, pl.:
MSSQL: SELECT TOP 10 oszlop FROM tabla
MySQL: SELECT oszlop FROM tabla LIMIT 10
Oracle: SELECT oszlop FROM tabla WHERE sorszam (ROWNUM) <= 10Ezekre viszont gugli barátunk 2 perc alatt választ ad.
Ha komolyabb szintű a felhasználás (tárolt eljárások, rutinok, stb.) akkor nagyobb az eltérés, érdemes előtte utána nézni.
És arra is érdemes figyelni, hogy a fejlesztő környezetedbe integrálva legyen az MSSQL. Gondolok itt arra, ha pl php alól kéne ms-t hívni, akkor a php.ini-t (is) szerkeszteni kellhet. Tehát a fejlesztés kezdetekor érdemes írni egy print "hellóvilág"; szintű programocskát, ami teszteli az adatbázis kapcsolatodat, hogy ne a fejlesztés során derüljön ki, ha valami ott nem stimmel. Sok fejtörést lehet vele megspórolni.
Védd a fákat! Egyél hódot...
-
#5268
Sk8erPeter
nagyúr
stevve
#5258
Sk8erPeter
nagyúr
"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ó."Most a végére rájöttél, hogy az UML mégsem csak egy helykitöltő baromság, ami remélhetőleg egyre kevesebb teret fog kapni a fejlesztésben?
Amúgy látom időközben modderrel regényeket írtatok, úgyhogy túl sokat nem tudok hozzátenni, úgy kiveséztétek, alapvetően modderrel értek egyet, persze Te is sok igazságot mondtál.
Sk8erPeter
-
#5269
stevve
nagyúr
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ó.
[ Szerkesztve ]
-
nvyktor
aktív tag
hmm.
Most, hogy mondod már "nagy" voltam, amikor a spectrumról áttértem c64 basic-re, ott volt egy három könyvből álló sorozatom, aminek a végére már grafikus környezetet is lehetett programozni, sprite-okkal, meg mindennel ami kellett...Húúúú emlékeztek még a sprite-okra?
Öreg vagyok.
[ Szerkesztve ]
Védd a fákat! Egyél hódot...
-
#5272
Sk8erPeter
nagyúr
stevve
#5269
Sk8erPeter
nagyúr
Szerintem akár egyetlen emberből álló munkánál is hasznos lehet az UML-ismeret.
Most ez lehet, hogy nem a legjobb példa, de én is hadd mondjak egyet. Hobbiból folyamatosan csiszolgatom egy régen elkészített honlap kódját, állandóan változtatok rajta, és röhögök a korábban megírt kódjaimon, és annál jobbat írok, aztán később majd ezen is röhögni fogok, és átalakítottam már a kódnak nagyjából 60%-át objektumorientáltra, ami eléggé segít számomra a kódom áttekinthetőségében, módosíthatóságában, stb. Viszont már kellően sok kódot írtam ahhoz, hogy kezdjem egyre nehezebben átlátni az egyes objektumok kapcsolatait, mi örököl miből, mi tartalmaz mit, mihez milyen metódus, tagváltozó, stb. tartozik, ezért egy programmal legeneráltatttam a kód alapján az UML-diagrammokat, így csomó mindenre rájöttem, hogy mit lehetne egyszerűsíteni, megváltoztatni, áthelyezni, stb. - ismétlem, UML-ábrák alapján. Ezentúl mostanában egyre gyakrabban alkalmazom azt a módszert, hogy a kódírás előtt először megpróbálok valami összedobált UML-diagrammot készíteni arról, amit épp alkotni szeretnék - ez is jelentősen leegyszerűsíti a munkámat, mert sokkal könnyebben észreveszem az esetleges koncepcionális hibákat, főleg, miután UML-diagrammokkal szemléltetve verték a fejünkbe a különböző tervezési mintákat is egyes egyetemi tárgyakból. Ha már erről van szó - a különböző tervezési minták alkalmazása esetén is szinte elkerülhetetlen szerintem az áttekinthetőség érdekében egy normális UML-diagram megalkotása a programunkban szereplő objektumok kapcsolódásáról ahhoz, hogy a megfelelő tervezési mintát rá tudjuk húzni a saját feladatunkra. A tervezési mintákat meg ugye nem hülyeségből találták ki, hanem épp a fejlesztés gyorsítása érdekében.
Mindezt azzal együtt értem, hogy nyilván az UML-diagrammok is állandóan változnak attól függően, hogy a kód épp hogy módosult. Így szerintem az UML-diagrammok előzetes megtervezése, valamint kód alapján történő utólagos megalkotása (legenerálása, ha van rá mód, és elég jó a program, amit erre használunk) is nagyon hasznos lehet. Már csak pont amiatt is, amit azt hiszem Te is írtál, hogy nagyjából egy nyelvet beszéljenek a programozási folyamatok különböző fázisaiban részt vevő fejlesztők is.
Félreértés ne essék, nem azt mondom, hogy UML nélkül nem lehet létezni, sőt, nagyon is sok példa van rá, hogy egyszerűen elkerülik a használatát a fejlesztés során, de nem ördögtől való, és nem is haszontalan találmányról van szó, hanem épp ellenkezőleg, sok hasznát lehet venni adott esetben.Sk8erPeter
-
Jim Tonic
nagyúr
Ne aggódj, itt vagyok én is UML ellenesnek. Szerintem hirtelen felrajzolni sem tudnám, csak utánanézéssel. Mondjuk magam nem veszek rész olyan projektekben, ahol félig laikusoknak kellene elmagyaráznom dolgokat. Mondjuk túl nagy dolgokat sem programoztam még.
Alcohol & calculus don't mix. Never drink & derive.
-
#5275
cucka
addikt
Sk8erPeter
#5272
cucka
addikt
válasz
Sk8erPeter
#5272
üzenetére
Ha már erről van szó - a különböző tervezési minták alkalmazása esetén is szinte elkerülhetetlen szerintem az áttekinthetőség érdekében egy normális UML-diagram megalkotása a programunkban szereplő objektumok kapcsolódásáról ahhoz, hogy a megfelelő tervezési mintát rá tudjuk húzni a saját feladatunkra.
Ezt így írják a tankönyvekben, a valóság azért kicsit más. A tervezési minták egyáltalán nem mindenhatóak, tulajdonképpen csupa olyan dolog, amire magától is elég hamar rájön az ember, ha mereven ragaszkodsz hozzájuk, akkor az inkább árt, mint használ.
Persze, az egyetemen van olyan tantárgy, ahol ezt tanítják, ott nyilván azt fogod hallani, hogy ezek aztán elengedhetetlenül fontos dolgok és ezek nélkül nincs minőségi szoftver.Az van, hogy a valóságban egyre több helyen agilis módszertan szerint fejlesztik a szoftvert (sokszor nem tudatosan), ott meg nem úgy működnek a dolgok, hogy a felhasználó által előzetesen jóváhagyott specifikáció alapján hetekig-hónapokig reszeljük a különféle uml diagramokat, majd amikor menet közben változik a specifikáció, akkor megint csak reszelgetjük hetekig, hogy a valódi állapotokat tükrözzék.
(Te csak osztálydiagramról beszéltél, van még ezen kívül pár fajta UML diagram)[ Szerkesztve ]
-
#5276
stevve
nagyúr
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. 
[ Szerkesztve ]
-
amargo
addikt
Sziasztok!
Érdeklődnék, hogy aki már használt sketchflow-t projekteken, az kb mekkora hatékonysággal tudta kihasználni, azaz mennyire volt vevő rá a felhasználó és kb mennyi enap-os projektről volt szó. Mert én jelenleg kicsit felemásan látom ezt a MS-os ajánlást.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
oregcsóka
őstag
Sziasztok, érdeklődnék, biztos tudja valaki, hogy a Windows alá írt programok milyen programnyelven íródtak, és mivel lehet esetleg megnyitni-szerkeszteni egy .exe fájlt, assembly szinten, nem gépi kódban?
''Ha igazad van, megengedheted magadnak, hogy megőrizd a nyugalmad. Ha nincs igazad, nem engedheted meg, hogy elveszítsd.'' /Mahatma Gandhi/
-
-
oregcsóka
őstag
Nem, hanem a gépi kódnál magasabb, egyébként alacsony nyelvü programozással. A Commodore64-nél volt ilyesmi, csak már nem tudom hogy hívták.
''Ha igazad van, megengedheted magadnak, hogy megőrizd a nyugalmad. Ha nincs igazad, nem engedheted meg, hogy elveszítsd.'' /Mahatma Gandhi/
-
ArchElf
addikt
válasz
oregcsóka
#5280
üzenetére
C64-es BASIC-je - ha jól rémlik - tokenizált nyelv volt (inkább interpreteres, mint kompilált nyelv). A PC (windows, dos, egyebek) futtatható fájlai leggyakrabban kompilált (lefordított) programok (lefordítandó programnyelven készült programok). Legtöbbször a forrásnyelv kitalálható a gépi kódból, de viszonylag kevés nyelv van, ahol a gépi kód visszafordítható volna (majdnem egy-az-egyben) forráskódra. Az ilyen (ehhez hasonló) nyelvek a "modern korban" .NET környezetben készült nyelvek (IL kódot generál a fordító, nem közvetlenül gépi kódot), és a JAVA (szintén ú.n. byte-kód készül, amit a JVM fordít gép kódra).
Vannak emellet interpretált futtathatók (szkriptnyelvek), de ezek - mivel futtatás előtt nincsenek lefordítva - így közvetlenül is olvashatók.AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
amargo
addikt
válasz
oregcsóka
#5280
üzenetére
A leírtakhoz, annyit fűznék hozzá, hogy törvénytelen is a bináris állomány visszafejtése, ha a szerző úgy gondolja, akkor megoszthatja - legjobb tudomásom szerint még az open source bináris állományára is vonatkozik, de ennyire nem vagyok ezekben jártas.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
amargo
addikt
válasz
Jester01
#5283
üzenetére
Egy kicsit tudnál még erről írni - nem szoktam ilyenekkel foglalkozni -, de én eddig kicsit másképpen ismertem. Már magával a fordítással a szellemi tulajdonoddá válik a bináris állomány - én eddig így tudtam.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
oregcsóka
őstag
Köszönöm a hozzászólásokat, szóval nincs egy egységes szabvány programnyelv, amin íródtak ezek a Windows alatt futó programok?
''Ha igazad van, megengedheted magadnak, hogy megőrizd a nyugalmad. Ha nincs igazad, nem engedheted meg, hogy elveszítsd.'' /Mahatma Gandhi/
-
-
oregcsóka
őstag
Köszönöm szépen.
Akkor jó eséllyel lehet ezeket szerkeszteni, ha mondjuk átnevezem a fájlt, pl.txt-re, szerkesztés után pedig visszaadom a régi kiterjesztését.[ Szerkesztve ]
''Ha igazad van, megengedheted magadnak, hogy megőrizd a nyugalmad. Ha nincs igazad, nem engedheted meg, hogy elveszítsd.'' /Mahatma Gandhi/
-
amargo
addikt
válasz
oregcsóka
#5289
üzenetére
Ne haragudj, de egy kicsit megint lemaradtam.
Mit lehet szerkeszteni?
Ha a bináris állományt akarod, akkor kevés hozzá az átnevezés. Úgynevezett decompiler/reverse engineering-re van szükség. Ha a bináris állomány kódolt, akkor még nagyobb feladat.Ha leírod mit szeretnél csinálni, lehet jobban tudnánk segíteni.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
cucka
addikt
válasz
oregcsóka
#5289
üzenetére
Nem kötekedésből meg fennhéjazásból, de ha az első gondolatod egy .exe file esetén, hogy átnevezed .txt-re hogy szerkeszthesd, akkor ne erőltesd ezt az egészet. Ez nem az a témakör, ahol néhány fórum hozzászólás elég ahhoz, hogy akár minimálisan is képben legyél azzal kapcsolatban, hogy mi merre hogyan.
-
Lacces
őstag
Sziasztok!
Nagy gondban vagyok, nem tudom melyik programozási nyelv és platform állna hozzám közelebb, melyiket válasszam?
Sajnos én egyetem csúsztam 2 évet... ez az én hibám, bevallom lusta voltam, és ha nehézségeim akadtak a programozási tárgyaimmal, akkor nem voltam elég kitartó.
Az utóbbi néhány hétben nagyon összeszedtem magam. De nem tudom, hogy melyik lenne a jó és megfelelő programozási környezet, nyelv, amelyben elmélyítsem a tudásomat.Régen tetszett a asp.net, az mvc részével dolgoztam is egy darabig, de nem szerettem meg... a sima asp.net-tel pedig hobbi szinten szívesen foglalkozom. De kevés a cég, akinek ez kell. Oda nagyon magas tudással tudnék csak belépni.
Érdekel a php is, most azt fogom tanulni mysql-el a nyáron. A Drupal cms is nagyon érdekesnek tartom, illetve van egy alap xhtml, css tudásom, és most fogok bele a Jquerry-be is. (könyvek könyvtárból kikölcsönözve).
C#-ot tanultam, de nekem szintén nem jött be sajnos. Valahogy úgy vettem észre, hogy Java-hoz könnyebb megoldani a beadandókat. És a Nagy Gusztáv című Java jegyzet meghozta hozzá a kedvem, így azzal is fogok nyáron foglalkozni. Bruce Eckel könyve megtetszett, és ez alapján a C++ még az ami nagyon vonzz.
De nem tudom, hogy melyikkel foglalkozom mélyebben...Szerintetek mi alapján kell dönteni? A .net-es technológiák iránt sokáig érdeklődtem, T4B-re is mentem, meg nyári képzésre is. De valahogy a sok egyetemi beadandó progik kudarca miatt, elvette a kedvem tőle... Meg úgy érzem, hogy úgy igazán jó könyvek kevés van belőle, mint Java-ból.
Rövid távon, php és mysql + jquerry vagy javascript az amivel úgy foglalkoznék, de hosszabb távon biztosan beleunnék.
A java mellett szól az android platform is. Na meg, hogy egyszer szeretnék majd egy Macbook-ot :-).
Viszont a C++ mellett, hogy talán egyszer majd felvételiznék Mérnök Info-szakra MSc-n, vagy egy külföldi egyetemen, ahol a C++ hardverközelibb nyelv tudtommal. De ennek elsajátítása nehézkes lehet.Illetve a között vacilálok, hogy 2 hónap alatti nyári szünetemnél melyik nyelvet lehet úgy mond hamarabb "megtanulni az alapokat"? (Java és C++-ra gondolok)
A .net egy devportálos cikk miatt is elriasztott...Bár lehet algoritmikusokat is kéne találkoznom, arra tudtok valami jó könyvet? weboldalt? ahol különböző forráskódok vannak, pl.: lexikografikus keresésre, mintaprogramok stb.
A válaszokat előre is köszönöm.
-
cucka
addikt
.net, java - Ezek mögött kb. hasonló az elgondolás, bármelyikkel érdemes lehet foglalkozni, munkalehetőség van bőven.
c, c++ - Ha mérnök vonalon szeretnél mozogni, akkor ideális választás, munkalehetőség is van (elsősorban c++)
php - Előnye, hogy nagyon gyorsan lehet releváns tudásra szert tenni. Hátránya ugyanez. Szarul fizető php-s munkahelyet vagy projekteket tömegével lehet találni, komolyabb cégeknél viszont ritkán használják.
Python - Ritkán keresnek Python programozót, de kevesen is értenek hozzá. Jelenleg pythonban dolgozom, az általam látott legkirályabb scriptnyelv.Algoritmusok: az igazi klasszikus a Knuth féle "A számítógép-programozás művészete", de ehelyett a sokkal korszerűbb Cormen-Leiserson-Rivest féle Algoritmusok könyvet javaslom. Azt azért finoman hozzátenném, hogy ez egy meglehetősen tömény 900 oldalas könyv, viszont jó és tartalmas. Ha csak egy-egy algoritmus működésére van szükséged, akkor az angol nyelvű wikipédián mindent megtalálsz.
[ Szerkesztve ]
-
Lacces
őstag
Pythonban egyet értünk, a legkirályabb nyelv szerintem is :-D
"Cormen-Leiserson-Rivest féle Algoritmusok könyvet javaslom" - kezdő szintnek is ajánlod?
wikipédia sem rossz, csak tényleg, nem ártana jobban beleásni magam az algoritmusokba is, hogy egy-egy feladatot hogyan oldjak meg stb.
És köszi a segítséget!
-
cucka
addikt
"Cormen-Leiserson-Rivest féle Algoritmusok könyvet javaslom" - kezdő szintnek is ajánlod?
A könyvben meglepő módon egy csomó algoritmus van, elmagyarázza, hogy mit tudnak és hogyan működnek. Ez alapján a kérdésed értelmezhetetlen. (A quicksort az quicksort, kezdő és haladó szinten is) -
Ja de megvan 
, csak úgy volt hogy kivétel hozzáadása 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Mobil flották
- sziku69: Fűzzük össze a szavakat :)
- EA Play - Napokon belül elérhető lesz a Star Wars Jedi: Survivor
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Politika
- AMD vs. INTEL vs. NVIDIA
- Milyen légkondit a lakásba?
- Futás, futópályák
- Eredeti dizájnnal tér vissza idén a Nokia 225 4G
- TCL LCD és LED TV-k
- További aktív témák...
