“Standardized formatting reduces the cognitive friction when reading code from other authors.”

Net als in het Nederlands, Engels en alle andere talen is het belangrijk dat we bij Guapa onze code volgens regels en in een bepaalde stijl schrijven. Dit is belangrijk om het begrijpbaar en leesbaar te maken voor elkaar. Het verbetert de kwaliteit van ons werk en het verlengt de levensduur van de code en projecten. Hierdoor wordt het makkelijker om code van elkaar over te nemen, omdat we allemaal in dezelfde structuur schrijven.

Al een tijd geleden zijn we bij Guapa begonnen om deze afspraken binnen het team te implementeren en tijdens de quality reviews die we altijd al deden, te controleren. De lead developers controleren tijdens deze fase in de sprint de opgeleverde code op kwaliteit. Dit doen we o.a. aan de hand van ons conventie-document waarin de regels voor codestyling verwerkt zijn. Het document is een combinatie van regels voor PHP, volgens de PSR (PHP Standard Recommendation), en SCSS gericht op development voor Magento (2).

Een aantal maanden terug hebben we besloten om deze controles nog vaster in ons werkproces te zetten en een deel geautomatiseerd te laten controleren door SonarQube voordat de taak naar de testfase gaat. De desbetreffende developer weet hiermee direct, voordat de taak kan worden getest, of de kwaliteit voldoet aan onze standaarden. Daarnaast is het voor de lead-devs al een indicatie of het werk wat we opleveren van hoogwaardige kwaliteit is. Hierdoor hoeven ze alleen nog naar regels te kijken die niet door SonarQube zijn afgevangen.

PSR & SCSS

De PSR zijn regels die zijn opgesteld door de PHP Framework Interopt Group (PHP-FIG), waar ook Magento een stem in heeft. De vertegenwoordiger hiervoor is Magento Evangelist: Ben Marks.

In deze standaarden wordt beschreven welke regels er uitgevoerd MOETEN worden, NIET MAG/MOGEN worden gebruikt, VERPLICHT zijn, gebruikt ZOUDEN moeten worden, NIET gebruikt ZOUDEN moeten worden, AAN TE BEVELEN zijn, gebruikt MOGEN worden en welke  zijn.

En ook SCSS heeft op deze manier regels waaraan we ons werk kunnen toetsen.

SonarQube

SonarQube is een tool waarin analyses op code gedaan worden. Deze analyses worden gedaan tegen ingestelde- en geprogrammeerde regels volgens onder andere de PSR, bekende bugs en code smells. De analyses geven direct een beeld van de kwaliteit van het algehele project. Komt de code niet door de quality gates, dan moet dit aangepast worden en opnieuw worden aangeboden aan SonarQube voordat de taak naar de testfase gaat.

Klinkt goed toch? Waar checken jullie dan zoal op?
Voor de PSR hebben we in SonarQube op dit moment 56 regels actief waarop gecontroleerd wordt, in gradaties van: “Minor”, “Major”, “Critical”

Een aantal voorbeelden:

Minor

“<?php” and “<?=” tags should be used”

Major

“Functions should not contain too many return statements”

Critical

 

“Control flow statements “if”, “for”, “while”, “switch” and “try” should not be nested too deeply Nested if, for, while, switch, and try statements is a key ingredient for making what’s known as Spaghetti code. Such code is hard to read, refactor and therefore maintain.”

 

Dit zijn slechts 3 voorbeelden van de verschillende gradaties.

De uiteindelijke uitkomst van de controle gaat door een zogenaamde Quality Gate heen. Hierin staat beschreven in hoeverre de code moet voldoen aan de eisen om goedgekeurd te kunnen worden.

Komt een van de genoemde onderdelen niet door de Quality Gate heen? Dan wordt de code afgekeurd en gaan we aan de slag om alsnog de juiste uitwerking te schrijven. Ook hierbij worden we weer door SonarQube geholpen omdat SonarQube een oplossingsrichting geeft.

TTL

In eerdere blogposts schreven we al over onze TTL (Time To Learn). Het bovenstaande voorbeeld geeft mooi weer dat onze developers niet alleen leren tijdens hun leertijd, maar ook tijdens het werken aan projecten ontzettend veel bezig zijn met het verbeteren van hun kennis en kwaliteit, waardoor we iedere dag nog vettere projecten kunnen opleveren.

Toekomst

Naast gezond verstand hebben we dankzij onze kwaliteitseisen goed beeld over de status van projecten. Zoals al eerder benoemd, is dit erg belangrijk voor de doorontwikkeling, toekomstbestendigheid, patches en updates. Goed is voor ons niet goed genoeg en we dagen onszelf hier dan ook continu in uit om verbeteringen toe te voegen!

Wil je meer weten over onze normen en waarden op technisch vlak? Neem vrijblijvend contact met ons op of kom eens langs!