Principper for den leverede kode

Kodens kvalitet er vigtig, fordi ringe kvalitet i kode på et tidspunkt i fremtiden vil have en negativ indflydelse på mulighederne for effektiv videreudvikling og vedligeholdelse af systemerne. Det er altså ikke nok med god funktionalitet. Den skal bakkes op af god kvalitet i alle dele.

STAR’s principper vedrørende kodning er inspireret af god skik, den agile bevægelse og erfaringer. Principperne er hverken komplette eller religiøse. STAR vil altid gerne blive klogere og vil derfor løbende udvikle principper og standarder inden for rammerne af samarbejdet med vores leverandører.

Det er et krav, at den leverede kode overholder de til enhver tid aftalte principper og standarder.

STAR ønsker således, at Opgaven løses efter ”Best Practice” for systemudvikling med udgangspunkt i følgende principper:  

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) og en persisteringsdel (SQL Server). 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.

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.

P5

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 accepterer dog, at navngivningen er på engelsk.

P6

Kend og brug rammeværket

De udviklingsrammeværk, der finder anvendelse i STAR’s løsninger, er omfangsrige, f.eks. Microsoft .NET. 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 ikke en religiøs tilgang til SOA (Service orienteret arkitektur), men vil gerne have en serviceorienteret tankegang til at gennemsyre løsningerne. Det er en tankegang, hvor den forretning, der skal understøttes, gennemsyrer implementeringen.

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. Se Principper

P10

Optimer koden til sidst

Optimer ikke koden unødigt. Som oftest er det billigere at anskaffe mere hardware end at optimere det udviklede, der er lavet fornuftigt i forvejen. Optimering foregår altid iterativt, sådan at det løbende valideres om optimeringerne er tilstrækkelige.

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 StyleCop og FxCop 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.