Met grote regelmaat rij ik 's avonds langs het nieuwe kantoor van mijn eerste werkgever in de ict. Aan het einde van de jaren tachtig werkte ik er als softwareontwikkelaar op MS-Dos pc’s. Van Windows 3.1 hadden we nog niet gehoord en op mijn bureau stonden twee pc’s: één om te ontwikkelen en één om te testen. De belangrijkste knop was de reset-button op je pc; die kennen we nu niet meer. Een leuke en leerzame tijd was het, ik kijk er met plezier op terug.
Van de ontwikkelaars werd ook toen al hoge productiviteit verwacht, dus veel code produceren, met weinig fouten. Om dit mogelijk te maken werd ook toen al gewerkt met bibliotheken van standaard code-componenten, en met 'runtime environments' waarmee standaard functionaliteit werd afgedekt. Dit alles om zo snel mogelijk te kunnen werken, met zo min mogelijk herhaald werk. Een andere mogelijkheid was het deels genereren van programmacode, in plaats van het invoeren ervan door een programmeur. Dit werd alleen voor het opbouwen van zogenaamde 'skeletcode' toegepast; een generiek raamwerk voor de programmacode, waarbinnen je als programmeur vervolgens maatwerk aanbracht. Werkte prima als versneller, maar telkens eenmalig. Zodra het maatwerk was toegevoegd, kon je niet nog eens genereren, anders was je alles weer kwijt.
De druk om in korte tijd zoveel mogelijk foutloze code op te leveren geldt tegenwoordig nog steeds, en codegeneratie komt steeds vaker voor. Scheelt tijd en geld, daarmee uiterst waardevol. Door het hogere tempo wordt prototyping mogelijk gemaakt, en de standaardisatie van code zorgt voor een lagere testinspanning.
Het genereren zelf wordt gedaan door de generator, een programma wat het ‘domme standaard werk’ door de programmeur vervangt. De essentie is telkens hetzelfde: configureer de generator voor wat er nodig is, druk op een knop en genereer de generieke code en zorg vervolgens voor een logische scheiding tussen deze code en het maatwerk, zodat er een herhaalbaar en beheersbaar ontwikkelproces ontstaat. Immers, maatwerk wil je maar één keer bouwen, generieke code wil je herhaaldelijk opnieuw kunnen genereren. Binnen ons bedrijf zijn we sinds een tijd bezig met een eigen generator, in dit geval voor datawarehouse-nieuwbouw. Werkt behoorlijk goed, en scheelt veel tijd en geld in projecten.
Tegelijk merk ik dat veel bedrijven nog ‘ouderwets’ blijven programmeren, binnen de traditionele waterval en code-libraries. De keuze voor een innovatieve ontwikkelmethode als generatie is moeilijk, het oude handwerk lijkt men maar moeilijk op te geven.
Beste lezer, ik ben benieuwd, wat is jouw beeld? Is code generatie hot or not?
Ik verbaas me er ook iedere dag weer over dat het genereren van code geen gemeengoed is geworden. In de tweede helft van de jaren 80 ontwikkelde ik ook op MS-DOS pc’s maar gebruikte daar toen de DSA COBOL & Pascal Generatoren voor (er was ook nog een C generator, maar die heb ik nooit gebruikt). Je kon een complete applicatie op deze wijze genereren, eigen code werd door de generator automatisch tussengevoegd, dus het onderhoud bleef op deze wijze mogelijk. Vandaag de dag werk ik met Java. Wie kan er mij één generator noemen die kan wat DSA toen deed op een simpele MS-DOS machine? Ze zijn er gewoon niet, het is allemaal half werk wat er geleverd wordt. Ik heb nog nooit zoveel code zelf moeten schrijven als nu. Een gemiste kans, jammer!
Code generatie komt goed van pas waar veel sprake is van zogenoemde boilerplate code. Code die geen inhoudelijke functionaliteit toevoegt maar eerder het raamwerk waarin de functionaliteit gehangen kan worden.
Kijken we naar (het voorbeeld van Rene) enterprise java dan zien we dat heel veel boilerplate code niet meer door een developer uitgevoerd hoeft te worden. Veel wordt achter de schermen al voor de ontwikkelaar uitgevoerd door de applicatie server zelf. Daarnaast zijn er frameworks zoals (jboss) seam die er voor zorgen dat je je als ontwikkelaar kunt focussen op louter de business logica van je applicatie. Veel van deze handigheidjes gebeuren veelal door code generatie.
Ik vind het dus vreemd om te stellen dat code generatie geen gemeengoed is. De vorm is anders dan de ‘oude’ code-generatie (geen generator waar je UML modellen doorheen jast) maar als je goed kijkt ……..
@Joao,
Kun je voorbeelden noemen van taken die de applicatie server overneemt van (programmeren binnen de) applicatie zelf ?
Ik ben er niet sceptisch over, maar ben gewoon benieuwd.
M.a.w. wat zijn de voordelen van een tomcat/java oplossing voor een webtoepassing t.o.v. een Perl/CGI of PHP oplossing ?
Ja ik herken dit ook. Als ex-programmeur hoop je dat je oude vakgebied een bepaalde ontwikkeling doormaakt. Nu zijn er wel degelijk ontwikkelingen, maar die liggen m.i. vooral op het vlak van aansluiten op de nieuwste Windows componenten en user interface. Dat waren dingen die vroeger niet spannend waren omdat ze redelijk eenvoudig waren. Maar ja, tegenwoordig met die componenten bibliotheken, kan dat dan toch ook niet moeilijk zijn. Wat ik sterk merk is dat het “Not invented here” syndroom nog flink rond gaat. Laat twee programmeurs naar een programma kijken en de ander zal altijd zeggen: o, dat kan ik slimmer. Men laat het dan niet bij die opmerking, maar men gaat het nog doen ook. Maar qua ontwikkelingsversnelling is er nog weinig nieuws onder de zon. Nog sterker ik denk dat het alleen maar achteruit gaat. Waar blijven de 5Gl’s en de 6Gl’s? 15 jaar gelden geloofden we werkelijk dat nu onderhand geen programmeurs meer nodig zouden zijn, maar dat gebruikers hun eigen programmas zouden configureren met enkele gesproken commando’s. Waar zijn de dromen? Dromen de nieuwe ontwikkelaars nog?
Code-generatie kun je – mijn inziens – alleen toepassing op “kant-en-klaar”s (meestal office) scenarios’ Robert.
Met Code_Generation kunt er idd lekker snel mee prototypen, vele code_meters maken in een korte tijd.
Echter wanneer het aankomt op niet-standaard scenarios (bijv.highperformance computing, fine-tuning, load-balancing, paralelle-processing is toch inhoudelijk verstand van de gebruikte algoritmes en de tips and tricks van de code_language_being_used van uitermate groot belang. Dan komt toch (weer) de ervarings-gebaseerde handwerk van de coding_vakman om de hoek kijken! Volgens mij is een gezonde mix van template_code en handgeschreven_code het ideale middel om je produkten gerealiseerd te krijgen.
Hoe graag je het ook zou willen, je kun niet alles automatiseren 😉 ICT blijft mensenwerk.