mboost-dp1
www.politi.dk
Wow JavaScript og .NET 2.0
Hvis det er det nyeste der blev lavet dengang... Så vil jeg ikke vide hvad alle de andre gamle systemer kører på.
Hvis det er det nyeste der blev lavet dengang... Så vil jeg ikke vide hvad alle de andre gamle systemer kører på.
Hvorfor lave noget der er nemt at velligeholde og forstå. På den måde kunne CSC jo være sikker på at det kun var dem som kunne stå for vedligeholdelsen i mange år bagefter, og derved score latterligt mange penge på at udvikle systemet, og efterfølgende skumme fløden endnu mere.
jeg gætter på at det er indere der har lavet koden.
de kodning jeg har mødt fra indiske kollegaer i sin tid, var ret temmelig sjuske, taget i betragtning at de skulle have flere års erfaring med kodning.
jeg tror mest det er pga kulturen under uddannelse. der hvor jeg blev uddannet, havde vi da intern kamp om hvem der kunne lave den simpleste kodning. desuden gjorde vores undervisere også opmærksom på KISS hver gang vi skulle lave noget.
som jeg har hørt fra andre, som sikkert har hørt fra andre, så forgår undervisningen i indien med, at de bare skal læse bøger og svare på spørgsmål
de kodning jeg har mødt fra indiske kollegaer i sin tid, var ret temmelig sjuske, taget i betragtning at de skulle have flere års erfaring med kodning.
jeg tror mest det er pga kulturen under uddannelse. der hvor jeg blev uddannet, havde vi da intern kamp om hvem der kunne lave den simpleste kodning. desuden gjorde vores undervisere også opmærksom på KISS hver gang vi skulle lave noget.
som jeg har hørt fra andre, som sikkert har hørt fra andre, så forgår undervisningen i indien med, at de bare skal læse bøger og svare på spørgsmål
#3 - Se denne kommentar: http://www.version2.dk/artikel/breaking-hemmelig-r...
Kan ikke se problemet i .net 2.0, vil jo fortsat virke, og bør vel uden de helt store armbevægelser også kunne konverteret til .net 4.x.
Der må vel foreligge nogle dokumenter, hvor man har truffet disse valg, så man kan se årsagen hertil ? Jeg går ikke ud fra, at de vitterligt ikke har haft egne interne regler for, hvor meget test og dokumentation der skal laves ?
Der må vel foreligge nogle dokumenter, hvor man har truffet disse valg, så man kan se årsagen hertil ? Jeg går ikke ud fra, at de vitterligt ikke har haft egne interne regler for, hvor meget test og dokumentation der skal laves ?
ligesom de forretningsmæssige krav og ønsker kan ikke udledes fra designdokumentet.Så skulle projektet jævnfør min håndbog da vist aldrig have været startet..
Jeg er SÅ forfærdet over hvor mange komplet imbecile fedtmuleprogrammører (...OG projektledere!!!) der sidder rundt om i IT.
Det kan godt være at de kan vise en masse fancy Datamatiker-papirer frem og Super-Grade-My-Naked-A$$ certifikater fra deres tid i maskinlære....
Men der er SÅ mange Fedtmuler rundt om der tror at de bare er de bedste i verden og hvis nu jeg laver koden kompleks nok, så beholder jeg mit arbejde..... AAARRGGH.... modsiiigelse....
Den seneste jeg har hørt er en såkaldt "C# Software Developer" der ikke ved hvad en Auto-Property er.... ARGH!
Brain shutdown..... Somebody shoot me!!
Ontopic: Bad code quality? - Anyone suprised? :-P ;-)
Det kan godt være at de kan vise en masse fancy Datamatiker-papirer frem og Super-Grade-My-Naked-A$$ certifikater fra deres tid i maskinlære....
Men der er SÅ mange Fedtmuler rundt om der tror at de bare er de bedste i verden og hvis nu jeg laver koden kompleks nok, så beholder jeg mit arbejde..... AAARRGGH.... modsiiigelse....
Den seneste jeg har hørt er en såkaldt "C# Software Developer" der ikke ved hvad en Auto-Property er.... ARGH!
Brain shutdown..... Somebody shoot me!!
Ontopic: Bad code quality? - Anyone suprised? :-P ;-)
Testa (5) skrev:Hvorfor lave noget der er nemt at velligeholde og forstå. På den måde kunne CSC jo være sikker på at det kun var dem som kunne stå for vedligeholdelsen i mange år bagefter, og derved score latterligt mange penge på at udvikle systemet, og efterfølgende skumme fløden endnu mere.
Hvis jeg skal gætte er det også det der har været planen.. Og det er jo en ret smart idé; flabet, men smart.
Problemet er bare når koden bliver for kompleks og de ikke selv kan finde ud af det.. så stopper dem der har udviklet det og der ikke er nogen dokumentation til dem der skal tage over (hvilket lader til også at have manglet):
0 skrev:Rapporten kritiserer også dokumentationen for Polsag, hvor kildekoden indeholder meget få kommentarer ligesom de forretningsmæssige krav og ønsker kan ikke udledes fra designdokumentet.
og pludselig kan de så bruge åndssvagt mange penge på at skulle finde hoved og hale i hvad der gør hvad, samtidig med at politiet har et pressende problem der skal løses som bare ikke kan findes i koden.
Og vil gætte på de samtidig ikke har lært noget og stadig ikke laver dokumentation, og et par år efter står de med samme problem igen :)
webwarp (8) skrev:Kan ikke se problemet i .net 2.0, vil jo fortsat virke, og bør vel uden de helt store armbevægelser også kunne konverteret til .net 4.x.
Desuden er .NET 2 en udmærket og moderne platform. Så er der altså heller ikke sket mere fra 2 til 4; det er et større skridt fra 1 til 2.
#11
Smart og smart. Det gjorde man i 90'erne og i starten af 2000.
I dag er der saa mange programmoerer, at det er en meget hurtig maade at miste sit arbejde og som leverandoer, evt. blive sagsoegt, etc.
Derudover saa er man generelt bare et roevhul hvis man goer saadan :)
Smart og smart. Det gjorde man i 90'erne og i starten af 2000.
I dag er der saa mange programmoerer, at det er en meget hurtig maade at miste sit arbejde og som leverandoer, evt. blive sagsoegt, etc.
Derudover saa er man generelt bare et roevhul hvis man goer saadan :)
Jeg kan ikke lade være med at tænke, at hvis de havde givet dobbelt så mange penge for det, havde de fået noget der var endnu større og endnu mere håbløst komplekst. Altså at flere penge ikke nødvendigvis leder til en bedre løsning, men snarere at kurven knækker, og før eller siden ender man med at bruge så store kanoner til at skyde gråspurven med, at man ikke engang kan ramme den stakkels pipfugl.
Jeg har på fornemmelsen, at den her slags systemer ofte opstår, fordi nogen beder om "et system der kan alt". Det er nemlig opskriften på katastrofe.
Jeg har på fornemmelsen, at den her slags systemer ofte opstår, fordi nogen beder om "et system der kan alt". Det er nemlig opskriften på katastrofe.
Normalt udføres der 2-3 unit tests per metode
Fuck nogle idioter, så dum en udtalelse gør det fuldstændig klart, at konsulenterne fra Globeteam ikke selv kan, eller har prøvet at, implementere noget som helst. Så er det heller ikke så mærkeligt at de synes al koden ser kompleks ud.
brokkehoved (15) skrev:Fuck nogle idioter, så dum en udtalelse gør det fuldstændig klart, at konsulenterne fra Globeteam ikke selv kan, eller har prøvet at, implementere noget som helst. Så er det heller ikke så mærkeligt at de synes al koden ser kompleks ud.
Og hvis du kommer med lidt belæg for din udtalelse, lytter vi helt sikkert efter.
#16 & #17
Der er "doing it" og så er der "overdoing it".
Selvfølgelig er det en god ide at lave unit tests, men man behøver jo altså heller ikke gå over gevind.
Jeg vil mene at hvis ens metoder er så komplekse at man er nød til at teste dem alle sammen, så skulle man måske overveje at splitte tingene lidt mere op.
Selvfølgelig er der grænser for hvad der er logisk at splitte op, men der er dælme også grænser for hvornår det er logisk at bruge tid, penge, og linjer på at skrive tests
Der er "doing it" og så er der "overdoing it".
Selvfølgelig er det en god ide at lave unit tests, men man behøver jo altså heller ikke gå over gevind.
Jeg vil mene at hvis ens metoder er så komplekse at man er nød til at teste dem alle sammen, så skulle man måske overveje at splitte tingene lidt mere op.
Selvfølgelig er der grænser for hvad der er logisk at splitte op, men der er dælme også grænser for hvornår det er logisk at bruge tid, penge, og linjer på at skrive tests
webwarp (20) skrev:#18 men nu er deres funktioner netop rigtig, rigtig lange og komplicerede, så er vel ud fra disse præmisser at de bemærker det.. Uanset hvad, gør det dem ikke til idioter (mener det er en IQ omkring de 40).
En idiot er en person med en IK på under 20, hvilket der kun er meget få af i Danmark. (har mødt en, hun var meget, øh, sød)
#tests
Selvfølgelig skal der være noget der ligner 2-3 tests pr metode til et system som dette.
Pålidlighed og korrekthed er ekstremt vigtigt, så ud over at der indgår elementer fra TDD i udviklingen, så har de nok også brugt (eller burde) tid på at lave systematisk test.
(med metoder må man endelige ikke medtage setters, getters og andre trivialiteter)
Ud over det er der også integrationstests og systemtests,
Selvfølgelig skal der være noget der ligner 2-3 tests pr metode til et system som dette.
Pålidlighed og korrekthed er ekstremt vigtigt, så ud over at der indgår elementer fra TDD i udviklingen, så har de nok også brugt (eller burde) tid på at lave systematisk test.
(med metoder må man endelige ikke medtage setters, getters og andre trivialiteter)
Ud over det er der også integrationstests og systemtests,
Desuden er valget af Microsofts .NET 2.0 også kritiseret, da der allerede i 2010 var kommet en version 4.0 af .NET.
Jawa Striker (3) skrev:Wow JavaScript og .NET 2.0
Hvis det er det nyeste der blev lavet dengang... Så vil jeg ikke vide hvad alle de andre gamle systemer kører på.
lorric (7) skrev:#3 - Se denne kommentar: http://www.version2.dk/artikel/breaking-hemmelig-r...
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.
Vi tager lige tidslinien:
november 2004 - man starter moderniserings plan
januar 2005 - den konkrete plan som POLSAG er en del af godkendes
november 2005 - .NET 2.0 releases
maj 2007 - kontrakt indgåes med leverandør
november 2007 - .NET 2.0 opdateres og kaldes nu .NET 3.5
april 2010 - .NET 4.0 releases
december 2010 - pilot på Bornholm starter
februar 2012 - projektet droppes
Projektet startede med nyeste .NET version på tidspunktet og man undlod at opdatere 8 måneder inden produktet skulle tages i brug (og jeg vil formoder at al egentlig udvikling var afsluttet og produktet var i test på det tidspunkt).
buchi (24) skrev:(med metoder må man endelige ikke medtage setters, getters og andre trivialiteter)
Jeg har altid undret mig over hvorfor det er mere populært at undlade at unit teste getters og setters end det er at undlade at unit teste metoder hvor metodenavnet indeholder et 'n'.
Der er ingen saglig begrundelse for at undlade at teste nogle metoder som kan indeholde fejl.
Og skal man undlade at teste nogle tilfældigt udvalgte metoder så burde det vil være hip som hap hvordan man udvælger ...
:-)
brokkehoved (15) skrev:Fuck nogle idioter, så dum en udtalelse gør det fuldstændig klart, at konsulenterne fra Globeteam ikke selv kan, eller har prøvet at, implementere noget som helst. Så er det heller ikke så mærkeligt at de synes al koden ser kompleks ud.
Kolklik (18) skrev:
Der er "doing it" og så er der "overdoing it".
Selvfølgelig er det en god ide at lave unit tests, men man behøver jo altså heller ikke gå over gevind.
cluq (19) skrev:En sådan mængde unit test ville gøre det en enorm opgave at vedligeholde både kode og tests.
WTF?
Er Danmark virkeligt så langt bagefter med hensyn til software udvikling?
2-3 unit tests per metode i gennemsnit lyder ret beskedent.
McConnel foreslår f.eks. 1 + N test cases per metode hvor N er antal if's, løkker, and's/or's og switch cases.
Det skal være meget triviel kode for at komme under 2.
Og unit tests er ikke en ekstra omkostning men en besparelse over produktets livs cyklus.
Man investerer noget i implementations fasen/faserne, sparer noget i test fasen/faserne og sparer rigtigt meget i de 5-10-20 år hvor produktet skal vedligeholdes.
Nu tænker jeg bare højt, men at lave overkompliceret kode virker som en typisk måde for IT virksomheder og dets mange konsulenter at malke den danske stat.
Valget af sprog er som sådan godt nok når man tænker det startede i 2005. (Selvom jeg personligt finder JavaScript forfærdelig dumt på mange punkter, er der dog tidspunkter hvor det ikke kan løses nemt på andre måder). Jeg ville gerne have haft et eksempel på hvor Javascript var mere kompliceret end man ellers kunne have gjort det (f.eks. hvis de styler i javascript i stedet for at bruge CSS eller laver formvalidation i javascript i stedet for på serversiden)
Valget af sprog er som sådan godt nok når man tænker det startede i 2005. (Selvom jeg personligt finder JavaScript forfærdelig dumt på mange punkter, er der dog tidspunkter hvor det ikke kan løses nemt på andre måder). Jeg ville gerne have haft et eksempel på hvor Javascript var mere kompliceret end man ellers kunne have gjort det (f.eks. hvis de styler i javascript i stedet for at bruge CSS eller laver formvalidation i javascript i stedet for på serversiden)
arne_v (27) skrev:Jeg har altid undret mig over hvorfor det er mere populært at undlade at unit teste getters og setters end det er at undlade at unit teste metoder hvor metodenavnet indeholder et 'n'.
Der er ingen saglig begrundelse for at undlade at teste nogle metoder som kan indeholde fejl.
Jeg tror ideen er at de metoder er særligt simple, so evt. tests vil fylde got meget..
Men hvis en setter/getter bliver mere end blot at returnere en feltvariabel, så vi jeg da også begynde at teste dem :-D
desuden tror jeg man vil ram mange af dem i integrationstests og systemtests, hvor der nok også fokuseres lidt mere på code coverage?
cluq (30) skrev:
Ja, engang i 90'erne! Nu har verden af TDD jo udviklet sig en del siden dengang.
Med sand TDD rammer du i hvert fald 1 + N tests pr metode.
Problemet med TDD alene, er at man ikke er sikker på at ramme alle nødvendige tests, sådan nogle some bordercases etc. der kræver en lidt nærmere analyse. Så TDD vil ikke stå for sig selv i sådan et projekt.
Hvad med at Politiet udgav deres kravspecifikation og så kunne alle de kloge hoveder herinde udvikle POLSAG for dem?
hyænen (34) skrev:#32 Du er alt, der er galt med softwareudvikling, hvis du foreslår noget så hjernedødt.
Tror nu det var ment lidt som "Hvis i alle mener i er så kloge, så burde i jo kunne lave det!".. ikke som i "Jeg synes faktisk at i burde lave det!".. :P
Derimod ville din kommentar passe fint til #33! Jeg ville aldrig nogensinde ønske at politiets systemer blev opensource.
Paranoir (37) skrev:Derimod ville din kommentar passe fint til #33! Jeg ville aldrig nogensinde ønske at politiets systemer blev opensource.
Hvorfor ikke?
Paranoir (37) skrev:Derimod ville din kommentar passe fint til #33! Jeg ville aldrig nogensinde ønske at politiets systemer blev opensource.
Alt offentligt, og især kritiske systemer, burde være opensource...
På den måde ville man få den mest værdifulde peerreview.
Security by obfuscation er desuden ikke en måde at lave sikkerhed på.
buchi (39) skrev:Alt offentligt, og især kritiske systemer, burde være opensource...
Det ville ihvertfald gøre det nemmere at genbrug dele, når man skifter leverandør.
buchi (39) skrev:På den måde ville man få den mest værdifulde peerreview.
Det er teoretisk muligt.
Men jeg tvivler på at der i praksis er nogen som vil bruge den tid det tager at forstå krav og design for at kunne lave et effektivt review.
Det vil nok mest blive low level detaljer med kommentarer, navngivings standard og den slags.
buchi (39) skrev:Security by obfuscation er desuden ikke en måde at lave sikkerhed på.
Helt enig.
Lord HellFire (32) skrev:Hvad med at Politiet udgav deres kravspecifikation og så kunne alle de kloge hoveder herinde udvikle POLSAG for dem?
Paranoir (37) skrev:Tror nu det var ment lidt som "Hvis i alle mener i er så kloge, så burde i jo kunne lave det!".. ikke som i "Jeg synes faktisk at i burde lave det!".. :P
Nu ville jeg ikke blive vildt overrasket hvis nogen på newz.dk kritiserede noget uden at kunne gøre det bedre selv.
:-)
Argumentet er i dette tilfælde ret pseudo, da den her slags projekter kræver et stort team og lang tid.
Forstår simpelthen ikke hvordan deres krav kan være så avancerede. Skal de ikke blot kunne holde styr på biler og personer i dette system. Og så måske en form for opgave styring.
Og så nogle terminaler i bilerne og et menupunkt til at guide til nærmeste donut butik.
Der findes jo masser af systemer der kan dette som standard eller med ret beskedne tilretninger.
Fx.
Dynamics AX
Oracle
SAP
Forstår ikke man ikke kan bruge ovenstående som udgangpunkt istedet for at bygge softwaren fra bunden.
Er ikke udvikler :)
Og så nogle terminaler i bilerne og et menupunkt til at guide til nærmeste donut butik.
Der findes jo masser af systemer der kan dette som standard eller med ret beskedne tilretninger.
Fx.
Dynamics AX
Oracle
SAP
Forstår ikke man ikke kan bruge ovenstående som udgangpunkt istedet for at bygge softwaren fra bunden.
Er ikke udvikler :)
Atom (42) skrev:
Der findes jo masser af systemer der kan dette som standard eller med ret beskedne tilretninger.
Fx.
Dynamics AX
Oracle
SAP
Forstår ikke man ikke kan bruge ovenstående som udgangpunkt istedet for at bygge softwaren fra bunden.
POLSAG blev bygget på et standard system!
Captia ESDH.
Men man customizede så meget og på den forkerte måde at resulatet blev som det blev.
buchi (31) skrev:
Jeg tror ideen er at de metoder er særligt simple, so evt. tests vil fylde got meget..
Men hvis en setter/getter bliver mere end blot at returnere en feltvariabel, så vi jeg da også begynde at teste dem
Selv den trivielle version kan indeholde fejl. Copy paste, ret metodenavn men ikke feltnavn inden i metodeb.
Og når man skriver testen ved man næppe hvorvidt metoden forbliver trviel over hele systemets levetid.
buchi (31) skrev:desuden tror jeg man vil ram mange af dem i integrationstests og systemtests, hvor der nok også fokuseres lidt mere på code coverage?
Ja. Men det argument kan jo bruges om de fleste unit tests.
cluq (30) skrev:Ja, engang i 90'erne! Nu har verden af TDD jo udviklet sig en del siden dengang.
Den udgave af bogen jeg citerer fra er fra 2004.
Jeg har iøvrigt aldrig hørt at skift fra ikke-TDD til TDD eller fra gammel-TDD til ny-TDD skulle mindske antal unit tests.
Har du nogle gode referancer til dette?
arne_v (28) skrev:Og unit tests er ikke en ekstra omkostning men en besparelse over produktets livs cyklus.
Man investerer noget i implementations fasen/faserne, sparer noget i test fasen/faserne og sparer rigtigt meget i de 5-10-20 år hvor produktet skal vedligeholdes.
Desværre er mange ligeglade med løbende omkostninger - i chefers hoveder findes kun købsprisen. De glemmer at tænke på drift og vedligehold.
#44 Tak for info. Giver mening at de har valgt at bygge ovenpå et system men damn hvor kunne man få lavet mange tilretninger for 500mio.
Er det mig der regner forkert eller er det 333.333 udvikler/konsulent timer til 1500,- Noget af det er jo nok servere og terminaler men alligevel.
Er det mig der regner forkert eller er det 333.333 udvikler/konsulent timer til 1500,- Noget af det er jo nok servere og terminaler men alligevel.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund