{"id":811,"date":"2017-01-10T11:04:54","date_gmt":"2017-01-10T09:04:54","guid":{"rendered":"https:\/\/www.bartbarnard.nl\/blog\/?p=811"},"modified":"2017-01-11T11:32:24","modified_gmt":"2017-01-11T09:32:24","slug":"bettercodehub","status":"publish","type":"post","link":"https:\/\/www.bartbarnard.nl\/blog\/bettercodehub\/","title":{"rendered":"bettercodehub"},"content":{"rendered":"

Inleiding<\/strong>
\nVoor de ontwikkeling van het nieuwe tweedejaars onderwijs waren we op zoek naar een manier om eenvoudig een redelijk beargumenteerd cijfer te geven op een programmeeropdracht. Tijdens de gesprekken hierover rees het idee om de studenten de kwaliteit van hun code te laten beoordelen en hierop te laten reflecteren. Op die manier zouden ze er niet meer mee wegkomen door eenvoudig iets op te leveren dat werkt, maar zouden ze ook actief iets moeten zeggen over hun code.<\/p>\n

Er zijn verschillende code-analysetools<\/a>, maar de meeste hiervan zijn behoorlijk complex om te installeren<\/a>, vereisen veel administratieve handelingen<\/a>, gaan uit van heel strikte eisen die aan de code gesteld worden, of geven zoveel data<\/a> dat je door de bomen het bos niet meer ziet. Nu was ik al een tijdje in gesprek met mensen van de Software Improvement Group<\/a>, die met het analyseren van broncode hun brood verdienen. Enige tijd geleden heeft Joost Visser<\/a> een praatje gehouden voor ons honoursprogramma<\/a> naar aanleiding van een boekje<\/a> dat hij vorig jaar heeft geschreven. Dit boekje heeft geresulteerd in de bettercodehub<\/a>, een automatisch online analysetool die github-repositories op basis van de tien guidelines<\/em> die Visser in zijn boekje beschrijft.<\/p>\n

Analyse<\/strong>
\nOm eens te kijken hoe deze tool exact werkte, pushte ik mijn funda-harvester <\/a>naar mijn github account en ging naar bettercodehub<\/a>, waar ik hem onmiddellijk tussen mijn andere repositories zag staan. Om de code te analyseren hoefde ik alleen maar op het pijltje rechtsonder te klikken. Nadat ik de standaardconfiguratie had geselecteerd werd er een kloon gemaakt van de repo, die werd geanalyseerd en tenslotte weer verwijderd. Het totale proces duurde ongeveer een halve minuut (nu is die harvester niet heel groot, een kleine duizend regels code, maar evengoed is dit behoorlijk snel).<\/p>\n

De resultaten worden in een overzichtelijk schema getoond, georganiseerd volgens de tien guidelines<\/em> en de score bovenaan (Figuur 1). Je kunt op een guideline<\/em> klikken om de details van de analyse te zien. Aan de linkerkant krijg je dan een beschrijving van de betreffende guideline<\/em> te zien, en aan de rechterkant de resultaten van de analyse. In Figuur 2 is te zien hoe de harvester scoorde op het onderdeel ‘complexiteit’. De grafiek onderaan geeft de totale score van de code-base weer, en de teksten eronder zijn hyperlinks waarmee je de betreffende classen in het bovenste deel kunt laten zien. Deze klassen zijn op hun beurt weer hyperlinks naar de code van de refactoring candidates<\/em> zelf. Zo zie je bijvoorbeeld in Figuur 3 dat hier nog een refactoring mogelijk is, omdat er een TODO<\/em> in productiecode staat.<\/p>\n

\"1.overzicht\"<\/a>

Figuur 1: overzicht van de resultaten.<\/p><\/div>\n

\"2.simple_units_code\"<\/a>

Figuur 2: het detail-scherm van \u00e9\u00e9n van de tien guidelines.<\/p><\/div>\n

\"3.codevoorbeeld\"<\/a>

Figuur 3: een refactor candidate met de betreffende regel gearceerd.<\/p><\/div>\n

Nadat je deze analyse hebt bekeken kun je onderdelen hiervan op je takenlijst zetten. Deze lijst komt dan weer terug op je dashboard, wat direct als input voor je retrospective<\/em> kan fungeren of je nieuwe actielijst kan defini\u00ebren. Nadat je deze wijzigingen hebt ingevoerd en je een nieuwe push naar github doet kun je de analyse herhalen en zie je gelijk de verbeteringen in de analyse terugkomen. Het idee van bettercodehub is dat het op die manier een inherent onderdeel wordt van de productiecyclus.<\/p>\n

\"4.tasklist\"<\/a>

Figuur 4: de resultaten met een hoeveelheid taken die daaruit naar voren is gekomen.<\/p><\/div>\n

Nadat ik mijn eigen code had geanalyseerd, heb ik ook nog even een studentenuitwerking van een tweedejaars project geanalyseerd (een project dat qua lines of code vergelijkbaar is met de harvester). Zoals blijkt uit Figuur 5a en b scoort deze code op een aantal onderdelen minder goed dan mijn code. Op basis van die soort vergelijkingen kun je dus redelijk gefundeerd stellen dat de ene code beter is dan de andere \u2013 wat zich weer kan laten vertalen in een cijfer.<\/p>\n

\"5a.overzicht_harvester\"<\/a>

Figuur 5a: overzicht en score van de funda-harvester.<\/p><\/div>\n

\"5b.overzicht_studenten\"<\/a>

Figuur 5a: overzicht en score van een studentenproject.<\/p><\/div>\n

Conclusie<\/strong>
\nDeze bettercodehub<\/a> heeft een aantal voordelen boven de meer traditionele analysetools. Allereerst is het online en gekoppeld aan github, dus het aan de praat krijgen hiervan kost eigenlijk geen tijd. Een ander groot voordeel is dat je niet wordt doodgegooid met allerlei details en rode lijntjes, zoals bijvoorbeeld met metrics for Eclipse het geval is. Tenslotte geeft het direct feedback met mogelijke refactoring-slagen, waarbij je op eenvoudige manier input kunt krijgen voor je retrospective. Al met al is dit de beste automatische analysetool die ik ken.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Inleiding Voor de ontwikkeling van het nieuwe tweedejaars onderwijs waren we op zoek naar een manier om eenvoudig een redelijk beargumenteerd cijfer te geven op een programmeeropdracht. Tijdens de gesprekken hierover rees het idee om de studenten de kwaliteit van hun code te laten beoordelen en hierop te laten reflecteren. Op die manier zouden ze<\/p>\n

Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[19],"tags":[],"_links":{"self":[{"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/posts\/811"}],"collection":[{"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/comments?post=811"}],"version-history":[{"count":2,"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/posts\/811\/revisions"}],"predecessor-version":[{"id":819,"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/posts\/811\/revisions\/819"}],"wp:attachment":[{"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/media?parent=811"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/categories?post=811"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bartbarnard.nl\/blog\/wp-json\/wp\/v2\/tags?post=811"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}