Hemmelig rapport afslører CSC's og Scanjours katastrofale Polsag-kode

21. december 2012 kl. 16:1536
Hemmelig rapport afslører CSC's og Scanjours katastrofale Polsag-kode
Illustration: Das Büro.
Kildekoden til det skandaleramte Polsag-projekt har længe været hovedmistænkt for at være den faktor, der kostede projektet livet. Version2 har efter et års tovtrækkeri fået aktindsigt i den rapport, der gav Polsag dødsstødet.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

I februar 2012 måtte Rigspolitiet trække stikket på det forsinkede it-projekt Polsag, selvom systemet allerede havde været pilotdrift blandt de 80 betjente på Bornholm i over et år, og Polsag ifølge den efterhånden stærkt forsinkede tidsplan stod til at blive rullet ud i hele landet.

Klagerne fra de bornholmske testpiloter var massive, for systemet led af blandt andet lange svartider og manglende mulighed for at flere arbejdede på en sag samtidigt. Og spørgsmålet var så, om manglerne i systemet realistisk set kunne rettes op

Det skulle en nøje teknisk gennemgang afsløre, og indtil nu har Rigspolitiet og Justitsministeriet holdt disse rapporter hemmelige. Men som det første medie i Danmark kan Version2 nu bringe konklusionerne fra konsulentfirmaet Globeteams gennemgang af Polsag-systemet. Det er sket gennem aktindsigt - som er afsendt i først januar og igen i maj måned - hvorefter Justitsministeriet altså har valgt at vente til få timer før juleferien med at sende svar.

Globeteams rapport tegner bestemt ikke et positivt billede af leverandørerne CSC og Scansjours evner til at kode.

Artiklen fortsætter efter annoncen

I rapporten med code review af Polsags kodebase peger Globeteam-konsulenterne på den ene opsigtsvækkende fejl eller mangel efter den anden. Resultatet blev, at Rigspolitiet opgav at redde Polsag og derfor måtte vinke farvel til en investering på over en halv milliard kroner, som trods et efterfølgende forlig med CSC gik tabt.

Af Globeteams gennemgang af Polsag-kildekoden fremgår det blandt andet, at:

Kildekoden er alt for kompleks

Kildekoden til både server- og klientapplikationen af Polsag er programmeret alt for komplekst. Det gør den svær at vedligeholde og fejlrette.

»18% af kildekoden til POLSAG-klienten er svær at fejlsøge, teste og vedligeholde, fordi den er for kompleks, og heraf er 31% procent meget kompleks og dermed meget svær at fejlsøge, teste og vedligeholde,« hedder det blandt andet i Globeteam-dokumentet.

Artiklen fortsætter efter annoncen

Det samme gælder POLSAG-serverapplikationen, hvor 34 procent af kildekode ifølge Globeteam er for kompleks.

»Heraf har 56% af kildekoden (20% af kildekoden til POLSAG-serverapplikationen) en alt for stor kompleksitet, hvilket betyder, at den må betegnes som værende meget svær at fejlsøge teste og vedligeholde.«

Kildekoden er dårligt organiseret

»50% af kildekoden til POLSAG-klienten er samlet i kun 18% af metoderne, hvilket betyder, at kildekoden til POLSAG-applikation mangler organisering.«

»50% af kildekoden til POLSAG-serverapplikationen er samlet i kun 5% af metoderne (19% af kildekoden er samlet i kun 0,7% af metoderne),« skriver Globeteam i rapporten.

Kildekoden testes stort set ikke.

Normalt testes en klasse med 2-3 unit tests per metode, hvilket vil sige, at en klasse med 10 metoder har 20-30 unit tests, skriver Globeteam. Men for Polsag-koden er testniveauet langt lavere:

»Antallet af unit tests til Polsag er virkeligt lavt, og Polsag vurderes at være opbygget på en måde, der gør det svært at lave unit tests til forretningslogikken uden en vis refactoring af samme.«

Samtidig har Globeteam-folkene tjekket kildekoden igennem med værktøjer til statisk kodeanalyse. De afslører, at kildekoden »ikke overholder de gængse practices for navngivning, struktur og organisering.«

Kildekoden er dårligt dokumenteret

Det er helt galt med niveauet af dokumentation til kildekoden, hvilket igen gør den svær at vedligeholde og forstå for andre.

»Kildekoden indeholder et særdeles lavt niveau af kommentarer og øvrig information. SDD'erne (designdokumentet, red.), som er de primære dokumentation for Polsag-funktionaliteten, er meget implementeringsnære. Det vurderes at være svært at udlede de forretningsmæssige krav og ønsker på basis af SDD'erne,« hedder det i gennemgangen.

Bygger på JavaScript og forældede teknologier.

Polsag-klienten er baseret på websproget JavaScript, hvilket Globeteam kritiserer. JavaScript udgør i alt cirka halvdelen af Polsag-kodebasen, fremgår det af rapporten.

Artiklen fortsætter efter annoncen

»Det forhold, at JavaScript er et typesvagt sprog, medfører, at øget kompleksitet har en væsentlig større negativ impact for udvikleren end ved andre sprog.«

Samtidig bygger Polsag-serverapplikationen på Microsoft .NET version 2.0 - en platform, der allerede i 2010 blev lanceret i version 4.0.

Det betyder ifølge Globeteam, at »projektet ikke høster de forbedringer, der er sket på Microsofts udviklingsplatform i form af højere udviklerproduktivitet, behov for reduceret kodemængde eller øge fleksibilitet,« skriver Globeteam.

36 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
35
28. december 2012 kl. 14:51

Undrer mig over den kraftige kritik af, at koden er 'kompleks'.

Enkelhed er godt. KISS er et godt princip. Unødig kompleksitet er af det onde.

Men det fremgår ikke, at kodegennemgangen påviste, at koden faktisk kunne skrives enklere og samtidigt opnå samme funktionalitet (at samme funktionalitet så viser sig at være utilstrækkelig er en anden (pol)sag).

Koden kan være berettiget kompleks, hvis datastruktur, ønsket funktionalitet og behov nødvendiggør det.

At noget er 'komplekst' bør anvendes som en objektiv, beskrivende, ikke(for)dømmende værdineutral beskrivelse. At beskrive noget som 'unødigt komplekst' bør følges af en beskrivelse af hvordan problemet kunne være løst af simplere kode (hvad det så end er: færre kodelinjer?, flere kodelinjer med lettere gennemskuelig logik?, kodning i samme stil som dén læseren foretrækker og har erfaring med?)

Uden adgang til hele rapporten er det svært at forholde sig til kritikken.

Men som det fremgår i artiklen får man nemt den tanke, at hvis man (Globeteam) er købt og betalt til at kritisk at gennemgå kode, er det sikre valg netop at være kritisk og fordømmende - er de ikke nærmest 'bestilt' til at komme med dén konklusion givet opdraget (kritisk kodegennemgang) og den kedelige forhistorie med tids- og budgetoverskridelser samt en katastrofal pilot-afprøvning hos Bornholms Politi?

Derudover er en naturlig menneskelig reaktion på noget, man (konsulenten, der foretager kodegennemgang) ikke forstår, at beskrive det som 'for komplekst'. Og en modtager (Rigspolitiet og Justitsministeriet) med samme lave forståelsesniveau vil være lykkelig for at blive bekræftet i, at vedkommende ikke mangler forståelse, indsigt og en koncis kravsspecifikation, men at koden vitterligt er 'for kompleks'.

Jeg har intet kendskab til kvaliteten af ressourcerne sat på opgaven hos hverken CSC, Globeteam, Rigspolitiet og Justitsministeriet, men man bør nok betragte rapporten som et partsindlæg ligesom et indlæg fra CSC i samme sag måtte betragtes med en vis skepsis.

34
27. december 2012 kl. 12:09

Så vidt jeg husker blev POLSAG købt under FESD aftalen - og altså ikke som et "rigtigt" EU-udbud?! Korrigér mig, hvis jeg tager fejl?!?

For heri ligger hele misæren.

Politiet var med i følgegruppen til FESD arrangementet - og havde dermed en form for forpligtelse til at vælge en af de tre leverandører, som kom med på aftalen.

Men i realiteten stod Politiet med nogle noget mere komplicerede problemstillinger, end den typiske journalsystem-kunde i den offentlige sektor - og burde som sådan nok aldrig have sat sig med i følgegruppen!!

Da leverandørerne var valgt, fremstod CSC/ScanJour så som det, om man så må sige, "mindst ringe" af de tre.

Men man havde nok været bedst tjent med at springe op og falde ned på "sin forpligtelse" overfor FESD - og være gået den lange, tunge vej over et eget EU-udbud, istedet for at vride et standardsystem om til noget, det ikke var egnet til...

33
27. december 2012 kl. 01:29

Jeg har meget svært ved at vurdere disse tal, altså om det er spaghettikode eller ej.

Som jeg har forstået det er serverdelen et webserver-program, skrevet i C# på .Net 2.0, som læser og skriver data i en database. Til dette er der sikkert et godt kodegenereret objektorienteret data-tilgangs-lag, som sikkert er mange tusinde klasser med metoder der kun henter eller sætter værdien at en variabel (get og set). Der skal altså skrive rigtig mange forretningslogik metoder til at nå op på 5% af samtlige metoder...

Tilsvarende har jeg det svært med analyseprogrammers angivelse af kompleks kode, brug af abstrakte eller interface klasser, eller en simpel try-catch er som regel nok til at koden er kompleks. Det siger mere om analysen end programmøren.

Når det er sagt, så forventer jeg da at firmaet har haft programmøre til at kigge kode grundigt efter, og at rapportens konklusioner er baseret på dette og ikke de nævnte tal.

28
25. december 2012 kl. 08:51

Dette bekræfter mig blot i at leverandørene aldrig havde planlagt at levere et fungerende system. De stod sig langt bedre ved at levere noget dårlig kode, som aldrig ville kunne bringes til at fungere og score den betaling som de nu kunne få for det.

29
25. december 2012 kl. 16:57

Dette bekræfter mig blot i at leverandørene aldrig havde planlagt at levere et fungerende system.
De stod sig langt bedre ved at levere noget dårlig kode, som aldrig ville kunne bringes til at fungere og score den betaling som de nu kunne få for det.

Det kan man jo sige, men et eller andet sted tror jeg heller ikke de fleste steder er klar over hvordan man faktisk udvikler IT. Mange steder kører stadig efter 70er og 80er "principper", hvor udviklerne reelt står for alt tekniske styring, og som der er blevet påpeget i kommentarerne så halter mange udviklere langt efter hvad der reelt er påkrævet for at udvikle store moderne web applikationer i "god kvalitet".

.NET 2.0, og med de tal der nævnes, så er jeg sikker på at alle udviklere kan nikke genkendende til det et projekt de har arbejdet med selv, skrevet af folk som ikke kender grundlæggende framework koncepter, med de medfølgende gamle/propriatære UI web forms kontroller iblandet den obligatoriske JS blanding af forsøgt OO/lib og funktions suppe. For slet ikke at tale om når et projekt også går amok på databasen med tusinder af stored procedures/functions/views oven på alt det andet. Og naturligvis må der være en trillion integrations punkter, og hvad der så deraf kommer af ekstra kompleksitet.

Jeg har ikke arbejdet på noget i Polsag skalaen, så selv jeg har svært ved at forestille mig det absolutte rod det må være (50% af koden i 7% af funktionerne, jesus).

Nu har vi ikke set hele rapporten, men jeg synes også deres kommentare om .NET 2.0 og JS virker mærkelige, men der er måske også tale om nogle få sætninger i en flere hundrede sider lang rapport.

24
22. december 2012 kl. 17:26

Jeg funderer om der kunne være tale om en usund arbejdskultur. Dvs. at management ikke vil have alt det der pjat med tests, og dokumentation - det eneste der skal laves er funktionalitet.

Begrebet teknisk gæld er måske også ukendt for management.

Hvis de har irettesat gode udviklere for at lave tests, og dokumentation, så er det næsten helt sikkert at ingen knap så dygtig udvikler ville turde tage et initiativ til noget der ligner kvalitetskode.

23
22. december 2012 kl. 12:26

Det ville være perfekt for CSC at finde nogle grunde til at deres POL sagssystem haverede i hegnet.

Men det har intet med Javascript at gøre. Jeg gætter på at flere af de mennesker der er fremkommet med det argument bruger gmail som privat mail konto. En applikation der er skrevet i 90% Javascript (152.000 LOC) som virker ganske fortræffeligt. Om MS produkterne er outdated aner jeg intet om.

Mem jeg ved at "greenfield" system kræver mange beslutninger. Hvis nogle af de beslutninger der tages tidligt i projektet er forkerte kan de næste beslutninger ikke rede situationen.

Sådan som jeg læser Globeteams rapport er det tydeligt at problemet handler om mennesker og dårligt håndværk. Globeteam er bare for konfliktsky til at sige det ligeud.

22
22. december 2012 kl. 11:08

Vi skal i vores branche til at stille større formelle krav til udviklere, som man f.eks gør med læger. Her har man opbygget et system med turnus, specialisering og lægeløfte etc. I dag kan alle kalde sig for software ingeniør og hvis arbejdsgiver ikke er skarpe til at hyre kompetente mennesker der selv stiller høje faglige krav til resultatet af deres arbejde, så går det nemt helt galt med en kodebase.

20
21. december 2012 kl. 23:13

Det er muligt jeg husker forkert, men var det ikke en væsentlig antagelse, at løsningen skulle baseres på et standardprodukt, i dette tilfælde ScanJours ESDH-system?

Hvis projektet aldrig har været tænkt som et udviklingsprojekt, men som implementering af "standardfunktionalitet med mindre tilretninger", så er det ikke overraskende at det går galt, når der opstår behov for langt mere udvikling end forudset. Man kommer til at mangle ressourcer med de nødvendige evner og projektplanen indeholder ikke aktiviteter til den nødvendige analyse, dokumentation og test.

Samtidig har projektet en størrelse, hvor erkendelsen af, at vigtige forudsætninger ikke længere er opfyldt, har en meget langsom vej til de beslutningstagere, der kan (eller burde kunne) agere på den omstændighed at standardløsningen er for langt fra de stillede krav. Er der det mindste element af personlige politiske agendaer eller "management by fear" på vejen fra den tekniske erkendelse af problemet til den forretningsmæssige løsning, så går det galt.

17
21. december 2012 kl. 21:33

Kan ikke sige jeg er 'forbavset' over kompleks kode. Det virker som om der ofte er en ... nærmest nødvendighed i at lave kode kompleks fordi det så virker mere 'programmøragtig'.

Der er jo ikke meget prestige i bare at lave noget der virker ordentligt hvis det ikke implementerer 17 interfaces, nedarver nogle klasser og benytter en masse andre teknikker.

18
21. december 2012 kl. 22:20

Der er jo ikke meget prestige i bare at lave noget der virker ordentligt hvis det ikke implementerer 17 interfaces, nedarver nogle klasser og benytter en masse andre teknikker.

Det sjoveste eksempel jeg har set på det var en gut der lige havde læst om en Y-Combinator, og så implementerede en generel sorterings-metode med den i C#. (Koden skulle bruges eet sted, og var temmelig krøllet). Jeg foreslog ham at refaktorere det, og det gjorde han heldigvis.

Lysten til at spille med den intellektuelle muskel uden god grund, skal holdes til egne side-projekter, og ikke ind i den fælles kodebase :-)

13
21. december 2012 kl. 20:21

Har de brugt et automatisk standard værktøj til at måle kodekompleksitet eller har de reelt vurderet kvaliteten?

25
22. december 2012 kl. 17:41

Det fremgår ikke her, men af min kendskab til deres arbejde, bygger det på begge dele. En værktøjsbaseret analyser med Sonar el. lign., og så derfra manuelle undersøgelser og vist nok også interview med div. projektdeltagere.

15
21. december 2012 kl. 20:57

Gætter på det er en statisk analyse af det. Var faktisk ved at skrive en kommentar lig med din, men efter lidt omtanke tror jeg faktisk ikke det er så dum en måde at betragte kvalitet af software. Altså givet at man skal sige noget generelt.

7
21. december 2012 kl. 17:40

NEEDS MORE BREAKING... Kan i offentliggøre rapporten her ? Den lyder ret interessant (undskyld hvis jeg har overset det åbenlyse link)

11
21. december 2012 kl. 20:08

Til alle jer, der efterlyser selve rapporten:

Selve aktindsigten er en meget omfattende sag, og vi er blevet bombarderet med dokumenter. I første omgang går vi efter at grave de mest åbenlyse historier frem fra materialet, sidenhen skal vi nok offentliggøre de mest oplagte dokumenter.

God jul & vh Morten, Version2.

10
21. december 2012 kl. 19:08

Kan du så fortælle mig hvor det link, er for jeg kan sgu ikke finde det, ikke særligt åbenlyst.

4
21. december 2012 kl. 16:57

