Standaarden, wat zijn dat, waarom moeten wij die hebben en hoe werken ze dan? Vragen die ik regelmatig krijg, als ik informeer naar documentatie over standaarden binnen een bedrijf.
Ik ben nu meer dan 15 jaar actief als developer in de Microsofthoek en te vaak krijg ik deze antwoorden, wanneer ik naar standaarden vraag, bij de start van een nieuwe opdracht.

De meeste developers weten waarschijnlijk wel wat ik met standaarden bedoel. Sommige bedrijven hebben het allemaal netjes op de rit en komen met een document over de programmeerstandaarden. Dat is al heel wat, echter voor veel meer zaken is het nuttig standaarden op te stellen.

Wat zijn standaarden eigenlijk?

Te denken valt aan:

Programmeerstandaarden:

Oneliners, naamgeving, schrijfwijze, interfacegebruik, patterns, overerving, parametervolgordes, formattering, etc.

 

 

Deploymentstandaarden: 

Copy – paste, vanuit ontwikkelomgeving, automatisch? Ook hierbij hoort weer documentatie over hoe, wanneer (welke tijdstippen) en mogelijk één of meerdere checklists.

 

 

Source control:

Welke gebruiken we, branching strategie (Test / Acceptatie / Productie of per functionaliteit / sprint).

Inrichting standaarden, denk hierbij aan mappenstructuur, on-boarden van nieuw product of handleidingen.

 

Teststrategieën:

Unit testen schrijven, UI testen, integratie testen. Vergeet ook niet de code coverage (Moet de code min.50% geraakt door testen o.i.d.), stubben van systemen / applicatielagen / classes (gebruik van een mocking framework) en databasegebruik (testen op echte database en iedere keer opschonen of memory database gebruiken).

Deze documentatie kan een wiki, fysiek document of standaard on-boarding email zijn, die iedere nieuwe developer ontvangt. Voor sommige van de hierboven genoemde standaarden bestaat ook goede software-ondersteuning. Denk aan Visual Studio (Unit testen, code coverage), Resharper, SonarQube, CodeRush, FXCop, etc.

Natuurlijk is er niet één juiste manier van standaarden documenteren. Het gaat er vooral om dat het pragmatisch gebeurt en kan groeien. De wereld verandert snel en hierop moet dus ook de documentatie aanpasbaar zijn. Zie het als een kapstok of richtlijn. Niet alles hoeft tot op de letter gevolgd. Er kunnen namelijk altijd redenen zijn, af te wijken van een standaard.

Waarom standaarden van belang zijn?
Mensen verschillen en daarmee ook hun manier van werken. Nieuwe mensen brengen andere ideeën met zich mee en dat leidt soms tot het herzien van standaarden. Zeker als er goede argumenten zijn de zaken net wat anders te doen. Bedrijven/teams moeten hiermee agile omgaan.

Persoonlijk vind ik het prettig als vanaf het begin een opdracht transparant is. Wat is de manier van werken hier? Een groot deel van mijn ‘waarom?’-vragen is dan meteen beantwoord. Hierdoor kan ik makkelijker de code lezen, applicaties uitrollen, code schrijven en testen.

Hoe de standaarden vast te leggen?
Voor ieder bedrijf is dat anders. Of het nu om een document, code reviews of wiki’s gaat, het belangrijkste is dat het transparant is. Iedereen moet ze kunnen vinden en input kunnen leveren. Belangrijk hierbij is dat iemand eindverantwoordelijk is. Zo voorkom je eindeloze discussies, er moet soms een knoop doorgehakt worden.