Citat:
@bkaradzic
Neki dizajner alati drže formu u binarnom obliku pa nije moguće porediti verzije
Ali često postoji i opcija da se izabere između binarnog i skript načina čuvanja, zar ne? Tada DIFF završava posao bez ikakvih problema ;)
Citat:
@mmix
GUI kod za kompleksnu formu moze da naraste na par hiljada linija koda uz efektivan payload (konkretnu logiku) forme od par stotina linija.
Da, ali postoje i potpuno obrnuti primeri (i moj slučaj) - da nekih 10 ili 50 formi sa sve binding kodom, spakovano u neki modul, bude trivijalna dobit (mereno u bilo nečemu: vremenu, novcu i sl.) u poređenju sa kompletnom implementiranom logikom, algoritmima i tehnologijama koje su u pozadini projekta, a čine suštinu i njegovu vrednost.
Citat:
@MarkoBalkan
pa zar onda izrada projekta ne traje duže?
ako traje duže, onda je i skuplje?
Pa ne nužno. Ne može baš da se za sve tipove projekata napravi takva proporcija.
RAD alati ti pružaju vrhunske performanse i uštedu kada je u pitanju projektovanje i održavanje interfejsa, prototipova, 'apstraktan' pogleda na taj deo sistema (ŠTA želim da uradim, a ne KAKO da nešto uradim), ali ti ne mogu puno pomoći kada je u pitanju implementacija konkretnih ne-vizuelnih podsistema.
Na primer, nekoliko meseci ili godina si radio na nakom super algoritmu za redukciju red-eye efekta kod fotografija, koji je bolji od svih prethodnih - to je ono što su ljudi spremni da ti plate. Sad sračunaj koliko je to vremena u odnosu na uštedu koju ćeš imati u projektovanju nekoliko jednostavnih interfejsa.
---
E sad, da ne ispadne da sam ja protiv RAD alata, naprotiv. Ja sam ljubitelj RAD alata i mislim da je to kvalitativni skok u dosadasnjem načinu razvoja. RAD ne obavezuje korisnika da koristi to što nudi, već je samo mogućnost i svako treba da pronađe svoj interes u tome.
RAD je korisan i početnicima jer i nudi i uči. Imati pred sobom budući izgled interfejsa, property-je i evente pojedinačnih objekata, sve povezano Class Explorerom i sa kontekstno osetljivim F1 pod prstom - zaista rasterećuje developra mnogih trenutnih dilema.
Možda način čuvanja zapisa RAD formi što pomenu bkaradzic (binarni, skript, ili nešto treće) nije najsrećniji (pogotovo jer nema kompatibilnosti sa ostalim RAD tvorevinama) ali to se da prevazići.
O konkretnoj upotrebnoj vredniosti RAD alata, evo mojih iskustava (s obzorom da radim u firmi od 5,000 ljudi).
90% programa u praksi nisu vrhunska ostvarenja nego su namenski, instant programi (kako ih ja zovem), odnosno podrška nekom većem sistemu. To su recimo programi koji se konektuju na neki postojeći 'data storage' i produkuju neke izveštaje ili funkcionalnosti koji nisu bili inicijalno predviđeni. I da ne bude zabune, ti programi su VAŽNI iako je tip programa složenosti 'telefonskog imenika'. Takav program se sa sve izveštajima u RAD okruženju pravi za par sati a neko će reći i za pola sata. To je vrhunska produktivnost i ja ne mogu da zamislim ništa bolje od toga. Naravno, sve to ne znači da je RAD razvoj fokusiran da samo bude podrška nečem 'većem', ali čisto pominjem jedanu konkretanu vrednost.
Ipak, ono u što sam definitivno siguran (i nije ovde tema) je da RAD alat zna da bude missused i 'odškoluje' loše programere.
Citat:
znači, preporuča se raditi ručno?
tj. pisati kod i sve ostalo.
Jok. Treba da naučiš da o problemu razmišljaš 'slojevito' i da prepoznaš šta je kao zicer nadležnost za RAD deo, a šta od koda je prirodno da odvojiš u neki zaseban modul, jer je logički druga celina. Ovo je korisno razumeti i zbog organizovanja timskog rada, da ne ispadne da baš svi developeri moraju da zabadaju nos u isti Unit kad nema potrebe.
Na primer /karikirano/, ako imaš:
OnClick( argumenti )
{
// ovde 1000 linija koda
}
...po svoj prilici ovo je loše.
Bolje je:
OnClick( argumenti )
{
NekiDrugiModul.Logika( argumenti ); // ... i baš me briga ima li 1000 linija u toj nekoj metodi tuđeg modula, jer je to sad Perin problem a ne moj i njega će šef da hvata za gušu...
}