Ik ga graag op bezoek bij collega’s en concullega’s. Naast dat het goed is voor mijn netwerk, is het gewoon een hele mooie gelegenheid om van elkaar te leren.
Een van de punten waar ik vaak een suggestie toe doe is het maken van een ‘ontwikkelaars manifest’. Niets bijzonders, in de basis gewoon een documentje met een aantal afspraken en richtlijnen voor het ontwikkelteam, maar wat mij betreft een documentje met enorm veel voordelen.
Om te beginnen dwingt het schrijven van een manifest tot reflectie. Hoe wordt er ontwikkeld? Wat wordt er gedaan met tussenresultaten? Waar laten we de programmatuur? Hoe wordt er getest? Hoe wordt er opgeleverd?
Het schrijven zorgt vaak voor een herziening van de (vaak tot dan impliciete) procedures voor ontwikkeling en release. Vaak met snellere/meer foutloze opleveringen als gevolg.
Een ander voordeel is dat het manifest zorgt dat alle ontwikkelaars op dezelfde lijn komen. Door het manifest wordt duidelijk wat men van elkaar kan verwachten en wordt de code geschreven o.b.v. een gedeelde standaard, waardoor ontwikkelaars flexibeler zullen worden in het aanpassen en beoordelen van elkaars werk. (feitje: een regel code wordt 8 keer vaker gelezen dan geschreven.).
Zelf ééntje schrijven? Neem ter inspiratie onderstaande kopie van het concept manifest voor mijn huidige opdracht. Merk op dat de afspraken redelijk abstract zijn. De concrete procedures worden door het team zelf geschreven in aparte handleidingen.
Maatwerk manifest.
- Met maatwerk veranderen we geen standaard programmatuur.
Uitzonderingen worden in het team besproken.
- Het doel, alle ontwerpbeslissingen en de plaats binnen de architectuur van het maatwerk wordt gedocumenteerd..
- Al het maatwerk wordt vergezeld door unit-tests.
- Al het maatwerk wordt vastgelegd in subversion.
Vermeld story of issue-nr bij checkin.
- Het maatwerk (de programmatuur) is zelf beschrijvend of wordt vergezeld met verklarend commentaar/(java)doc
- Maatwerk wordt opgeleverd met buildscript/instructie t.b.v. Jenkins-CI.
t.b.v. uitvoeren tests, compileren en deployen.
Richtlijnen:
Aan alle teamleden de aanbeveling om ten minsten notie te nemen van de volgende aanbevelingen, en waar relevant toe te passen binnen het eigen werk. Onderstaande betreft een verzameling van tips & regels uit eigen ervaring of literatuur.
Software design
Best practices
- Weest bewust van veel voorkomende design patterns. Je collega’s gebruiken ze.
- ‘Designing for test’ zorgt voor een beter ontwerp door vermindering in afhankelijkheden, formelere interfaces en betere abstractie & modularisatie.
- Identificeer de elementen die mogelijk onderhevig zullen zijn aan verandering. Scheid en isoleer deze.
- ‘Schets’ je functies/klassen/packages eerst uit op papier. Dit scherpt je concepten, toetst je aanpak en maakt het beheersbaarder.
- Pas ‘information hiding’ toe. (Wat moet de buitenwereld weten?)
- Streef naar loose coupling.
- Zoveel mogelijk onafhankelijk van andere modules.
- Duidelijke lijntjes/relaties.
Code-kwaliteit
Naamgeving
- De naam beschrijft zo volledig mogelijk het doel.
- Geen cryptische ambigue termen.
- Liever lang en duidelijk, dan kort en verwarrend.
- Namen als i en j zijn geaccepteerd voor simpele loops.
- Gebruik een betekenisvolle naam bij lange loops, lange blocks of geneste loops.
- Gebruik ook for—each.
- Houdt status-variabelen specifiek. B.v. dataReady, needsRecalc, containsErrors. Ipv flag, status, error.
- Ook tijdelijke variabelen hebben een naam.
- Booleanse variabelen hebben een naam die impliceert dat hij waar/niet waar is.
- Zorg dat de members van ENUMS herkenbaar zijn. B.v. door prefixing.
enum color {color_red, color_blue) - Java: Baseer je code-style op de java/eclipse conventies. Conformeer je stijl waar nodig.
- Probeer bij het aanpassen van code – in een ander zijn stijl- zijn stijl ‘licht’ te adopteren als dit de leesbaarheid vergroot.
- I en j zijn indexes.
- Constanten zijn in CAPS.
- Class/Interface: Alle woorden beginnen met een hoofdletter.
- Variabelen: beginnen met een kleine letter, daarna alle woorden met een hoofdletter.
- Underscore ‘_’ wordt niet gebruikt behalve in CAPS.
- Afkortingen: prima, als ze maar bekend zijn.
- Javascript: Schrijven met als doel de filesize klein te houden bestaat niet. Gebruik een buildscript om je jeavascript te compileren, zoals de YUI compressor
Variabelen
- 1 variabele heeft 1 doel/functie. En nooit een tweede (verborgen) functie.
- Controlleer of input variabelen valide zijn (precondition checks)
- Beperk de ‘distance of declaration’. De ruimte tussen assignment en 1e
- Declareer (of her initialiseer) een variabele bij voorkeur net voor gebruik.
- Groepeer gerelateerde statements. Splits ze eventueel op in aparte functies of scope-blocks.
- Begin altijd met de meest beperkte scope (geldt uiteraard ook voor functies en classes).
- Wees bekend met de termen/concepten: coding time, compile time, load time, object instantiation time en just im time.
- Latere binding-time van variabelen verhoogt flexibiliteit.
- Voorkom in ieder geval magic numbers (coding time).
Classes & packages
- Betekenisvol, de naam beschrijft het doel.
- Voorkom imperatieve afhankelijkheden in aanroep tussen publieke functies.
Maatwerk IBM Content Navigator
- Javascript: Er wordt geen gebruik gemaakt van extra plugins zoals JQuery. Uitgangspunt is Dojo.
- Gebruik altijd asynchrone communicatie. Ken het scoping concept van closures.
- Bij plugins buiten het standaard plugin model
- Houdt extra rekening met naamgeving / beschrijving.
- Documenteer!
- Verkies ICN services boven webservices.
- Juist i.v.m. security.
- Plaats ‘generieke services in een generieke service plugin.
- Service exposen naar Workflows? Dan wel via webservices, maar met re-use (import) van de service.
- Voor extensies buiten het plugin model:
- Houdt rekening met conflicten door andere plugins (b.v. Enterprise Records).
- Weet wanneer je moet/kan kiezen voor een object-override of klasse override.
- Gebruik dojo mixin,extend, ..
- Je opties zijn: override, monkey patch prototype
- Zorg voor een passende betekenisvolle naam/omschrijving.
Concept bijgewerkt 🙂