Szoftverfejlesztés bármely szakaszában készítesz-e modelleket (ábrákat)?

Programozás

Igen, analóg módszerekkel (toll+papír, whiteboard, stb.)
28% (96 szavazat)
Igen, digitális módszerekkel (modellező szoftverek).
6% (22 szavazat)
Igen, vegyesen.
30% (103 szavazat)
Nem.
9% (30 szavazat)
Nem vagyok szoftverfejlesztő, hagyjatok békén.
27% (95 szavazat)
Összes szavazat: 346

( bra | 2012. 11. 13., k – 09:28 )

-Igen, digitális módszerekkel (modellező szoftverek).
+Igen, digitális módszerekkel (modellező szoftverek). Leírom melyikkel.

--
zsebHUP-ot használok!

Én a "Nem vagyok szoftverfejlesztő, hagyjatok békén." gombot nyomtam meg.

Ellenben volt olyan szakasza az életemnek, hogy kellett szoftvert írnom, Jackson-ábrát rajzolnom (amikor tanultam). Sőt, olyan is volt, hogy kellett egy szoftver és megrajzoltam a folyamatábrát, amit aztán a szoftverfejlesztő lefejlesztett. Skiccnek jó volt.

--
trey @ gépház

Eszem ágában sincs. Hivatalos okiratom (nem, nem hamis :) van róla, hogy szoftverfejlesztő vagyok. Azonban sosem tartottam magam annak, mert ha valamit nem gyakorlok hivatásszerűen, ahhoz nem is érthetek. Így nem is állítom, hogy értek hozzá.

Abban azért biztos vagyok - látva itt egykét ebből élő hozzászólását - hogy akár belőlem is lehetne kis rágyakorlással szoftverfejlesztő :D

--
trey @ gépház

( Lacyc3 v | 2012. 11. 13., k – 09:43 )

Igen, vegyesen de nem vagyok szoftverfejlesztő, hagyjatok békén. :)

( doc | 2012. 11. 13., k – 10:01 )

ooo...
a forras alapjan a Doxygen automatikusan generalja (graphvizt hasznalva), akkor ez most melyik? :D

Meg még egy tőlem a Doxygen használatáért, ami nálam rossz pont. (Hogy miért: mert általában úgy használják, hogy vagy telerakják a kódot dokumentációs kommentekkel, amivel az áttekinthetőség romlik, vagy nem rakják tele, akkor meg általában a Doxygen azt hozza ki, amit többnyire te is tudsz.)

es ez hogy jon ide? ennek semmi koze a doxygenhez...

szerintem igenis elvarhato hogy egy fuggvenyhez/metodushoz jarjon egy egy vagy ket soros comment
ha ezt amugy is megcsinalod, akkor nem nagy megeroltetes odairni mondjuk egy '@return' kulcsszot a visszateresi ertek leirasanal

ha valaki oldalnyi commentet fos feleslegesen, annak mar ugyis mindegy... ot meg szinten nem oszt/nem szoroz hogy ott van-e ket vagy harom doxygen kulcsszo

nem cafolni akartam azt amit irsz, csak arra akartam ramutatni, hogy nem mindig jo az eszetlen kommenteles,pl az olyan kommentek mondjuk egy AddCustomer method fole, hogy 'This method adds a customer' idegesitoek es elveszik a figyelmet.

'nem nagy megeroltetes odairni mondjuk egy '@return' kulcsszot a visszateresi ertek leirasanal'

egyetertek.

szerintem te nem erted hogy mirol beszelunk :)

a '@return'-nek nem sok koze van a programnyelvhez, az a doxygennek szolo plusz info

azt meg semmilyen programnyelv nem fogja nekem magatol beleirni a doksiba, hogy a vissz. ertekrol mit erdemes tudnod (es itt nyilvan nem arra gondolok hogy pl mi a tipusa, esetleg bizonyos nyelvekben milyen ertekeket vehet fel)

