Development

Software-ontwikkeling
Code cleaning

Grote schoonmaak in open source

Vandaag start Better Code Hub, een nieuw codetestplatform op GitHub.

© CC0 - Pixabay
13 december 2016

Vandaag start Better Code Hub, een nieuw codetestplatform op GitHub.

De introductie van Better Code Hub vandaag, krijgt begin volgend jaar een vervolg met Spring Cleaning, een initiatief gericht op de inzet van zo veel mogelijk ontwikkelaars bij een wereldwijde verbeterslag in open source.

Bij open source wordt er doorgaans van uitgegaan dat de code beter en veiliger is omdat er zo veel ontwikkelaars de mogelijkheid hebben deze te controleren en te verbeteren. Toch is de procedure niet waterdicht. Pijnlijke voorbeelden waarbij de beveiliging in het geding was, zijn wel bekend, zoals HEARTBLEED en POODLE. Om de grootste beveiligingsmissers in OpenSSL er uit te halen is het Core Infrastructure Initiative opgezet. Maar er is veel meer open source code die niet optimaal is wat betreft efficiëntie, onderhoudbaarheid en veiligheid. 

Spring Cleaning moet in het voorjaar een begin maken wereldwijd verandering te brengen in die situatie. Code wordt in behapbare stukken opgedeeld en ontwikkelaars worden uitgenodigd deze te controleren en te verbeteren.

Het initiatief is onderdeel van de introductie van Better Code Hub, een codetestplatform dat vandaag officieel uit de bètatestfase komt. Het platform is een gezamenlijk initiatief van GitHub en de Software Improvement Group (SIG). Het platform biedt ontwikkelaars een testtool dat is gebouwd rondom de tien richtlijnen uit het boek 'Building Maintainable Software' van professor Joost Visser, directeur Research bij SIG en hoogleraar aan de Radboud Universiteit.

Tool

De testtool van Better Code Hub zetten codemetrieken in om onder meer coderegels te tellen en een analyse maken van de complexiteit van de code. Er vindt bijvoorbeeld controle op duplicatie plaats en op de koppeling met modules. Die analyse resulteert in een getalsmatige vertegenwoordiging van de codebasis. Die getalsmatige verhouding kun je dan weer gebruiken voor een benchmark met andere code. Juist die benchmark is een van aspecten die de tools van Better Code Hub onderscheid van de andere statische testtools, zegt Michiel Cuijpers, product owner van Better Code Hub bij SIG. "Bij veel testgereedschap ontstaat vaak ruzie over de 'thresholds'. Dat is contraproductief. Je moet niet zelf proberen te bepalen wat de juiste waarden zijn, maar een vergelijking maken met het werk van anderen."

De tool van Better Code Hub is door zo'n 350 ontwikkelaars in een bètatest aan de tand gevoeld. Sinds de lancering in december is de Better Code Hub gratis toegankelijk voor wie werkt aan openbare projecten.

De 10 regels die in de tools zijn verwerkt:

- Schrijf code in korte eenheden
In de regel moet software makkelijk op te delen zijn in units. Een unit mag - enigszins afhankelijk van de programmeertaal - uit niet meer dan 15 regels code bestaan.

- Schrijf simpele code-eenheden
Het aantal punten waarop het uitvoeringsverloop van het programma kan wisselen (‘branch points’) niet hoger dan vier per unit. Wanneer er meer nodig zijn is het beter de betreffende component of subroutine op te splitsen.

- Schrijf code maar één keer
Code dupliceren betekent een dubbele kans op bugs en levert twee keer zo veel onderhoud op

- Hou de interfaces tussen eenheden eenvoudig
Kleine interfaces maakt hergebruik eenvoudiger

- Een taak per eenheid
Werk waar mogelijk elke taak uit in een aparte unit

- Zorg voor onafhankelijke architectuurcomponenten
De onafhankelijkheid zorgt voor eenvoudiger onderhoud

- Zorg voor juiste balans tussen architectuurcomponenten
Door een logische opzet van de architectuur is het makkelijker componenten terug te vinden

- Codeer zuinig
Een kleine codebasis maakt onderhoud makkelijk

- Automatiseer de tests
Het automatiseren van tests maakt het mogelijk veel te testen. Daardoor neemt de kans op bugs af.

- Schrijf schone code
Ruim rommel op, doe niet aan quick and dirty, schrijf korte maar duidelijke commentaren, ga netjes om met uitzonderingen.

De regels moeten overigens in samenhang worden toegepast, meent Cuijpers. "Er blijven altijd stukjes code die moeilijk onderhoudbaar zijn. Bij te strikt toepassen van de regels -  zonder gebruik te maken van tolerantieniveau's - dreigt het gevaar dat ontwikkelaars het gereedschap naast zich neer leggen. Maar er is een omslagpunt. Is de code complexer dan dat punt neemt de complexiteit in de loop der tijd steeds verder toe. Het doel is juist om technical wealth te creëren en niet alleen maar technical debt weg te werken. Dus is het belangrijk het omslagpunt te kennen en daarvan weg te sturen."

