Het gebruik van third party code, de voor- en nadelen

Door Sjoerd Maessen, lead software engineer
3 april 2012 - 998 x bekeken -

Wat is third party code?

Soms komt de vraag vanuit een klant om bijvoorbeeld een bepaalde koppeling te realiseren met een bestaand pakket. Op dit moment zul je als developer eerst de technische documentatie opvragen van die koppeling om te bepalen hoeveel werk het zal zijn om de koppeling tot stand te brengen. Op welke manier werkt de koppeling, is dit via REST, FTP, SOAP of op een andere manier? Hoe vaak draait de koppeling en wat gebeurt er als de koppeling niet draait op het moment dat hij moest draaien? Wordt de data dan later opnieuw verzonden of moet er andere actie op worden ondernomen? Er komt heel wat bij kijken. In sommige gevallen is er reeds een library beschikbaar om de koppeling tot stand te brengen. Een library is simpelweg een verzameling van code die een bepaald doel heeft, bijvoorbeeld in het voorzien van een koppeling. Een dergelijke library kan door de community beschikbaar gesteld zijn of door de partij die koppeling voorziet. Op dat moment spreken we van third party code of een third party code library.

Een ander voorbeeld van een third party library is het gebruik van opensource frameworks of content management systemen zoals Symfony2, Zend Framework, Joomla, Drupal, Concrete 5,… Het gebruik van frameworks en bestaande CMS'en kan een enorm hulpmiddel zijn bij het uitwerken van een bepaald project. Er zijn echter ook een aantal valkuilen waar rekening mee gehouden moet worden.

De auteur van de code 

Het is belangrijk om te weten wie er achter de code zit die je gaat gebruiken. Is deze persoon, organisatie of partij wel te vertrouwen? Een voorbeeld is een Facebook koppeling. Er zijn op internet een hoop libraries te vinden die voorzien in het opzetten van een koppeling. Echter verschilt de code van kwaliteit.

Belangrijker is nog dat het bij sommige bronnen niet duidelijk is wat er allemaal in de code gebeurt. Wat gebeurt er bijvoorbeeld met onze data die we ophalen en versturen, wordt deze niet onderschept door een andere partij? Bij grote libraries is het al snel veel werk om de gehele interne werking van de library te begrijpen. Een ander voorbeeld is een koppeling met Google Analytics. Worden onze statistieken ook niet gebruikt door een andere partij om hiermee een inzicht te krijgen in andere websites?

Updates 

Bij het gebruik van third party code moet er goed worden gekeken naar updates. Het is zeer aannemelijk dat wanneer er een kritisch veiligheidslek wordt gevonden in bijvoorbeeld Drupal een kwaadwillende programmeur een geautomatiseerd script zal schrijven die hier misbruik van maakt. Zo kan het script Drupal installaties die kwetsbaar zijn voor deze specifieke exploit, defacen of zelfs offline halen. Interessant is dan om te weten hoe snel de auteur van de code of iemand anders een patch instuurt om dit probleem te verhelpen, waardoor je als developer eenvoudig kunt updaten en grote problemen kunt voorkomen. Daarbij komt meteen het feit dat het onmogelijk is om nu een CMS installatie klaar te zetten en hier vervolgens nooit meer naar om te kijken. Hoewel de CMS'en en frameworks van tegenwoordig steeds betrouwbaarder worden blijven er risico's aan het gebruik ervan verbonden. Zo bleek ook laatst nog bij PLESK, een softwarepakket om servers te beheren via een webinterface. Het lek werd ontdekt en binnen de korte tijd gebruikt om een DDOS attack mee uit te voeren.

Geen of slechte documentatie

Indien een stuk "vreemde code" niet direct uitwijst hoe het gebruikt dient te worden is het als developer erg handig om terug te kunnen vallen op de documentatie van het pakket. Dit kan documentatie in de code zijn maar ook eventuele flowcharts en diagrammen die de globale werking duidelijk maken. Als er dergelijke documentatie voorhanden is, inclusief code voorbeelden, dan versnelt dit de implementatietijd aanzienlijk. Ook andere problemen zijn op deze manier makkelijker te traceren en op te lossen. Is de auteur van de code bereikbaar voor vragen of is er een actieve community bij wie je terecht kunt? En wat is de taal van de comments, Engels, Nederlands of is het een vreemde taal?  

Code stijl

 Hoewel dit niet echt een probleem is kan het wel zorgen voor wat vertraging. Iedere developer heeft een favoriete of eigen manier van het schrijven van code. Een professioneler pakket heeft afspraken gemaakt over de code die het bevat, de whitespace in de code. Is dit met tabs of met spaties, en prefixen we codevariabelen of niet. Er zijn echter ook voorbeelden waarbij libraries bestaan uit soms honderden bestanden die niet uniform zijn qua stijl. Bij E-sites werken met de Hungarian notation. Dit is een notatie waarbij de variabelen worden geprefixed met het type. Zo is een array altijd geprefixed met a, bijvoorbeeld $aCars. De Hungarian notation komt echter niet heel veel voor en daarom is de kans klein dat een pakket hierbij aansluit. Een zelfde notatie in alle code zorgt voor meer leesbaarheid en is makkelijker en sneller te begrijpen als developer. Zoals eerder gezegd hoeft dit niet echt een probleem te zijn maar kan het wel een bron van ergernis gaan vormen. 

Verschillende platformen

Het is goed mogelijk dat third party code eisen stelt aan de omgeving waar het draait. Denk hierbij aan bijvoorbeeld de MySQL of PHP versie. Ook kunnen er afhankelijkheden zijn naar Google V8, ImageMagick of anderen… Ook hierbij kan je tegen problemen aan lopen. Wat als je eigen product een andere versie nodig heeft van ImageMagick dan je third party library? Of nog erger; dat er eisen worden gesteld aan de PHP versie waaraan je niet kan voldoen omdat het pakket te oud is en je huidige PHP installatie niet volledig backwards compatible is, waardoor het niet meteen out of-the-box werkt.

Class name collisions

Hoewel PHP ondersteuning biedt voor namespaces is dit nog relatief nieuw. Namespaces zorgen er voor dat het makkelijker is om verschillende stukken eigen of third party code naast elkaar te draaien. De wat grotere pakketen ondersteunen tegenwoordig allemaal namespaces maar toch is de kans is groot is dat de third party code die je wilt gebruiken geen gebruik maakt van een namespace. Dit kan er voor zorgen dat de third party class names gebruikt die botsen met de classes die je zelf ook al gebruikt (waardoor het niet werkt).

Conclusie

Wegen de voordelen op tegen de nadelen? Third party code kan een hoop tijd besparen mits er dus een actieve developer of community achter zit die zorgt voor goede documentatie, updates en bereikbaar is voor uitleg bij problemen. Is dit niet het geval dan is de kans groot dat de keuze voor third party code je een keer opbreekt en je de functionaliteit misschien wel beter in-house had kunnen ontwikkelen. Bijvoorbeeld sitemanager5, dit is ons CMS dat we dagelijks intern ontwikkelen. Hierdoor zijn we perfect op de hoogte van de interne werking, verzorgen we zelf de updates, past het prima binnen onze eigen code stijl, en zijn we in staat om makkelijke nieuwe functionaliteit toe te voegen of om eventuele problemen te verhelpen.


"Zou moeten werken"

Door E-sites

Kwaliteit is erg belangrijk, maar testen is ook erg saai. Dat klinkt als een probleem; gelukkig hebben we ook een oplossing. - Lees meer

Lees verder