Rossz doksit mindennel lehet irni. En a Doxygent azert kedvelem, mert nem csak az lesz az eredmenye, hogy lesz szep HTML/PDF/man/akarmi doksim az API-rol, de a .h fileokban is ott lesznek a kommentek, igy ha valaki csak azokat nezi, mert nincs ingerenciaja, ideje, akarmi feltenni a -doc csomagot, vagy csak egyszeruen a forrast bongeszi, annak is hasznos.

Nyilvan nem jo mindenre a doxygen sem, nem helyettesiti a korrekt fejlesztoi dokumentaciot, de API dokumentalasra meg par kapcsolodo feladatra kivalo.

--
|8]

a kulon doksiirast en meg soha, senkinel nem lattam mukodni
altalaban nagyon gyorsan 'out of sync' lesz a doksi es a forras, amibol aztan iszonyat kaosz tud keletkezni
doxygennel legalabb valamennyire ra vagy szoritva hogy egyutt haladjon a forras es a dokumentacio

persze nyilvan lehet rosszul is csinalni, de ennek meg semmi koze a doxygenhez, aki nem tud normalis commentet irni, az valoszinuleg dokumentaciot sem fog...

marmint melyik hozzaallas az, ami a logikaval szembemegy?
a doxygen alapelve az, hogy a forrast a forrasban dokumentaljuk. ez szerintem nemhogy szembe nem megy a logikaval hanem epp' ellenkezoleg: a leglogikusabb, legkenyelmesebb es leghatekonyabb megoldas
(az, hogy ehhez milyen szintaktikat hasznalsz, mar egy masik kerdes, bar az en velemenyem az hogy a doxygen ebben is jol vizsgazott)

"persze nyilvan lehet rosszul is csinalni, de ennek meg semmi koze a doxygenhez,"

Ez a hozzáállás megy szembe a logikával. Hogy ha lehet jól csinálni, akkor a tool tökéletes.

Bogozom, bogozom... Tehát akkor aszondod, hogy nem a doxygen megy szembe a logikával, hanem a felhasználó? Arra semmi program nincs, ami ezt megakadályozná :)

a kerdes NEM uzleti folyamatokrol szolt, hanem a szoftverfejlesztessel kapcsolatos modellekrol
ennek egy kis reszhalmaza persze lehet az uzleti folyamat...

egyebkent doxygenben is lehet sajat abrakkal dokumentalni (csinaltam is mar ilyet), a kulcsszo a graphviz ;)

ezt viszont mar nyilvan nem a forraskodban (hacsak nem kapcsolodik ertelemszeruen oda)

Modellekrol, abrakrol esetleg specifikaciokrol.

Ez lehet tervezes (akar funkcionalis, akar muszaki) reszekent, lehet teszteles reszekent, stb. Kodrol es hasonlokrol itt most szo sincs.

Ki beszelt itt dokumentaciorol? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Miért rossz a doxygen?
Van esetleg olyan dokumentum-generáló, ami nem a forrásfájlokból dolgozik?
Szerintem néhány sornyi dolog sokszor nem árthat, ha van a forrásban (néhány sor < 5-10). De valóban, azon már én is gondolkodtam, hogy amikor több tíz sort érdemes odaírni (pontosság miatt), akkor mit lehetne inkább csinálni, mert az már tényleg sok.

Az hogy utólag generáltatsz valamit az más. Nyilván itt a struktúrák, megoldások előzetes megtervezéséről, elemzéséről van szó. Nálunk az irodában van tábla, arra szoktunk egymásnak rajzolgatni. Illetve elég gyakran firkálgatok magamnak papírra, mert úgy jobban át tudom gondolni a dolgokat. Egyébként nem használunk semmi extrát.

--
http://neurogadget.com/

nem, ez azt jelenti hogy a kerdes 'fejlesztes barmely szakaszarol' szolt, es a mar meglevo kod alapjan rajzolt diagram szerintem belefer a 'barmely szakasz'-ba :)