Store gamle IT-firmaer har typisk en stor kodebase af ældre dato, som de gerne bygger nye applikationer ovenpå i den tro, at de sparer tid og penge ved dette. Derfor bruges ofte forældede platforme såsom .NET 2.0, og koden bliver patch-på-patch og derfor mere og mere uoverskuelig og tung. Endvidere vil egenskaber såsom samtidig brug og sikkerhed være meget vanskelige at tilføje, da den slags skal være bygget ind fra grunden og kun vanskeligt lader sig bygge ovenpå en kodebase, der ikke er forberedt til dette.

Men historien viser gang på gang, at der ikke er noget sparet ved at bygge et stort IT-projekt som modifikation et ældre projekt. Man skal bruge mere tid på at omgå begrænsningerne i den gamle kode, end den tid, man sparer ved ikke at skulle skrive det fra bunden.

Men desværre er der mange såkaldte softwareudviklere, der ikke magter at skrive ting fra grunden: De kan til nød modificere eksisterende kode og sætte parametre på biblioteksfunktioner, men hvis der skal laves grundlæggende ny funktionalitet, smider de håndklædet i ringen -- eller koder tåkrummende dårlig og skrøbelig kode, hvilket faktisk er værre.

12
21. december 2012 kl. 20:11

Det er forkert at skrive .NET 2.0 er forældet; ja vi har .NET 4.5 men CLR er stadig meget lig den der findes i .NET 2.0 omend der er lavet forbedringer. .NET 2.0 og frem er meget tidsvarende.

14
21. december 2012 kl. 20:26

Det virker i det hele taget temmeligt søgt at kritisere for brug af .Net 2.0, eftersom projektet blev startet i 2003, mens .Net 2.0 først udkom i 2005. Man har altså valgt at opgradere platformen midt i udviklingsforløbet mindst én gang. Det kan selvfølgelig være fordelagtigt i nogle tilfælde, men kan også være risikabelt, og kan da på ingen måde siges at være et must.

5
21. december 2012 kl. 17:06

Enig - Patchwork oven på gammel kodebase kan aldrig løse de grundlæggende mangler.

  • og delvist enig. Der er stadig gode programmører derude. Det er sjældent at projektet tillader at de kan bruge tid på at skrive koden helt fra bunden. Men vi kan godt lave quicksort og dobbelt linkede lister, hvis vi altså finder olie i norske mængder.

Det er i øvrigt forbavsende ofte vi ser, at store IT monstre partout skal erstattes af et større - og at projektet fejler.

3
21. december 2012 kl. 16:50
Det vurderes at være svært at udlede de forretningsmæssige krav og ønsker på basis af SDD'erne,« hedder det i gennemgangen. Den næste forespørgsel om aktindsigt kunne så netop fokusere på hvordan politiets "ikke-it-nørder" har beskrevet og dokumenteret deres forventninger/krav til POLSAG's støtte til forretningsprocesserne. (altså hvordan skal betjenten registrere en udstedt fartbøde, registrere en henvendelse fra en borger, osv. osv. )
1
21. december 2012 kl. 16:33

»Det forhold, at JavaScript er et typesvagt sprog, medfører, at øget kompleksitet har en væsentlig større negativ impact for udvikleren end ved andre sprog.«

Det gik jo egentligt OK indtil denne kommentar. Jeg kan regne ud af en del af Polsag består af en webklient, og så er Javascript nu engang det vi har at arbejde med (jaja, der er alle mulige sære sprog der kan oversættes til javascript, men hvor mange mon rent faktisk bruger den slags i enterprise-applikationer?).

32
27. december 2012 kl. 00:41

Desværre er der jo ikke noget der tyder på at det ændrer sig i nær fremtid. Det offentlige bliver ved med at fortsætte denne måde at udbyde IT opgaver på.

Jeg er af den overbevisning at sandsynligheden for, at et IT projekt fejler på denne måde, er proportionel med, hvor meget den SKAL omfatte ved første release.

Hvis man starter småt, men dog har opmærksomhed på at systemets fundamentet skal kunne håndtere et uvist mængde af tilføjelser, kan man sagtens ende med en løsning, der ikke har karakter af knopskydninger.

Spis elefanten lidt ad gangen og til sidst er man i mål.

Utroligt mange af de store systemer, der har haft succes, er startet småt og er efterhånden forbedret og udvidet indtil man løser de opgaver der rent faktisk skal løses.

