[.NET/Beleid]

[Bats]

Vraag
In hoever moet je gaan (voorbeelden/standaarden) in het vastleggen van beleid over hoe softwarecomponenten gebruikt dienen te worden binnen een organisatie?
Zijn hier standaarden over of assesment guides over hoe dit te realiseren?

Ik praat dus niet over bijv naming conventions.

Achtergrond
Ik werk voor een bedrijf met +/- 15 man development op een totaal team (testers/IA/Dev/projectleiders) van 60 man. Het totale bedrijf bestaat uit 450 man.

Nu is het idee dat er beleid gemaakt moet worden over hoe software wordt ontwikkeld, hierin stranden we elke keer in wellis nietis discussies.

Voorbeelden
Binnen het bedrijf is gekozen om WCF te gebruiken als primair communicatie middel (geen protocol, alleen techniek). Nu gaat de huidige discussie over hoe deze service te gebruiken. Maak een Service Agent, we werken voornamelijk intern met onze service het is dus makkelijk extra dll mee te leveren die de service referentie implementeerd, deze service agent dient altijd x aantal features te bevatten zoals bijv: vertaling Dto => entity objecten, caching. Zorg ervoor dat je interface van je businessServiceImplementatie het zelfde is als die van je ServiceAgentImplementatie zodat deze componenten uitwisselbaar zijn.

Nu zijn hier verschillende onderdelen in benoemd waar erg veel discussie over is in een wellis nietis variant.

Tot slot
Ik denk zelf dat het vastleggen van dit soort afspraken op dit niveau voor een relatief klein bedrijf zoals dit is overbodig is. Het idee om dit zo strak mogelijk op te schrijven zodat hier alle uitzonderingen in gedekt zijn lijkt me een verspilling van tijd over een onderwerp wat te groot is om alles van te beschrijven wat we mogelijk raken.

Graag jullie ideeen over hoe om te gaan met dit fenomeen.

Grt Bats

[EfBe]

"There's no silver bullet"

M.a.w.: wat jij nastreeft, een 'doe dit' guide, die is er niet. Wat je moet doen is een beslissing nemen. Maakt niet uit welke, ALS deze maar beargumenteerd is. Als je een welles/nietes discussie krijgt, dan zijn er kennelijk meerdere mensen overtuigt van hun gelijk maar niet van elkaars gelijk. Dit los je alleen op door een van beide te kiezen op basis van argumenten die hout snijden. DAT documenteer je en dat gebruik je.

Het maakt nl. niet uit wat je kiest, er zijn namelijk meerdere manieren om software te maken. Wat je moet kiezen is datgene wat onderhoudbare, begrijpelijke software oplevert die past bij hoe men in jouw team door de bank genomen software wil maken. Waak voor de architecture astronaut en zn wilde ideeen.

[BikkelZ]

Ik streef er altijd naar om met elkaar om de tafel te gaan zitten, allemaal stukken code aan te dragen van een project (bijvoorbeeld de gehele implementatie van één scherm in een applicatie) en dan die te gaan reviewen met elkaar, eventueel aan te passen en die dan te verheffen tot standaard.

Niet proberen alles vast te leggen maar wel door codereviews stapsgewijs vastleggen wat wel en wat niet goed is en dan kun je ook zo een nieuwe developer inschuiven die eigenlijk vanuit templates met goede code kan gaan werken. Maar je moet gewoon codereviews houden. Vijf geeks in een vergaderhok, vijf pizza´s en cola en dan door wat interessante checkins heen gaan. Je krijgt dan veel meer een idee hoe mensen over dingen denken, en je krijgt een werkend voorbeeld van code te zien in plaats van alleen wat gelul in een vergadering of in de open ruimte.

[Megamind]

Bij ons hadden we ook allerlei van dit soort "standaard" dingen, maar helaas werken deze na een tijd toch niet meer. Niet geupdate, werkt niet meer bij nieuwe versies of mist functionaliteit.

Aangezien we voornamelijk webdesign doen hebben we één "template" gemaakt met allerlei kleine basis dingen en een CMS welke gebruikt wordt als nieuw project. Dit is dan wel een "community" project waar alle devvers stukken code aan kunnen dragen waarbij één iemand verantwoordelijk is voor het onderhoud hieraan.

De rest bestaat vooral uit nuget packages.

[Onbekend]

Standaarden waarover het iedereen eens mee is kan je direct opschrijven.

De punten waar de meningen over verdeeld zijn moet gewoon laten liggen. Na verloop van tijd komen de voor en nadelen van bepaalde punten naar boven en kan je die op dat moment opschrijven.

Alle punten opschrijven zal je nooit lukken, aangezien na verloop van tijd zal ook standaarden gaan wijzigen.
Vast houden aan standaarden zal ook de ontwikkeling van nieuwere betere standaarden in de weg zitten.