egyebkent diagramokat tobbnyire nem szoktam rajzolni, vagy legalabbis nem szabvany UML-eket meg egyebeket, hanem nagyvonalubb, inkabb attekinto jellegueket (amikor van ertelme)

( fdavid | 2012. 11. 13., k – 11:53 )

Ez azert komolyabb szoftvernel alap. A rajzolo toolok nekem nem elegendoek, alapvetoen rendes modellezo eszkozzel dolgozom. Pl. Enterprise Architect. De persze a papir es ceruza is kivalo a kollegakkal valo beszelgeteshez es otleteleshez.

Van aki szerint a túl sok tervezés is árt, úgyhogy ezen lehet vitatkozni. Nálunk nincs modellezés, inkább a szép kód a követelmény. Elvileg az OOP-t részben azért találták ki, hogy maga kód is adjon egy absztrakt nézetet az üzleti entitásokra, tehát ne egy halom algoritmus legyen, amiből semmi nem derül ki ránézésre. Ha kell egy modell, fogom a forrásfát és ráeresztek valamit, de nem érzem a késztetést.

--
http://neurogadget.com/

Aki szerint a tul sok tervezes art, annak azt javaslom, hogy alljon neki autopalyahidat epiteni tervezes nelkul nehany komuvessel. A lenyeg, hogy az elek a beton ontesenel szep egyenesek legyenek.

Szoval a szep kod nem helyettesiti a tervezest. A szep kod szimplan alapkovetlemeny, de tervezes nelkul eleg keves esellyel lesz szep a kod.

de tervezes nelkul eleg keves esellyel lesz szep a kod

Ez projekktől, fejlesztőktők, munkafolyamatoktól, határidőktől, vezetőségtől függ. Miért gondolod, hogy úgy kell csinálni mindenkinek, ahogy te csinálod? Ja, hogy okos emberek azt írták a könyvekben.. aha :P

--
CyclonePHP

Nyilván, kis projektben és olyan problémánál, ahol előre nem ismert a megoldás, ott nem kell/lehet tervezni. Minden más esetben érdemes.

A kis projekt mérete az egyéni agykapacitástól és ízléstől is függ. Én pl. adatbázis struktúrát, nagyobbacska üzleti/kommunikációs folyamatokat, algoritmusokat nem szeretek fejben tartani, se forráskódból/adatbázisból bogarászni. Abból csak a baj van, és egymás idejét pazaroljuk. :)

Majd azt azert ird le, hogy hol irtam olyat, hogy ugy kell csinalni, ahogy en csinalom, es hogy azert kell ugy csinalni, mert ezt irtak a konyvekben. De ha mar a konyvek is azt irjak, akkor erdemes lenne azokat a konyveket egy kicsit olvasgatnod.

A tervezes egy szuksegszeruseg. Hogy valaki kodolas kozben "on-the-fly" (donto tobbsegeben rosszul) csinalja, vagy kidolgozott modszer menten alaposan, tobbekkel egysztetve az ugye nyilvan az eredmenyen latszani fog.

Fussunk neki mégegyszer: a túl sok tervezés bizonyos esetekben tényleg árt (Gyuszk eredeti állítása ez volt, erre sikerült kifosnod a billentyűzetedből az arroganciádat), jellemzően túlabsztrahálással (túlbonyolítással) járhat. Tudom, hogy ezt suliban nem mondják, de attól még ez a tapasztalat.

Az autópályás hasonlatod pedig hihetetlenül demagóg volt.

--
CyclonePHP

Na hat ez a nekifutas mar tenyleg szep szaftos lett. (A stilus maga az ember.) Es megint jossz valmi suli dologgal,amit nem tudom honnan vettel.
Semmilyen arrogancia es demagogia nincs abban, hogy leirom azon velemenyem, hogy nincs tul sok tervezes, csak rossz tervezes. Az over-engineering az egy tervezesi hiba, amire nem megoldas a tervezes elhagyasa.