Ulempen ved at man har hele problemet defineret i en STOR kravspecifikation er, at man så kun fokuserer på det der er defineret. På den måde lukker man muligheden for tilføjelser eller ændringer da hele system er internt afhængigt. Sagt på en anden måde, hvorfor skal en projekt leder afsætte tid til at gøre system generisk hvis der ikke er brug for det? Alt er jo beskrevet nøgternt i krav spec ikke? Hvorfor bruge tid på besværlige patterns og lagdelinger hvis man bare kan skrive en funktion der kan det hele. Det lyder uhyggeligt men der sker. Som jeg læser det:

»50% af kildekoden til POLSAG-serverapplikationen er samlet i kun 5% af metoderne (19% af kildekoden er samlet i kun 0,7% af metoderne),« skriver Globeteam i rapporten.

Så lyder det som en forfærdelig gang spagetti kode.

Et andet problemer er at man fra start af, sjældent har et overblik over, hvilke problemer systemet rent faktisk skal løse.

Tit er der en tendens til at tro man ved det. Jeg har flere gange oplevet at man løser problemerne på den måde man altid har løst dem. Dette er selvom man aldrig har løst problemerne med de tekniske hjælpemidler man nu har. Altså man indbygger en del af de eksisterende løsninger i et IT system, selvom de kun løste nogle problemer man havde, da man gjorde tingene manuelt. Eller man indbygger nogle af de Userinterface paradigmer man havde da applikationen stort set bare var en SQL forms app.

Andre gange har jeg oplevet at jeg har løst problemet PRÆCIST som det var defineret, men når man så bruger det, finder man ud af, at det alligevel ikke var det man ville have. Først bagefter kommer der så en gradvis forbedring af løsningen indtil den er acceptabel. Hvis hele løsningen så er designet til det der oprindeligt var defineret i kravspec betyder det så at der er lavet nogle opfindsomme hacks der får systemet til at virke med den løsning man til sidst fandt. Desværre gør det så løsningen lidt langsommere og langt mere uforståelig fra et teknisk perspektiv.

19
21. december 2012 kl. 22:28
9
21. december 2012 kl. 18:26

Det er jo nok forholdet mellem klientkode og serverkode som er kritisabelt. At bygge et stort system op omkring en tyk javascript klient lugter langt væk.

21
22. december 2012 kl. 00:34

Det er jo nok forholdet mellem klientkode og serverkode som er kritisabelt. At bygge et stort system op omkring en tyk javascript klient lugter langt væk.

Citation needed.

Hvad er dine erfaringer med tunge javascriptklienter bygget med moderne webteknologier som får dig til at drage den konklusion?

26
22. december 2012 kl. 21:01

Det har ellers været ganske meget fremme i nyere tid at bygge websider hvor serverside-delen ikke er meget mere end data-validering og et API der bruges af klienten.

Det er måske populært (google er gode til det) men det er svært. Jeg påstår at det er meget nemmere at lave et solidt stort system med kringlet forretningsregler i et typestærk sprog com c#. I min verden er .net 2 desuden forældet, når jeg tænker over hvordan jeg kan løse samme problemer med .net 3.5+. Man skal turde skifte version midt i et udviklingsprojket, hvornår skulle der ellers komme et bedre tidspunkt?

6
21. december 2012 kl. 17:28

»Det forhold, at JavaScript er et typesvagt sprog, medfører, at øget kompleksitet har en væsentlig større negativ impact for udvikleren end ved andre sprog.« ... Det gik jo egentligt OK indtil denne kommentar.

Selv om JavaScript kan kaldes for et vilkår for programmering til browser-klienter, ændrer det ikke på at sprogets karakter medfører at kompleksitet nemt bliver ekstra svært at overskue uden en grundig disciplin og strukturering af koden. Jeg ser ikke denne passus som et "angreb" på brugen af JavaScript, men blot en ekstra faktor omkring at koden vurderes som værende for kompleks (rodet). Og det forekommer mig at være et fair kritikpunkt.

8
21. december 2012 kl. 18:21

Ét ord: Typescript.

TypeScript er først blevet offentliggjort i løbet af i år, så jeg synes ikke vi kan klandre dem for ikke at have brugt det i denne specifikke sag.

Og hvis de rent faktisk kritiserer dem for at have brugt javascript i en webklient så skal de holde op med at ryge fjolleurt. Hvis de kritiserer dem for at kode slamkode er det noget helt andet.