De Spring Cleaning dient echter nog een ander doel. Er zijn inmiddels vele duizenden ontwikkelaars die werken open source software. De groep is echter allerminst homogeen. Naast een beperkt aantal 'cracks' met grote reputatie, zijn er vele duizenden ontwikkelaars die eigenlijk niet zo goed durven om verbeteringen aan grote projecten te suggereren. Ze leiden aan wat wel het 'fear of touching code'-syndroom wordt genoemd. Hun reputatie valt in het niet bij die van de project-eigenaren, vaak een van de opensource-cracks. Bovendien - ook al zouden ze die angst overwinnen - weten ze vaak niet waar te beginnen. 

Eigen kwaliteit etaleren

Better Code Hub biedt een manier om de eigen reputatie te vergroten en zichtbaar te maken. Wie zijn projecten analyseert, kan op zijn of haar profielpagina een gekleurd strookje (een 'badge') plaatsen. Deze badge geeft de score van het project en en daarmee de kwaliteit van het geleverde werk van de betreffende ontwikkelaar. In de Spring Cleaning krijgen ontwikkelaars hun brokjes code toegewezen om te verbeteren, dus het keuzeprobleem waar te beginnen is er niet meer. Door flink wat code te analyseren en goede verbeteringen voor te stellen aan de projecteigenaar via de GitHub-workflow, kunnen ze via de badge aantoonbaar hun status verbeteren. Dat levert naar verwachting uiteindelijk een grotere dynamische groep actieve ontwikkelaars op. 

Maar ook voor potentiële opdrachtgevers kan het badge-systeem een waardevolle toevoeging zijn. Steeds vaker stellen organisaties teams van onafhankelijke ontwikkelaars samen voor specifieke onderdelen van een project waar ze aan werken. GitHub spreekt in dat geval over 'innersourcing'. Zalando en Netflix zijn bedrijven die deze strategie al enige tijd toepassen. Voor hen is GitHub ook een Human Resource gereedschap. Anders dan op LinkedIn kunnen ontwikkelaars op GitHub niet hun prestaties mooier laten zijn dan ze zijn. Alle openbare projecten zijn immers voor iedereen te zien. De badges op de profielpagina's kunnen behulpzaam zijn bij het vinden van de juiste kandidaten. 

Doorstroming naar
closed source projecten

SIG hoopt dat het werk dat is verzet voor het ontwikkelen Better Code Hub zich uiteindelijk terugbetaald via het bedrijfsleven. GitHub wordt namelijk niet alleen gebruikt voor het ontwikkelen van open source software. In toenemende mate zetten organisaties het platform in om gesloten, bedrijfseigen software te ontwikkelen. Zo kunnen hun ontwikkelaars gebruikt maken van de workflow en de tools waar ze aan gewend zijn vanuit hun open source werk. SIG verwacht dat ze ook zullen willen werken met de tool van Better Code Hub in de bedrijfseigen, gesloten projecten. Hun opdrachtgevers kunnen daarvoor dan gebruik maken van een betaald licentiemodel.

Lees meer over
Zie ook Development op AG Connect Intelligence
2
Reacties
Paul 13 december 2016 15:55

Ik spendeer veel tijd in bestuderen, gebruiken, toevoegen en ontwikkelingen in open source. Een goed initiatief om naar de kwaliteit te kijken. Echter hoewel men stelt uitzonderingen worden toegestaan, lijkt me dat het meer-en-deel een uitzondering wordt, want (bijna) geen enkele open source code voldoet niet aan de meeste van deze regels. Enige vorm van de commentaar is vaak totaal afwezig, en het is dus een enorme puzzel om te begrijpen hoe en waarom e.e.a. werkt. Veel code, veel rommel, een wirwar van veel routines die slechts van een plaats worden. Daardoor is het erg moeilijk om, zonder heel veel tijd te investeren, iets aanpassen en mee te helpen met verdere ontwikkeling. Je vindt derhalve ook heel veel oude code, die niet meer wordt onderhouden en veel verschillende code/programma's die allemaal hetzelfde doen omdat opnieuw ontwikkelen makkelijker is.( maar dan ook weer niet onderhouden). Dat is niet echt de gedachte achter open source . Laten wij hopen dat dit initiatief echt helpt, maar vraag me wel af hoeveel er over gaat blijven....

F.J.M.Cuijpers… 13 december 2016 14:29

De gecompliceerdheid van de moderne (software)wereld is bekend. De kunst is om in een jargon dat inmiddels het predicaat 'taal' verdient, deze complexiteit te verkleinen voor de gebruikers, waartoe inmiddels het grootste deel van de wereldbevolking behoort. Zijnde een lid van die wereldbevolking, zal ik de teksten van Cuijpers moeten doorgronden, en de follow-up van zijn werk eveneens moeten doorgronden. Gelieve mij ook die toekomstige teksten toe te zenden. Gr.

Reactie toevoegen