Pratend met andere softwareontwikkelaars merk ik dat er nog veel bedrijven zijn die ze niet of minimaal gebruiken: softwarebibliotheken. En dan bedoel ik een bibliotheek van een derde partij. Soms kom ik zelf ook een dergelijk bedrijf tegen. Hoewel ze in de minderheid zijn en hun aantal langzaam afneemt, is hun aantal, voor zover ik dat kan schatten, nog steeds aanzienlijk. Dat is jammer, want softwarebibliotheken bieden grote voordelen.
In veel bedrijven heerst het 'not invented here'-syndroom. Alles wat niet zelf is ontwikkeld, wordt gewantrouwd en gemeden. Bij een nieuw project wordt alles vanaf de grond opgebouwd. Misschien wordt er af en toe een handig stukje code uit een oud project in het nieuwe project hergebruikt. Een stapje verder zijn de bedrijven met een eigen softwarebibliotheek. Zij weten dat het al veel handiger is om veelgebruikte functies in een of meerdere bestanden te plaatsen zodat deze gemakkelijk opnieuw gebruikt kunnen worden.
Deze bedrijven doen dit ondanks dat voor veel van deze zelfgeschreven software vaak kant-en-klare softwarebibliotheken bestaan die hetzelfde doen. En meestal beter. Voorbeelden zijn er te over: loginsystemen, pdf-generatoren, template-engines, ORM-software, etc. Het zelf ontwikkelen van dergelijke software heeft mogelijk de voordelen van onafhankelijkheid en leerzaamheid, maar de nadelen zijn aanzienlijk.
Zelf ontwikkelde software moet meestal ook zelf worden onderhouden. Functionaliteit moet worden toegevoegd en bugs moeten worden opgelost. Dit kost veel kostbare tijd. Ook het schrijven van documentatie kost veel tijd. Dat laatste wordt vaak nagelaten, wat weer tot gevolg heeft dat de structuur van de code achteruit gaat en moeilijker wordt om mee te werken. Dat leidt weer tot meer fouten en tragere ontwikkeltrajecten. Daarnaast zullen nieuwe teamleden een veel langere inwerktijd hebben.
Aan kant-en-klare softwarebibliotheken werken vaak meerdere ontwikkelaars die zich in specifieke onderdelen hebben gespecialiseerd. Zo zijn er niet alleen ontwikkelaars die bepaalde onderdelen goed kunnen implementeren, maar zijn er ook ontwikkelaars die de software profilen om de snelheid te optimaliseren of bijvoorbeeld opletten dat er geen gaten in de beveiliging ontstaan. Bij veel softwarebibliotheken wordt de kwaliteit hoog gehouden door bijvoorbeeld verplichte codereviews, verplichte unittesten en verplichte documentatie. Vaak is de kant-en-klare softwarebibliotheek de bibliotheek die de ontwikkelaar eigenlijk altijd al had willen hebben.
Voor webontwikkelaars specifiek bestaat er nog een andere reden naast het 'not invented here'-syndroom om geen extrerne softwarebibliotheken te gebruiken. Tot voor enkele jaren geleden bestonden er voor een aantal talen geen goede bibliotheken. Het is pas sinds de laatste paar jaar dat er voor bijvoorbeeld php en javascript echt goede bibliotheken bestaan. Voor javascript zijn dat bijvoorbeeld Dojo en jQuery, voor php zijn dat bijvoorbeeld Zend framework, Symfony en CakePHP. Een webontwikkelaar die al jaren hard werkt om mooie websites te maken, kan het zijn ontgaan dat de wereld om hem of haar heen is veranderd.
Waar moet men op letten bij het kiezen van een softwarebibliotheek? In de eerste plaats dop e functionaliteit, dat spreekt voor zich. Daarnaast kan men kijken naar de documentatie. Deze moet zo volledig en duidelijk mogelijk zijn. Ook belangrijk is dat ze niet verouderd is en synchroon loopt met de softwareversie. Afhankelijk van het doel kan de uitvoersnelheid een belangrijke factor zijn en kan bij javascript de bestandsgrootte bepalend zijn.
Veel bibliotheken hebben een eigen gemeenschap. Hier worden vragen gesteld, nieuwe mogelijkheden voorgesteld en foutrapporten ingediend. Sommige bibliotheken hebben de mogelijkheid dat gebruikers zelf uitbreidingen ontwikkelen en publiceren. Bij het kiezen van een bibliotheek dient het hebben van een actieve gemeenschap zwaar meegewogen te worden.
Een laatste aspect dat goed bekeken dient te worden is de licentie van de bibliotheek. Licenties zijn er in verschillende soorten. Een belangrijke keuze is of voor een open source-bibliotheek wordt gekozen. Ook hierin bestaan weer verschillende varianten. Zo is het niet altijd mogelijk om software die gebruik maakt van een dergelijke bibliotheek zonder meer door te verkopen. Vaak echter hebben open source-bibliotheken een erg vrije licentie. Bibliotheken die niet open software zijn hebben weer andere beperkingen. Het kan raadzaam zijn een deskundige hiernaar te laten kijken.
De voordelen van een softwarebibliotheek van een derde partij zijn fors. Ontwikkelaars kunnen zich bezig houden met het ontwikkelen van software dat belangrijk is voor het bedrijf in plaats van het schrijven van software dat al bestaat. Het onderhouden van een eigen softwarebibliotheek kost erg veel geld. Het zou niet misstaan om voortaan te eisen dat in het technisch ontwerp de te gebruiken softwarebibliotheken worden genoemd en waarom deze worden gebruikt. En vooral, indien niet van softwarebibliotheken van een derde partij gebruikt wordt gemaakt, te eisen dat dit beargumenteerd wordt.
Op zich aardig artikel, maar ik vind het jammer dat er niet naar de keerzijde gekeken wordt.
Ik heb constructies gezien dat er 5% van de bibliotheek gebruikt werd, maar wel de hele bibliotheek geladen/gedistribueerd werd.
Nu ben ik van de oude stempel; op een machine met 16k geheugen moest je nog echt kijken welke instructies je gebruikte anders past het niet eens in het geheugen.
De laatste jaren zie je echter dat, als het niet meer past, er “gewoon” even wat geheugen of diskruimte bijgeprikt wordt. Jammer genoeg wordt er niet gekeken of het programmeren/assembleren beter kan.
Klassiek voorbeeld is windows out of the box: er wordt standaard vanalles en nog wat geladen en geinstalleerd wat je niet of nauwelijks gebruikt. Als alles wat je niet nodig hebt eruit gelaten wordt, is je pc ineens een stuk sneller.
Dito kun je overwegen bij het gebruik van libraries: heb je echt de hele library nodig, of slechts een deel. En kun je dat deel dan geisoleerd gebruiken, of heb je toch de hele library nodig? Dit kan een reden zijn om toch zelf iets te ontwikkelen i.p.v. de hele library mee te nemen.
Libraries en frameworks zijn mij te groot.
Ik moet er niet aan denken dat de hele applicatie afhankelijk is van een bepaalde versie en een bepaalde server-configuratie.
Classes zijn wat anders. Die kun je overal en nergens gebruiken zonder er voor de rest van je leven aan vast te zitten.
Dojo base heeft een omvang van slecht 26k (gzipped) en een geweldig systeem om alleen de benodigde code te laden. Oudere versies worden nog langdurig ondersteund en via tools zoals firebug krijg je ruimschoots van te voren te zien wanneer iets wordt uitgefaseerd. Daarnaast wordt door grote bedrijven waaronder IBM veel aan de ontwikkeling van deze opensource library bijgedragen waardoor continuiteit is verzekerd. En last but not least, Dojo heeft een zeer vrij licentiemodel. Kortom ik kan mij niet vinden in bovenstaande bezwaren.
@Nick
26kb is geen probleem, ben ik met je eens.
Maar kijk voor de aardigheid eens naar .net framework…praten we al snel over 26Mb
En dat is precies wat ik helaas mis in het artikel: bij libraries van 26k ben ik het helemaal met de auteur eens, maar met een .net framework van 26Mb wordt het al snel anders
@PaVaKe, helemaal mee eens. Ik werk uitsluitend met virtuele systemen en heb telkens weer discussies over geheugengebruik van OS en applicaties. Er wordt zo makkelijk gedaan over het bijplaatsen van resources. En dat terwijl juist virtuele systemen het moeten hebben van (onder andere) geheugensharing. Er valt weinig te sharen als men onnodig kostbare resources claimt in machine 1 terwijl machine 2 die eigenlijk zou willen gebruiken. En het gaat dan niet om een of twee machientjes maar om honderden. Tel eens uit wat het kost om 200 keer 10M onnodig te moeten reserveren. Op die manier valt de bodem onder virtualisatie uit omdat het model juist is gebaseerd op sharing.
>> Jammer genoeg wordt er niet gekeken of het programmeren/assembleren beter kan.
Geheugen is zo goedkoop geworden, daar kan een programmeur niet tegenop. Of je moet voor een tientje per uur gaan werken, dan kun je nog eens middagje gaan optimaliseren.
Dat er maar een paar procent van de mogelijkheden wordt gebruikt, dat zie je met vrijwel alle hard- en software. Wie gebruikt er nu alle mogelijkheden van z’n database? Of van z’n pc? Of van z’n noem_maar_wat? Libraries zijn er om snel voor 80% een applicatie te kunnen ondersteunen, een one size fits all. En dat kan flink wat overhead opleveren, maar voor een habbekrats los je dat probleem op door er wat extra hardware tegenaan te gooien. Voor dat geld kun je niet zelf gaan programmeren. Of schrijf je ook je eigen database-server, webserver, etc.?
@Frank
Ik heb een installed base van zo’n 4000 systemen. Dit zijn allemaal high performance, high availability systemen. Het geheugen dat hierin zit is dus niet het geheugen van de pc-boer op de hoek, maar een wat duurdere variant.
Als ik op 4000 machines het geheugen moet vervangen, hangt hier een aardig prijskaartje aan. Niet alleen de prijs van het fysieke geheugen, maar ook de engineers die ik het veld in moet sturen, planning en logistiek van het geheel, afspraken met de klant om de upgrade uit te kunnen voeren etc.
Daarnaast heb ik ook parken gezien waar al het max. aan geheugen inzat, daar had je complete hardware upgrades nodig om sowieso meer geheugen kwijt te kunnen.
@PaVaKe: Hier heb je een goed punt. Zo blijkt maar weer eens dat er altijd een goede kosten baten analyse moet worden gemaakt. Dat geldt dus voor zowel het bijprikken van geheugen als het installeren van een complete library als het zelf ontwikkelen van een library. Wat in de ene situatie de goedkoopste oplossing is, kan bij de andere situatie zomaar de duurste oplossing zijn.
Tja…dot.net. Velen gebruiken het (nog)maar zodra de managers de enorme besparingen ontdekken die tools opleveren zoals Wavemaker Visual Studio (zie http://www.wavemaker.com wat op zichzelf ook weer voor driekwart uit libraries waaronder Dojo bestaat) dan wordt de Microsoft only dictatuur vermoed ik snel los gelaten.
Mbt de opmerking over high performance, high availablitiy. Ik ben geen hardware specialist, maar is google’s load balancing cluster architecture ook niet gebaseerd op reguliere PC’s?