Akkor most pillanatra szakadjunk el az n+1. webportáltól (bár azért egy picit komolyabb projektnél ott is érheti meglepetést az ember, ha nem gondolja végig, hogy mi függ össze mivel) és nézzünk meg egy valós élet beli ügyviteli folyamatot, amit sokszor a megrendelő sem tud leírni magának segítség nélkül.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azert ez erosen attol fugg, hogy milyen projektrol van szo. Ha semmi ujat nem csinalsz, csak az 1001. szamlazo-keszletnyilvantarto programot, akkor persze celszeru elotte minel alaposabban megtervezni, kulonosen ha nagy.

Viszont ha olyan problemad van, amire egyaltalan nem biztos, hogy van megoldas, ha megis van, nem biztos, hogy mukodik minden, a valosagban elofordulo esetre, es ha megis mukodik, egyaltalan nem biztos, hogy barki is hajlando penzt adni erte - nos, ha ebben a helyzetben valaki leul, honapok alatt megtervezi az egeszet az utolso szogig, es utana a tervhez tuzon-vizen at ragaszkodik, az bizony nem teljesen ep.
Valoszinuleg erre gondolt a kollega, amikor azt mondta, hogy a tul sok tervezes karos is lehet.

--
"You're NOT paranoid, we really are out to get you!"

Azt vegyük észre, hogy az általad említett professzionális tervezőeszköz más kategória, mint a brainstorming, rubberducking, rajzolgatás és beszélgetés. Az utóbbiak is tervezéssel és ábrákkal járnak, csak nyilván messze kisebb volumenben. Tehát nem azt állítottam hogy "nem kell tervezni", csak azt, hogy nem a világ összes projektje igényli, hogy mondjuk 6 hónapig csak terveztek.

--
http://neurogadget.com/

Ez hülyeség. Előző melóhelyemen rengeteg vitánk volt a vezetéssel, hogy hogyan is kellene egy sw fejlesztésnek történnie.

Sokáig tartott, mire eljutottunk odáig, hogy egy kis, alig 4-5 hetes kódolást igénylő projekthez készítsünk egy mindenre kiterjedő funkcionális specifikációt (kb. 35-40 oldalas Word doc lett a vége, készült kb. 1-1,5 hétig), viszont az a projekt ment legsimábban. Amikor már csak kódolni kellett, nem volt kérdés, hogy mit kell csinálni, nem voltak ilyen felkiáltások félúton, hogy "de srácok, ez nem lesz így jó", stb.

(Arról nem is beszélve, hogy akárhányszor így csináltuk, a megrendelő is roppant mód örült annak, hogy kapott valami előzetes betekintést abba, hogy mit is fog kézhez kapni. Egy ilyen doksi tartalmazta nálunk [al]projekt célját, a fogalmakat, azok leírását, folyamatokat, ha teljes projekt a tervezet futási környezetet és, hogy kik fogják felhasználni, milyen adatokkal dolgoztunk valamint minden egyes UI vázlatos tervét és részletes leírását ilyen "ha ide kattitunk ez és ez történik" leírásban.)

Mellesleg a forrásfa nem feltétlen fog neked megmondani egy csomó dolgot, amit egy rendes modell igen.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( pepo v | 2012. 11. 13., k – 12:05 )

Megbeszélés+papír+cetlik+kódolás.

( uid_194 | 2012. 11. 13., k – 13:15 )

A programrol magarol (vagy egyes reszeirol) nagyon ritkan csinalok barmifele abrat, maximum callgraphot nezek amikor bottlenecket keresek.

Az adatrol azonban... na az mar egy tok mas tortenet. Nagyon fasza abraim es animacioim vannak arrol, hogyan valtozik egy-egy adathalmaz a programom futasa kozben. En szemely szerint ezekbol sokkal jobban meg tudom erteni, mi tortenik, mint az anno egyetemen tanitott (de meg sose tanult) mindenfele abrakbol.

--
|8]

