Principper for den leverede kode

P1

Kørende kode

Der er kun reel forretningsværdi i kørende kode. Kun udviklingsaktiviteter, målinger og artefakter, der bidrager til fejlfri kørende kode, er relevante. Dvs. at hver gang, vi skal vurdere og prioritere en aktivitet eller et produkt, skal det indgå i vurderingen, om aktiviteten eller produktet fører til kørende kode og til forbedring af kvaliteten i kørende kode.

P2

Teknisk gæld

Teknisk gæld eksisterer i STAR’s Forretningssystemer. Den tekniske gæld skal løbende nedbringes. Alle, herunder primært dem der arbejder med koden, har en initiativpligt i forbindelse hermed.

Død kode skal slettes. Hvis koden skal bruges igen, kan den findes i kode-repository.

P3

Kvalitet via reviews

STAR’s løsninger består af mange delkomponenter og aktiviteter. Udviklingsleverandøren skal sikre kvalitet i alle dele. En webapplikation består f.eks. af flere lag: Et præsentationslag (html, CSS, JavaScript), et applikationslag med flere logiske lag (.NET kode eller JAVA) og en persisteringsdel (SQL Server e.lign.). Dette princip betyder fx, at alle elementer er legitime og nødvendige genstande for reviews og standarder. STAR kan kræve at deltage i disse reviews.

STAR benytter automatiske værktøjer til måling af kodekvalitet og til dokumentation af kodekvalitetstrends.

P4

Funktionalitet i fokus, ikke generiske løsninger

STAR ønsker at undgå generiske løsninger, der ikke giver umiddelbar værdi. Det er vigtigere, at koden implementerer et forretningsønske og kan vedligeholdes, end at den kan genanvendes i andre sammenhænge. Kode skrevet til genbrug er typisk dyrere at udvikle og teste, en investering, der i en foranderlig verden tit risikerer at være tabt.

P

Læsbarhed via konsistent navngivning

Kodens væsentligste karakteristikum er læsbarhed. STAR er ikke kun interesseret i, at tingene virker her og nu, men erkender, at god og læsbar kode gør fremtiden nemmere for alle. Dette opnås først og fremmest gennem navngivning (med sigende navne og uden forkortelser) og strukturering, og derudover værditilførende kommentarer.

Kodens læsbarhed testes gennem code review. Et kriterium for læsbarhed kan være, at STAR’s ikke-tekniske projektdeltagere ved et review kan følge det overordnede flow i koden.

STAR tilstræber at navngivningen er på engelsk, hvor det er formålstjenligt.

P6

Kend og brug rammeværket

De udviklingsrammeværk, der finder anvendelse i STAR’s løsninger, er omfangsrige, f.eks. Microsoft .NET, .NET Core og JAVA framework. Uanset hvilken udfordring, vi står overfor, vil der næsten altid være nogen, der har gjort det før – og bedre. STAR ønsker inspiration fra og brug af gennemprøvede løsninger. Det har ingen værdi for os at have opfundet noget selv, hvor andre allerede har lavet en løsning. STAR mener, det er vigtigt, at udviklerne kender og udforsker frameworket.

P7

Keep-it-simple

Der er stor værdi i ”design patterns” som et middel til at skabe læsbar kode og effektive løsninger, men det at følge dem må ikke blive et mål i sig selv. Tit er ”keep-it-simple” det bedste pattern.

P8

Service orienteret arkitektur

STAR har en vis fleksibilitet i forståelsen af SOA (Service orienteret arkitektur). Det væsentlige er, at løsningerne gennemsyres af en serviceorienteret tankegang, hvor implementeringen understøtter forretningen.

P9

”Best practice” og non-funktionelle krav

STAR følger og har selv præciseret og vedligeholder ”best practice” for løsning af opgaver inden for flere tekniske områder. Et eksempel på dette er ”Den gode webservice”. Derudover vedligeholder STAR lister med non-funktionelle krav til det udviklede. Begge dele kan findes på STAR’s WIKI. Der forventes, at udviklingsleverandørerne gør sig bekendt med og følger disse.

P10

Optimer koden til sidst

Optimer koden i tilstrækkeligt omfang. Optimering foregår altid iterativt, så det løbende valideres, om optimeringerne er tilstrækkelige. Optimering skal ske under hensyntagen til bæredygtighed i applikationsudviklingen.

[Leverandøren bedes i bilag 5, afsnit 7.5, beskrive overvejelser og principper, der kan bidrage til bæredygtigt applikationsdesign.]

P11

Solidt kendskab til objektorienteret udvikling

STAR mener, at principperne i Objekt Orienteret Programmering skal være velkendte af udviklerne og anvendes, hvor det giver mening. F.eks. S.O.L.I.D. og kendskab til OOA og OOD er en fordel.

P12

Skriv korrekt

Stavefejl, både i dokumentation og i koden (variabelnavne osv.), er tegn på sjusk og skal behandles som fejl. Eksisterende stavefejl er en del af den tekniske gæld.

P13

Automatisering når det betaler sig

Automatisering af processer skal anvendes hvor der er en god businesscase for dette. Eksempler er automatisering af test (Unit test, UI-test) og automatisk kontrol af kodekvalitet som med fx Roslyn og automatisk kodegenerering.

P14

Skriv testbar kode

Den udviklede kode skal i videst muligt omfang være testbar og have en velovervejet testdækning, og testen kan med fordel gøres til en del af byggeprocessen.

P15

Event drevet arkitektur

EDA (Event Drevet Arkitektur) er et mønster, som STAR ønsker at anvende i kommunikationen mellem delsystemer i systemlandskabet, der hvor det kan bidrage til at nedbringe afhængigheder mellem systemer og teams, og hvor det kan bidrage til at skabe robusthed i det samlede systemlandskab.