[Alg] RAD discussie.

[Alarmnummer]

Een van de dingen die me de laatste tijd erg opgevallen is dat de overhead van platformen zoals Java en .NET vrij groot is als je bedrijfsapplicaties gaat bouwen. Er zijn uiteraard wel voordelen aan deze aanpak, je houd namelijk controle en kunt alles tot in de kleinste puntjes coordineren. Maar mijn vraag is: is deze rekening voor kleine applicaties niet veel te hoog en is RAD misschien toch niet zo`n slecht alternatief? Ik zou geen gecompliceerde omgeving willen opzetten met een RAD omgeving als ik niet de mogelijkheid heb om mijn keuzes te kunnen maken, maar voor kleine applicaties denk ik dat RAD misschien wel een beter alternatief is.

Ik heb zelf even zitten spelen met Fabrique van Jetbrains (zelfde makers als IntelliJ idea). En dat is ook een RAD omgeving voor Java waarbij een enorm stuk code generatie voor plaatsvind. Ik denk dat voor kleine projecten dit wel een kostenbespaarder kan zijn.

Mijn vragen zijn:
-welke RAD omgevingen heb je gebruikt?
-als je ook normale omgevingen gebruikt, kun je een vergelijking geven tussen de RAD en de normale aanpak?
-heb je er geld mee bespaard?
-hoe goed schaalden de RAD projecten mee in groote?
-hoe onderhoudbaar was de code? Sommige omgevingen die genereren door drag en drop een lading code dat snel niet meer onderhoudbaar is. Maar er zijn ook omgevingen die je gehele applicatie in een hoger model zetten en daar wel controle kunnen uitoefenen op de consistentie van die applicatie. Check fabrique.

[ Voor 12% gewijzigd door Alarmnummer op 01-03-2005 08:54 ]

[ronaldmathies]

We hebben hier ruim 13 jaar lang gebruik gemaakt van Omnis (www.omnis.net), dit product heeft heel lang goed gewerkt. Alleen het nadeel is is dat je de mooie dingen van een OO taal mist. Ik heb nu 5 jaar lang in dit product gewerkt en mijn uiteindelijke conclusie is dat ik het voor de korte termijn een goed product vindt maar op de lange termijn kan het een grote bak elende zijn.

De onderhoudbaarheid is in het begin goed te doen, maar op de lange termijn één doffe elende. Dit komt vaak omdat bedrijven geneigd zijn minder gespecialiceerd personeel in dienst te nemen omdat het toch makkelijk is. Een andere reden is is omdat het code vaak dubbel gecreërd wordt omdat het niet fatsoenlijk te scheiden is. We hebben er zeker in het begin geld mee bespaard, en zeker veel geld mee verdient alleen op de lange termijn als het product bijvoorbeeld afsterf of ze gaan het rigelreus veranderen met alle conversies van dien dan is het ineens een heel duur project.

Denk bijvoorbeeld ook eens aan Oracle Forms, de conversies zijn vaak één bak elende en het product sterf nu af (over twee jaar). En dan moet je ineens je prodct omzetten naar iets anders, maar dat gaat niet want het is in een omgeving gemaakt die niet door een grotere markt beoefend word.

Hiernaast gebruiken we tegenwoordig Delphi en Java, en het kost mischien initeel wat meer, maar de onderhoudbaarheid en de levensduur van je software is naar mijn idee een stuk meer gegarandeerd.

Denk bijvoorbeeld eens aan het volgende feit:

Achter Java en .NET staan grote bedrijven, die support en onderhoud erop leveren. De kans dat zo'n bedrijf over de kop gaat is niet groot. En de kans dat het product afsterf is ook niet groot omdat het veel gebruikt wordt.

De kans dat een bedrijf met een RAD omgeving over de kop gaat is groter, en de kans dat het product dan afsterft is ook groot.

Ik ben over het algemeen negatief tegen over RAD maar dat komt meer door mijn ervaringen ermee. Dit wil niet zeggen dat Fabrique of Jetbrains slecht is. Maar het is iets om in de gaten te houden.

[farlane]

Het is de vraag wat je onder RAD verstaat, horen Delphi en VB daar bijvoorbeeld ook bij?

Naar mijn idee is het enige RAD aan die omgevingen namenlijk het in elkaar sleuren van de UI. De eigenlijke logica moet je alsnog inkloppen.

[Alarmnummer]

farlane schreef op dinsdag 01 maart 2005 @ 12:19:
Het is de vraag wat je onder RAD verstaat, horen Delphi en VB daar bijvoorbeeld ook bij?

Naar mijn idee is het enige RAD aan die omgevingen namenlijk het in elkaar sleuren van de UI.

Dat is denk ik een te beperkte kijk erop. RAD kan veel meer zijn dan alleen wat gui-sleur en pleur omgevingen. Als jij bv een bedrijfsapplicatie over Personen maakt, hoeveel keer ben jij bv het woord Persoon tegen gekomen vanaf de 1e tot de laatste keer? Het zal in je domein-model zijn, misschien in je uml, or mappings, database, forms, weblayer koppelingen, validatie etc etc.

Ik denk dat een RAD omgeving hier wel voor een verzachting van de pijn kan zorgen door zelf meer te genereren. Aha... er is dus een Persoon nodig... ok.. zorg ik ervoor dat de mapping goed komt, database model wordt aangepast/aangemaakt etc.

De eigenlijke logica moet je alsnog inkloppen.

De 'bedrijfs'logica wel. Daar kan het systeem nooit achter komen. Maar allerlei support logica zoals OR-mapping dat zou ook wel voor je gedaan kunnen worden. En het zal nooit tot in de puntjes te configureren zijn als je dat kan als je met de hand een OR-mapping opzet, maar de vraag is dus of je altijd deze controle nodig bent.

RAD omgevingen kunnen een stuk complexiteit wegnemen, en het gevolg hiervan is dat je een stuk controle verliest. Voor kleine applicaties is dat misschien wel een snellere manier van werken... sneller werken -> sneller klaar -> meer winst.

Verder denk ik dat een omgeving waarin je allerlei concepten uit bedrijfproblematiek als bouwstenen tegenkomt ook een enorme aanwinst kan zijn. Gewoonlijk ligt bedrijfslogica en support logica door elkaar (alhoewel je het wel wat kan scheiden). Maar een domein specifieke taal waarin concepten zoals Service, Business Object, Business Rule etc basis bouwstenen zijn, kunnen er voor zorgen dat je beter en sneller kunt ontwikkelen.

[Verwijderd]

farlane schreef op dinsdag 01 maart 2005 @ 12:19:
Het is de vraag wat je onder RAD verstaat, horen Delphi en VB daar bijvoorbeeld ook bij?

Naar mijn idee is het enige RAD aan die omgevingen namenlijk het in elkaar sleuren van de UI. De eigenlijke logica moet je alsnog inkloppen.

Ik heb weinig ervaring met VB (en dat wil ik ook graag zo houden ), maar Delphi heeft toch wel heel wat meer RAD-aspecten dan alleen het bijelkaar klikken van een UI, hoor.

Neem bv. 'class completion': je maakt een class, definieert z'n public properties, en met 1 druk op de knop (nou ja, 1 druk op 3 knoppen, ctrl-shift-C) worden automatisch de bijbehorende private fields en setters aangemaakt.Als dat niet 'rapid' is, weet ik 't niet meer. Je moet natuurlijk nog wel je eigen business logic toevoegen aan de setters en evt. de getters, maar dat moet je in andere RAD-achtige omgevingen ook.

Dingen als OR mapping, refactoring, etc. staan bij Delphi nog een beetje in de kinderschoenen, maar 't gaat de goede kant op.

Mijn ervaring is overigens dat met Delphi de code goed onderhoudbaar kan blijven, zelfs al is een project in de loop der jaren gegroeid naar >700.000 regels. Gewoon zorgen dat de basisstructuur goed in elkaar zit, en de IDE kan je daar een hoop in helpen. Wanneer je bv. een property of method toevoegt aan TMyBrilliantClass, en je gebruikt 'class completion', dan staat die setter of method ook in het juiste { TMyBrilliantClass } blok in de implementation. Houdt de boel een beetje overzichtelijk...

[EfBe]

RAD staat bij mij altijd gelijk aan dat ding dat men zich voor de ogen heeft laten draaien om toch maar met zo min mogelijk moeite zo snel mogelijk software te maken.

Er zijn een aantal dingen die middels visuele zaken zeer snel kunnen worden gebouwd. Er zijn ook zaken waarbij je gewoon code moet bouwen en niet met RAD bezig moet zijn. Ik noem bv het tranentrekkende fenomeen in VS.NET waarbij men een dataconnection op een formpje kan slepen en er allerlei kauwgom wordt aangemaakt aan de achterkant. Dat is geen RAD, dat is een RAMP.

De complexiteit van software engineering neemt heus niet af door het gebruik van z.g. RAD tools: die tools nemen alleen wat type werk uit handen. Op zich mooi meegenomen, maar in dat kader staan erg veel tools nog in de kinderschoenen.

De enige RAD tool, maar dat is het geloof ik niet eens, waar ik wel van onder de indruk ben is Biztalk met zn orchestration applicatie. Visueel je BL bouwen EN beheren. Je abstracte ontwerp wordt executeerbaar gemaakt. Kijk, dan maak je progressie.

[farlane]

Alarmnummer schreef op dinsdag 01 maart 2005 @ 12:34:
De 'bedrijfs'logica wel. Daar kan het systeem nooit achter komen. Maar allerlei support logica zoals OR-mapping dat zou ook wel voor je gedaan kunnen worden. En het zal nooit tot in de puntjes te configureren zijn als je dat kan als je met de hand een OR-mapping opzet, maar de vraag is dus of je altijd deze controle nodig bent.

Bij een 'echte' RAD omgeving denk ik aan een venster waarbij je blokjes kunt slepen en klikken en daarmee ook je logica bouwen ( de logica zelf moet je natuurlijk engineeren ).

Ik ben echter dergelijke dingen nog nooit tegengekomen, en ik denk eigenlijk ook dat de diversiteit van software dit niet praktisch haalbaar maakt.

Ik ben het met je eens dat alle hulp welkom is ( dus die RAD componenten die je veel klopwerk besparen ). Maar al te vaak helpen componenten die verder gaan ( zoals Efbe al aangaf ) je van de regen in de drup.

[Alarmnummer]

EfBe schreef op woensdag 02 maart 2005 @ 09:35:
RAD staat bij mij altijd gelijk aan dat ding dat men zich voor de ogen heeft laten draaien om toch maar met zo min mogelijk moeite zo snel mogelijk software te maken.

Wat is daar mis mee? Met zo weinig mogelijk moeite software te schrijven? Ik snap wel wat je bedoelt, aangezien veel rad producten kut te onderhouden software opleveren. Maar mij valt vooral binnen software ontwikkeling (en dan vooral binnen bedriijfs applicaties) de herhaling op en het zou fijn zijn als dat opgelost kan worden.

De complexiteit van software engineering neemt heus niet af door het gebruik van z.g. RAD tools: die tools nemen alleen wat type werk uit handen.

Zeker niet.. maar je kunt je wel beter concentreren op de complexiteit van het probleem en niet van allerlei randproblematiek.

Op zich mooi meegenomen, maar in dat kader staan erg veel tools nog in de kinderschoenen.

Ik heb zelf geen ervaring met RAD tools. In het begin zijn veel die-hard programmeurs er tegen omdat ze alles zelf onder controle willen houden (dat was ook mijn houding tov RAD). Maar soms zit ik wel zo van.. hmmmm.... ik loop nu veel dom en herhalend werk te doen... dan moet anders kunnen.

Er moet een hoger model te maken zijn van een bepaalde categorie applicaties. En uiteraard.. het zal nooit zo flexibel zijn zoals de tools die we nu hebben. Maar waarom zou ik altijd die prijs van deze vrijheid moeten betalen? Soms wil je iets simpels.. en als je in een paar uur ipv een dag iets in elkaar kan slepen waar een klant tevreden mee is. Wat is dan het probleem..

De enige RAD tool, maar dat is het geloof ik niet eens, waar ik wel van onder de indruk ben is Biztalk met zn orchestration applicatie. Visueel je BL bouwen EN beheren. Je abstracte ontwerp wordt executeerbaar gemaakt. Kijk, dan maak je progressie.

hmmm.. visueel hoeft van mij niet altijd. Maar het feit dat je met een hoger model kunt werken om je problemen in uit te drukken zou in sommige gevallen (denk ik) wel eens een goedkoper alternatief kunnen zijn.

[ Voor 3% gewijzigd door Alarmnummer op 02-03-2005 22:35 ]

[Delphi32]

Is deze feature van Borland ongeveer wat je zoekt dan?
Ik heb er even mee gespeeld, wil er zeker nog verder in duiken omdat het er veelbelovend uitziet. Het herhalende werk in de gemiddelde 'simpele' applicatie is wat hiermee geautomatiseerd zou moeten kunnen worden, doordat je je model op een abstract niveau definieert (en met de aansluiting op overige tools van Borland is het zelfs mogelijk je ontwerper aanpassingen aan je model te laten doen die direct vertaald worden naar de schermpjes).