Igen, a bonyolult és statikus ábrák akkor is semmitmondóak maradnak, ha 1 órát magyarázol hozzá kézzel lábbal. Animációk segítségével sokkal hamarabb megfogja az ember a lényeget (rengeteg tárgyat sikerült úgy megcsinálnom hogy animált segédleteket kerestem, pl. gráfalgoritmusok).

--
http://neurogadget.com/

" mint az anno egyetemen tanitott (de meg sose tanult) mindenfele abrakbol."

Erről az UML jut eszembe. Mindenki le van ragadva a class diagramoknál (már csak azért is, mert a legtöbb IDE képes produkálni magából olyat), holott szerintem annak van a legkevesebb jelentősége. Activity, use-case, és hasonlók, amivel magát az üzleti folyamatokat doksizod, sokkal-sokkal hasznosabbak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mire, ugye.

Egy use case, egy state machine, egy activity diagram kiváló, amikor egy rendszer működését elemzed, tervezed.

Az én esetemben egy terv itt általában meg is áll, a megvalósítást majd a fejlesztők megtervezik. Szóval nekem ezek a fontosak.

De ha én fejleszteném tovább, akkor ezután jöhet mondjuk egy Sequence diagram, ahol már ojjektumok is vannak, de lehet, hogy kihagyom. Aztán egy class diagram.

Aztán a kódot lehet generálni ebből.

Persze egy jó CASE tool ezeken végig is visz így, use case diagram alát tudsz felvenni pl. sequence diagramot, a sequence diagramba betett osztályokat megjegyzi, az üzeneteket beteszi, mint tagfüggvényt, stb. Szóval a class diagramra már félkész osztályok kerülnek.

Viszont ha én egy funkcionális specifikációt adok egy fejlesztőnek, amiben mondjuk minden szövegesen van leírva, akkor ő nem fog nekilátni más diagrammokkal szórakozni. Elgondolkodik és megtervezi az osztályokat.

Neki ez a fontos.

( uid_14867 | 2012. 11. 13., k – 15:45 )

ha adatbázisa is lesz a szoftvernek, azt mindenképpen vizualizálja nekem a MySQL Workbench (vagy úgy, hogy előtte phpMyAdmin-ban megcsinálom és áttöltöm a programba, vagy a programban kattintom össze és feltolom MySQL-be). más esetben csak akkor modellezek, ha kifejezetten kérik.

( phaul | 2012. 11. 13., k – 19:47 )

vegigolvasva a szalat arra kell rajojjek, hogy az en gyakorlati tapasztalatom egesz mas mint a tobbsege,. asszem ez azert van mert olyan projecteckbol indultok ki, amit megterveztek, megcsinaltok eladtok - vagy nem, mindegy - de ezen a ponton kesz.

Nalam inkabb az a helyzet, hogy megtervezunk valamit, csinalunk valamit amit egesz jol el lehet adni, eladjuk par vasarlonak, aztan jon egy vasarlo aki mond egy olyan arat aminek nem mondasz nemet, cserebe kitalal egy rakat olyan dolgot ami sehogy nem illik az eredeti designba. Kerdes - penz kell vagy hogy nezegethesd milyen szep a design :) Egyebkent a szoveges funkiconalis specifikacioban (SFS) jobban hiszek mint UML, flow etc diagramokban. Absztraktabb, kevesebb van benne implementacios konkretumokbol, uh jobban tud az "igazi" problemara koncentralni.

"Absztraktabb"

