Continuous Integration: meten is weten


1 juni 2011 - 821 x bekeken -

Continuous Integration: meten is weten

Ten aanzien van code proberen we altijd een zekere kwaliteit na te streven. Maar het is ondoenlijk om altijd elkaars code te controleren. Om toch het e.a. aan kwaliteitscontrole kunnen doen zijn er verschillende tools beschikbaar die dit proces tot op zekere hoogte automatiseert, deze zijn bekend onder de noemer "Continuous Integration" tools. Ook bij E-sites zijn we hiermee aan de slag gegaan met behulp van Jenkins (http://jenkins-ci.org) om nog betere code op te leveren.

Wat kan er dan zoal worden geautomatiseerd mbt codereviews?

1. PHP codesniffer. Binnen E-sites hanteren we onze eigen coding standaarden zodat we heldere code schrijven voor elkaar. Zo hebben we afspraken gemaakt over indenting, formatting, naamgeving enz. Dat lijkt soms muggenziften, maar het komt de leesbaarheid van code ten goede. Zo zal andermans code al vlug vertrouwd aanvoelen en is het dus makkelijker/sneller om aanpassingen hierin te maken. Meer info op http://pear.php.net/package/PHP_CodeSniffer/

Coding standard violations trend

2. PHPMD. Naast coding standards zijn er ook zgn. code metrics. Deze controleren en valideren de code op bepaalde best practices. Bijv een ongebruikte private/protected member variabele binnen een class kan hoogstwaarschijnlijk verwijderd worden. Of een methode zoals "getValidEmail($sEmail)" die een boolean returned om het adres te valideren zal ook opgemerkt worden met de melding dat het beter is om deze methode "isValidEmail" te noemen. Op deze manier worden we scherp gehouden om code zonder overbodige ballast op te leveren. Minder code = minder kans op fouten. En het bevordert de leesbaarheid ervan. Meer info op http://phpmd.org/


Metric violations trend


3. Duplicate Code Detection. Ook wel copy paste detection. Deze optie vind mogelijke dubbele code die wellicht gekopieerd is van een bestaand stuk code dat daarna minimaal is aangepast voor een stukje maatwerk. Vaak is het beter om de bestaande functie uit te breiden met een extra parameter om hetzelfde te bereiken, of kan een "parent::call" gedaan worden waarbij vooraf of achteraf het maatwerk geïmplementeerd kan worden. Bottom line is dat dubbele code ook dubbele fouten oplevert en dus een hoge onderhouds factor heeft wat we juist proberen te voorkomen. Meer info op http://pear.phpunit.de/

Duplicate code trend

4. PHPUnit en code coverage. Dit heeft vrijwel alles te maken met "Backwards compatibility". Hoe kan ik mijn code veilig aanpassen zonder bestaande functionaliteit kapot te maken? Hiervoor kunnen zgn unit tests geschreven worden. Unit tests zijn kleine stukjes code die je productie code testen. Je kan bijvoorbeeld een methode schrijven als "function isValidEmail($sEmail)" waarin een e-mail adres gevalideerd wordt. Wanneer je een unittest schrijft is het van belang dat zoveel mogelijk scenario's getest worden, in dit geval is dat dus testen met een geldig en een ongeldig e-mail adres. Dus in de unittest zal waarschijnlijk iets staan als:

$bReturn = $oEmail->isValidEmail("test@E-sites.nl"); // return true
$this->assertTrue($bReturn);
$bReturn = $oEmail->isValidEmail("@E-sites.nl"); // return false
$this->assertFalse($bReturn);

Alleen in dat geval weet je zeker dat alle inhoud van deze functie getest wordt en overeenkomt met de verwachtingen (assert functies). Naast een overzicht van de succesvolle en gefaalde tests geeft Jenkins ons ook een overzicht van de zgn. "code coverage". De code coverage geeft in percentages aan hoeveel code van de hele codebase daadwerkelijk getest is. Idealiter zou deze dus op 100% moeten staan, maar is wellicht praktisch gezien niet altijd haalbaar. Meer info op http://pear.phpunit.de/



Code coverage grafiek

5. PHPDepend. Tot slot zijn er nog enkele statistieken die gegenereerd kunnen worden mbt de codebase. Bijv. het aantal classes, aantal regels, aantal methodes, etc. Maar ook hun onderlinge ratio's. De praktijk leert dat hier een ideaalcurve in bestaat waarbij duidelijk wordt welke ratio's laag, gemiddeld en hoog zijn. De resultaten hiervan zijn natuurlijk nooit sluitend met de praktijktoepassing van een applicatie, maar het kan wel belangrijke sturingsinformatie zijn voor toekomstige architecturele beslissingen in een applicatie die met name voor de lange termijn een positief effect hebben op de life cycles van een applicatie. Meer info op http://pdepend.org/


Conclusie
Voor E-sites is het een waardevolle aanvulling op onze "quality & assurance" voor development, wat door zijn efficiency uiteindelijk de klant ten goede komt. Jenkins geeft ons een totaal overzicht in de vorm van cijfers, grafieken en per bestand gevonden markeringen. Een aantal onderdelen kunnen hard onderverdeeld worden in goed en fout, bijv voor het slagen van alle unittests is het essentieel dat deze 100% is. Maar een gevonden violation voor bijv een naamgeving van een method kan niet altijd als "fout" gemarkeerd worden. Daarom kan continuous integration wellicht beter gezien worden als een tool die informatie genereert waarop een development team kan worden aangestuurd. Jenkins geeft ons een krachtige tool in handen om de technische voortgang en kwaliteit van development te kunnen beoordelen zonder in de code te hoeven duiken. Kortom; meten is weten.

Mobilism dag 1: the two weeks after

Door E-sites

Een paar weken terug (lees: 12 en 13 mei) waren Joris en ik in Amsterdam om Mobilism te bezoeken, een conferentie met een exclusieve focus op mobileā€¦ - Lees meer

Lees verder