Software framework

De ontwerpers van softwareframeworks willen de ontwikkeling van software vergemakkelijken door ontwerpers en programmeurs in staat te stellen hun tijd te besteden aan het voldoen aan de software-eisen in plaats van zich bezig te houden met de meer standaard details op laag niveau om een werkend systeem te leveren, waardoor de totale ontwikkelingstijd wordt verkort. Zo kan een team dat een webframework gebruikt voor de ontwikkeling van een bankwebsite zich concentreren op het schrijven van specifieke code voor bankieren in plaats van op de mechanica van request handling en state management.

Frameworks vergroten vaak de omvang van programma’s, een fenomeen dat “code bloat” wordt genoemd. Als gevolg van de door de klant gestelde eisen aan applicaties, komen soms zowel concurrerende als complementaire frameworks in een product terecht. Door de complexiteit van hun API’s is het bovendien mogelijk dat de beoogde vermindering van de totale ontwikkelingstijd niet wordt bereikt, omdat extra tijd moet worden besteed aan het leren gebruiken van het framework; deze kritiek is duidelijk geldig wanneer een speciaal of nieuw framework voor het eerst wordt gebruikt door het ontwikkelingspersoneel. Als zo’n raamwerk niet wordt gebruikt in volgende opdrachten, kan de tijd geïnvesteerd in het leren van het raamwerk meer kosten dan doelgericht geschreven code die bekend is bij de projectmedewerkers; veel programmeurs bewaren kopieën van nuttige boilerplate voor veel voorkomende behoeften.

Hoewel, als een raamwerk eenmaal is geleerd, kunnen toekomstige projecten sneller en gemakkelijker te voltooien zijn; het concept van een raamwerk is om een one-size-fits-all oplossing te maken, en met bekendheid, zou de codeproductie logischerwijs moeten stijgen. Er worden geen beweringen gedaan over de omvang van de code die uiteindelijk met het eindproduct wordt gebundeld, noch over de relatieve efficiëntie en beknoptheid ervan. Het gebruik van een bibliotheekoplossing leidt noodzakelijkerwijs tot extra’s en ongebruikte vreemde elementen, tenzij de software een compiler-object linker is die een strakke (kleine, volledig gecontroleerde en gespecificeerde) uitvoerbare module maakt.

Het probleem blijft bestaan, maar meer dan tien jaar ervaring in de industrie heeft aangetoond dat de meest effectieve raamwerken die blijken te zijn die zich ontwikkelen uit het her-factureren van de gemeenschappelijke code van de onderneming, in plaats van een generiek “one-size-fits-all” raamwerk te gebruiken dat door derden is ontwikkeld voor algemene doeleinden. Een voorbeeld hiervan zou zijn hoe de gebruikersinterface in een applicatiepakket als een office suite groeit naar een gemeenschappelijke look, feel, en attributen en methoden voor het delen van gegevens, naarmate de ooit ongelijksoortige gebundelde applicaties zich verenigen tot een suite die strakker en kleiner is; de nieuwere/geëvolueerde suite kan een product zijn dat integrale utility bibliotheken en gebruikersinterfaces deelt.

Deze trend in de controverse brengt een belangrijke kwestie over frameworks naar voren. Het maken van een elegant framework, in tegenstelling tot een framework dat slechts een probleem oplost, is nog steeds eerder een ambacht dan een wetenschap. “Software elegantie” impliceert duidelijkheid, beknoptheid, en weinig verspilling (extra of extraneuze functionaliteit, waarvan een groot deel door de gebruiker gedefinieerd is). Voor die raamwerken die code genereren, bijvoorbeeld, zou “elegantie” de creatie van code impliceren die proper en begrijpelijk is voor een redelijk ervaren programmeur (en die dus gemakkelijk aanpasbaar is), tegenover één die enkel correcte code genereert. Het probleem van de elegantie is de reden waarom relatief weinig software frameworks de tand des tijds hebben doorstaan: de beste frameworks zijn in staat geweest om elegant te evolueren naarmate de onderliggende technologie waarop zij gebouwd waren evolueerde. Zelfs daar zullen veel van dergelijke pakketten, na te zijn geëvolueerd, legacy mogelijkheden behouden die de uiteindelijke software opzwellen omdat anders vervangen methoden zijn behouden in parallel met de nieuwere methoden.