Igen, szerintem valahol itt lehet az a bizonyos eb elhantolva. A kb. 10 éves profi java programozói pályám során végigmentem a legtöbb lehetséges modellező programon, UML rajzolón, stb. és a következőre jutottam: az első dolog az, hogy megtaláljuk a megfelelő absztrakciós szintet, ahol a megrendelővel (legyen az valódi megrendelő, vagy csak a projekt menedzser) át tudjuk beszélni, hogy ő pontosan mit szeretne. Ehhez nagyon jók a rajzok egy whiteboard-on vagy egy mockup készítő programban (mi a pencil-t használjuk, de van 1000 más), mert olyan LOGIKAI problémákra tudja felhívni a figyelmet, ami ha fejlesztés során derül ki, az nem lesz vicces. Fontos végigbeszélni a rendszer működését: mi hogyan fog működni magas szinten, mi kapcsolódik mihez. Ez UI-nál egyértelmű (ide kattint a felhasználó, ezt fogja látni) de egy más szintű rendszertervnél, pl. ahol szerverek és kommunkációs protokollok is vannak, ugyanúgy alapvető.

Itt szokott kiderülni az, hogy nagyon sok hasonló rész lesz a programban, hogy mit érdemes esetleg megvenni, mit fejlesszünk le, mihez van szabadon felhasználható könyvtár, stb. Érdemes szemmel tartani, hogy hiába beszélünk át mindent, a customer bármikor kitalál olyan hülyeséget, ami legalább kicsit borítja a rendszert.

Ha mindez megtörtént, akkor írjuk le a megbeszélteket, fényképezzük be a whiteboard-ot, stb. Ezután definiálhatunk magasszintű feature-öket, ezeket beledobhatjuk egy nagy backlog-ba, amit aztán priorizálhat a kedves customer, és mehet a SCRUM, vagy tetszőleges más PM módszertan.

Ezután jönnek a programozói rész (nálunk programozó/architect-ek vannak) amikor programozási szemmel kell struktúrákat tervezni. Annak semmi értelmét nem látom, hogy metódus szintű hívásokat írjunk le, inkább a Queue, Thread, Design Pattern, esetleg még magasabb szinten gondolkozunk (ide jön egy cache, ide egy tomcat, ide egy rest interfész). Ha esetleg valami rész nagyon bonyolult, akkor ott érdemes nekimenni sequence diagrammal, vagy állapotgéppel. Ezeket a rajzokat mindig dokumentáljuk némi szöveggel úgy, hogy ha másoknak szüksége lesz rá, akkor néhány mondatból megértse, hogy mit miért csináltunk, mi volt a döntés oka. Ez magunknak is jó, mert én pl. fél-1 évvel ezelőtti kódnál nem mindig emlékszem,hogy egy trükkösebb esetben mit-miért csináltam.

Ezután jöhet a kódolás, de előtte érdemes megtervezni (5-10 percben) hogy az adott funkciót hogyan fogjuk tesztelni, esetenként lehet tesztlistát/tesztet is írni, ez később nagyon meghálálja magát.

( Aadaam v | 2012. 11. 14., sze – 04:00 )

Igen, analóg és digitális módszerekkel, bár speciel az EA-tól hisztit kapok, olyat sose akar amilyet én, akkor se, ha nagykönyv szerinti UML-el dolgoznék (OMG UML specifikáció - ingyen leszedhető, PDF)

Szóval én biza egyszerű vektorgrafikus csodákkal sokszor, és kézi ellenőrzés a modellek közt - nem túl gyors néha, de inkább ez mint veszekedés az EA-val, az első olyan paránál hogy valamit emiatt nagyon benézek, úgyis automatizálnám.

Azt látom, hogy az én területemen - nagyvállalati konzumer webes rendszerek, ilyen alexa top 500-as weboldalak - a Tervezést, mivel az informatikusok nem hajlandóak, a UX vette át.

Meglepő amikor az ember a kis képernyőkép-mockupjaik előkészítő doksijaiban komplett adatstruktúrákat, folyamatábrákat, állapotdiagrammokat talál - az esetek többségében durván elcseszve, mert érti, hogy ez kell hozzá hogy konzisztens legyen, de nem ért hozzá akkor se.

Ha értesz az UML-hez, egy picit rá kell tanulni pszichológiát (nem a freudit, pl. rendes emberi memóriamodelleket), meg vizuális tervezésből a tényleg tanulható részt (gridek pl), és te leszel az ász...