allan ebdrup bloghoved ny

Resultat af efterlysningen (opdateret)

Dette er en opfølgning på mit blogidlæg
Undgå jQuery (DOM-selectors) i tykke JavaScript applikationer

Koder du ofte jQuery eller andet JavaScript med DOM-selectors, som getElementsByTagName?

Ja: 27 (46,6%)
Nej: 31 (53,4%)

Har du nogensinde op levet en at en DOM-selector, dvs. jQuery eller getElementById, getElementsByTagName, pludseligt har fejlet, af en af følgende grunde:

  • En anden udvikler har rettet noget kode du ikke var herre over.
  • Du har selv rettet noget kode, hvor det ikke var åbenlyst at det du rettede ville have indvirkning på DOM-selectoren, fordi det lå et helt andet sted end det kode der naturligt hørte sammen med DOM-selectoren.
  • En 3. parts komponent blev opdateret. 
  • Ja: 9 (33,3%)
    Nej: 18 (66,7%)

    Hvor blev fejlen opdaget?

    I udvikling: 5 (55,6%)
    I test: 2 (22,2%)
    I produktion: 2 (22,2%)

    Konklusion

    Der findes folk der har udfordringer med DOM-selectors, og fejlene ryger nogle gange helt ud i produktion.
     

    Opdatering

    Jeg kan prøve at illustrere hvad spørgsmålet går ud på, ved at indsætte en datepicker i stedet for:
    ––––––––-
    Har du nogensinde op levet en at din datepicker, pludseligt har fejlet, af en af følgende grunde:

    • En anden udvikler har rettet noget kode du ikke var herre over. (dvs. ikke en del af datePickeren)

    • Du har selv rettet noget kode, hvor det ikke var åbenlyst at det du rettede ville have indvirkning på Datepickeren, fordi det lå et helt andet sted end det kode der naturligt hørte sammen med DatePickeren.

    • En 3. parts komponent blev opdateret. 
      –––––––-
      Her vil ca. 100% svare nej
      Jeg mener en datapicker, som eksempel på et komponent der har fuldstændigt styr over hvad det bruger sin DOM selector på. Hele udfordringen er: Hvad vi gør når vi begynder at sætte disse komponenter sammen' Hvordan sikrer vi, at vores applikation forbliver robust' Hvordan sikrer vi, at vi kapsler vores komponenter sikkert ind'Skal vi fortsætte med at bruge DOM-selectors' Hvordan får vi bedst pakket den HTML og funktionalitet der hører til datePickeren (eller andre komponenter) ind.

    Skal vi fx lave en datePicker-abstraktion og så kun manipulere komponentet gennem dets abstraktion eller dens model' Skal vi så fortsætte med at lave grupper af komponenter. der også er en abstraktion (fx et timespan, med to datepickers der interagerer), med en logisk model vi manipulerer med. Hvordan sikrer vi bedst at dette virker'

    Er denne strategi med komponenter der kan kombineres på kryds og tværs foreneligt med at bruge DOM-selectors' Hvis det er foreneligt, er der helt sikkert nogle regler man skal følge, når man bruger DOM-selectors, da disse ikke bare uden videre overholder de regler vi har for hvad der hører til i de enkelte komponenter. Hvordan sikrer vi på forskellig vis robuste løsninger'

    Kommentarer (28)
    sortSortér kommentarer
    • Ældste først
    • Nyeste først
    • Bedste først
    Vijay Prasad

    Et lille opfølgende skema:

    1) Koder du ofte?

    2) Har du oplevet at kode er fejlet? (pga. andres fejl, egne fejl, fejl i 3. parts komponenter)

    3) Hvor blev fejlen opdaget? (udvikling, test, produktion)

    Er resultatet forskelligt fra "efterlysningen"? :-)

    Mvh,

    • 0
    • 0
    Allan Ebdrup Blogger

    Ja, der er forskel, prøv at læse hvad der står igen.
    Dit spørgsmål:

    2) Har du oplevet at kode er fejlet? (pga. andres fejl, egne fejl, fejl i 3. parts komponenter)

    Ville være 100%

    Hele pointen er, at med DOM-selectors kan du få en ringe robusthed overfor alle andres ændringer. Og det er vel og mærke ikke andres kode der fejler, men din kode der pludseligt fejler, pga noget du ikke er herre over.

    • 0
    • 0
    Vijay Prasad

    Hele pointen er

    Og min pointe er, at jeg har oplevet kode som er fejlet i produktion, lige meget hvilken teknologi der er benyttet :-)

    Jeg er meget ked af at udtale mig generelt pga. manglende data, men min "gut feeling" siger mig at projekter hvor script-sprog er benyttet oftere har fejlet i produktion - javascript et af dem.

    Fortsat god weekend der!

    Mvh,

    • 0
    • 0
    Morten Sjøgren

    Jeg er meget ked af at udtale mig generelt pga. manglende data, men min "gut feeling" siger mig at projekter hvor script-sprog er benyttet oftere har fejlet i produktion - javascript et af dem.

    Jeg har ihvertfald oplevet det mange gange med JavaScript, men langt de fleste af dem var fejl som kunne være fundet ved brug af værktøj jslint, der tjekker for de mest åbenlyse fejl, derfor tjekker jeg al min kode med jslint i dag. Det giver mere tid til de interessante problemer.

    • 0
    • 0
    Allan Ebdrup Blogger

    Og min pointe er, at jeg har oplevet kode som er fejlet i produktion, lige meget hvilken teknologi der er benyttet :-)

    Men skal det afholde os for at diskutere principper for godt software-design, og checke om lige netop denne fejl som diskussionen handler om, forekommer i praksis.

    God uge :-)

    • 0
    • 0
    Jacob Christian Munch-Andersen

    Jeg synes nu ikke at der er særligt meget at konkludere ud fra din undersøgelse, der er overhovedet ingen dybde i den, fx har vi ikke fået svar på hvilke dom selectors der har været tale om, jeg vil da tro at class i denne sammenhæng er meget "farligere" end id.

    Men uanset, som jeg har været inde på før, det er ikke forkert at bruge en funktion blot fordi den kan give problemer, men det er da godt at være opmærksom på hvad der kan ske så man kan tage sine forholdsregler.

    Jeg håber at nogle af dem som har svaret positivt kan droppe en stump kode for at demonstrere problemet.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Der findes folk der har udfordringer med DOM-selectors, og fejlene ryger nogle gange helt ud i produktion.

    Er det er joke?!

    Vi kan udskifte DOM-selectors med X og så sætte hvad som helst ind, jeg vil påstå at udsagnet er sandt ligegyldig hvad X er, eller må du godt modbevise og vise mig X der giver falsk?

    Hvis du virkelig vil provokere skal du nok prøve X=programmering.

    • 0
    • 0
    Allan Ebdrup Blogger

    Det er muligt jeg har formuleret mine spørgsmål uhensigtsmæssigt, jeg indrømmer gerne at det ikke er min spidskompetence. Det jeg prøver at fange er de tilfælde hvor det at bruge en DOM-selector går galt fordi man ikke har kontrol over det man selecter over.
    Når man bruger DOM selectors over HTML der er sammensat af komponenter fra flere forskellige steder.
    Det er derfor det er vigtigt at det der bliver ændret enten bliver ændret af en anden udvikler et helt andet sted, eller ligger i en helt anden komponent.
    I de tilfælde hvor du har en vertikal opdeling af din frontend, kan denne opdeling "ødelægges" af at du har DOM-selectors der kommer til at arbejde på ting der ligger udenfor dens "boks".
    Ulempen ved det er at det kan gå galt på ret uforudsigelige måder.

    • 0
    • 0
    Allan Ebdrup Blogger

    Men uanset, som jeg har været inde på før, det er ikke forkert at bruge en funktion blot fordi den kan give problemer, men det er da godt at være opmærksom på hvad der kan ske så man kan tage sine forholdsregler

    Enig, det er denne diskussion jeg synes er spændende.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Det er muligt jeg har formuleret mine spørgsmål uhensigtsmæssigt, jeg indrømmer gerne at det ikke er min spidskompetence. Det jeg prøver at fange er de tilfælde hvor det at bruge en DOM-selector går galt fordi man ikke har kontrol over det man selecter over.
    Når man bruger DOM selectors over HTML der er sammensat af komponenter fra flere forskellige steder.
    Det er derfor det er vigtigt at det der bliver ændret enten bliver ændret af en anden udvikler et helt andet sted, eller ligger i en helt anden komponent.
    I de tilfælde hvor du har en vertikal opdeling af din frontend, kan denne opdeling "ødelægges" af at du har DOM-selectors der kommer til at arbejde på ting der ligger udenfor dens "boks".
    Ulempen ved det er at det kan gå galt på ret uforudsigelige måder.

    Uden at sige, at ovenstående er forkert, er problemstillingen fuldstændigt den samme hvis vi taler system til system kommunikation vha. f.eks. XML Services.
    Jeg synes ikke DOM selectors på den måde er specielle.

    Jeg tror også, at det du mener er om vi kan strukturere samarbejde på en måde, så vi undgår faldgruberne for f.eks DOM selectors mm.

    • 0
    • 0
    Carsten Sonne

    Vi kan udskifte DOM-selectors med X og så sætte hvad som helst ind, jeg vil påstå at udsagnet er sandt ligegyldig hvad X er, eller må du godt modbevise og vise mig X der giver falsk?

    Der er forskel på hvor nemt det er at lave (design) fejl med forskellige teknologier. Generelt, jo større frihed og kontrol en given teknologi giver dig, jo større er risikoen for fejl.

    Man kan sammenligne det med motorsport. Jo større og kraftige motor, jo større risiko for ulykke.

    En mere jordnær sammenligning er C afviklet i kernel mode imod C# afviklet af CLR.

    Men skal det afholde os for at diskutere principper for godt software-design, og checke om lige netop denne fejl som diskussionen handler om, forekommer i praksis.

    Nej, det skal det lige præcis ikke. Jo stærkere teknologi og jo mere kompleks software, jo større er behovet for at fastholde et robust og vedligeholdelsesvenligt design.

    Det kræver tid, disciplin og en erkendelse af det er nødvendigt.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Der er forskel på hvor nemt det er at lave (design) fejl med forskellige teknologier. Generelt, jo større frihed og kontrol en given teknologi giver dig, jo større er risikoen for fejl.

    Man kan sammenligne det med motorsport. Jo større og kraftige motor, jo større risiko for ulykke.

    Vil du dermed mene der er større mulighed for at lave designfejl ved at programmere end ved at tegne i UML værktøjer?

    Deri er jeg meget uenig.

    Din antagelse er forkert.
    Jeg kan fortælle at antallet af fejl i programmet er ligefrem proportionalt med antallet af tegn i source koden (oftest omtalt linier). Derfor indeholder programmer skrevet i meget verbose sprog som C/C++/Java/C# mange fejl sammenlignet med mindre verbose sprog som f.eks. Groovy. Dette upåvirket af at Groovy er dynamisk typet.
    Det har ikke noget med teknologien at gøre.

    Ligesom antallet af ulykker er proportinalt med antallet af trafikanter, og intet har med motorstørrelsen at gøre. Riskoen for uheld/ulykke er større i Formel 1 når der er 22 på banen end når der er 2. Ikke om motoren er på 700 hk eller 800 hk.

    En mere jordnær sammenligning er C afviklet i kernel mode imod C# afviklet af CLR.

    Does not compute, hvordan sammenligner du dem - ud fra teknologi kompleksitet?
    Så kan du da ikke sammenligne deres afviklingsmiljø, det giver da absolut ingen mening.

    • 0
    • 0
    Carsten Sonne

    Vil du dermed mene der er større mulighed for at lave designfejl ved at programmere end ved at tegne i UML værktøjer?

    Spørgsmålet ikke forstået.

    Din antagelse er forkert.

    Hvilken antagelse?

    Does not compute, hvordan sammenligner du dem - ud fra teknologi kompleksitet?

    C afviklet i kernel mode:
    Egen hukommelsesstyring
    Adgang til hardware registrer
    Adgang til hukommelse uden for process

    C# afviklet af CLR:
    Garbage collection
    Abtraktionlag uden direkte adgang til hardware
    AppDomains med beskyttet hukommelse.

    Etc.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Spørgsmålet ikke forstået.

    At man har meget størrer frihedsgrader til udfoldelse ved at skrive kode, end ved at tegne i UML. Du skriver jo selv at man laver flere (design)fejl når der ikke er faste rammer.
    Eller har jeg helt misforstået dig?

    Hvilken antagelse?

    Er du blind :-) Den antagelse du fremsætter, jeg skal gerne skrive det igen:

    Der er forskel på hvor nemt det er at lave (design) fejl med forskellige teknologier. Generelt, jo større frihed og kontrol en given teknologi giver dig, jo større er risikoen for fejl.

    Man kan sammenligne det med motorsport. Jo større og kraftige motor, jo større risiko for ulykke.

    Jeg kan så også spørge dig hvad <I>"jo større frihed og kontrol en given teknologi giver"</I> betyder?

    C afviklet i kernel mode:
    Egen hukommelsesstyring
    Adgang til hardware registrer
    Adgang til hukommelse uden for process

    C# afviklet af CLR:
    Garbage collection
    Abtraktionlag uden direkte adgang til hardware
    AppDomains med beskyttet hukommelse.

    Ja men Carsten, hvordan er det du kan sætte lig med tegn mellem et runtime miljø, og risikoen for at lave fejl? det er jo C og C# vi sammen ligner og ikke deres afviklingsmiljø.

    • 0
    • 0
    Carsten Sonne

    At man har meget størrer frihedsgrader til udfoldelse ved at skrive kode, end ved at tegne i UML. Du skriver jo selv at man laver flere (design)fejl når der ikke er faste rammer.

    UML er ikke umiddelbart sammenligneligt med programmering som koncept. Slet ikke ift. risikoen for fejl. Problemområdet er simpelthen forskelligt.

    UML er rettet mod en visuel fremstilling af en applikation ud fra diagram form. Mulighederne for fejl her, er typisk rettet imod misforståelser af forretningskoncepter og i problemdomænet. Lidt på samme måde som database diagrammering, f.eks. ER diagrammer.

    Programmering er rettet imod en operativ løsning af et problem. Du skriver noget kode, der gør noget, med henblik på at løse et problem.

    Der er som sådan ingen modsætning imellem de 2 ting. Tværtimod.

    Eller har jeg helt misforstået dig?

    Det lyder såden.

    jo større frihed og kontrol en given teknologi giver.

    Lad mig komme med 2 andre eksempler fra den virkelige verden.

    En kniv er et kraftigere våben end en kølle. En atombombe er et kraftigere våben end en kniv. De har alle forskelligt potentiale ift. størrelsen af en ulykke.

    På en trehjulet cykel kan du kun skade dig selv. Måske kan du køre ind i benet på en forbipasserende og give ham/hende et blåt mærke. En 40 tons lastbil eller en Formel 1 vogn, kan dræbe adskillige mennesker under de rette (forkerte) omstændigheder.

    Er det fordi du ikke kan følge tankegangen eller underkender du en sammenhæng imellem frihed/kontrol/magt og risikoen for ulykker/fejl?

    det er jo C og C# vi sammen ligner og ikke deres afviklingsmiljø.

    Nej, jeg sammenligner de 2 helheder med det formål at videreformidle et budskab.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Lad mig komme med 2 andre eksempler fra den virkelige verden.

    En kniv er et kraftigere våben end en kølle. En atombombe er et kraftigere våben end en kniv. De har alle forskelligt potentiale ift. størrelsen af en ulykke.

    På en trehjulet cykel kan du kun skade dig selv. Måske kan du køre ind i benet på en forbipasserende og give ham/hende et blåt mærke. En 40 tons lastbil eller en Formel 1 vogn, kan dræbe adskillige mennesker under de rette (forkerte) omstændigheder.

    Er det fordi du ikke kan følge tankegangen eller underkender du en sammenhæng imellem frihed/kontrol/magt og risikoen for ulykker/fejl?

    Jeg underkender at risikoen for fejl/ulykke afhænger af om det er en cykel eller en bil der er tale om, , fordi en bil har en større motor - hvilket du påstulerer. Det er forkert.
    Potentialet for ødelæggelse hvis en ulykke indtræffer er afhængigt af mange faktorer, dog ikke den teknologiske kompleksitet hvormed de 2 sammenlignede objekter er fremstillet. Det giver ingen mening.

    At sige en A-bombe har større ødelæggelseskraft end 1 kniv har intet med dette indlæg at gøre - overhovedet.

    Lad mig igen citere dig:

    Der er forskel på hvor nemt det er at lave (design) fejl med forskellige teknologier. Generelt, jo større frihed og kontrol en given teknologi giver dig, jo større er risikoen for fejl.

    Man kan sammenligne det med motorsport. Jo større og kraftige motor, jo større risiko for ulykke.

    Mener du stadigvæk at risikoen for ulykke ved motorsport er afhængig af størrelsen på motoren? For hvis du mener det, så nej - jeg kan ikke følge din tankegang - men at den er afhængig af f.eks. antallet af samtidige biler på banen kan jeg se - det har blot intet med dit indlæg eller Allans artikel at gøre.

    underkender du en sammenhæng imellem frihed/kontrol/magt og risikoen for ulykker/fejl

    Tjaa - jeg ser ikke en entydig sammenhæng - hvad består den i?

    Nej, jeg sammenligner de 2 helheder med det formål at videreformidle et budskab.

    Den eneste forskel er at C kan få din computer til at gå ned, og det er lidt vanskeligere i C#. Altså at virkningen af en fejl (og ikke risikoen for at lave dem) er større i C.
    Men hvad var budskabet?

    • 0
    • 0
    Carsten Sonne

    Hej Nikolaj,

    Helt ærligt, hvad har overstående med sagen at gøre? Prøv at holde fokus på emnet.

    Jeg vil godt skære det ud i pap for dig:

    1) Frihed - Jo flere frihedsgrader du har, jo større risiko er der for at lave en fejl. Hvis du har 2 muligheder, er der 50% sandsynlighed for at vælge den optimale. Hvis du har 100 muligheder, er der 1% for at vælge den optimale.

    2) Kontrol - Jo flere ting du kan kontroller, jo større risiko for at du styre noget i en forkert retning. Hvis du har 2 ting du skal holde styr på er det nemmere end hvis du har 100 ting at holde styr på.

    3) Magt - Jo større magt du har, jo større risiko er der for at du uforvarende får anvendt din magt uhensigtsmæssigt.

    4) Stærkere teknologi = frihed + kontrol + magt.

    5) kompleks software = Størrelse + logisk kompleksitet.

    Jeg underkender ikke dine pointer. Jeg ser heller ikke det du fremføre som egentlig modsætninger. Jeg ved ikke hvad din agenda er eller hvorfor du forsøger at flytte fokus. Du kan være uenig. Det er i din gode ret. Hvis du ikke vil forstå, er det ikke mit problem.

    Anti-pattern:
    http://en.wikipedia.org/wiki/Anti-pattern

    Hav en god aften.

    Mvh
    Carsten Sonne Larsen

    • 0
    • 0
    Allan Ebdrup Blogger

    Der findes folk der har udfordringer med datepicker-komponent, og fejlene ryger nogle gange helt ud i produktion.

    Rigtigt, men nu var det ikke det der var spørgsmålet. Det skal nærmere være:

    Har du nogensinde op levet en at din datepicker, pludseligt har fejlet, af en af følgende grunde:

    • En anden udvikler har rettet noget kode du ikke var herre over. (dvs. ikke en del af datePickeren)

    • Du har selv rettet noget kode, hvor det ikke var åbenlyst at det du rettede ville have indvirkning på Datepickeren, fordi det lå et helt andet sted end det kode der naturligt hørte sammen med DatePickeren.

    - En 3. parts komponent blev opdateret.

    Jeg mener en datapicker som eksempel på et komponent der har fuldstændigt styr over hvad det bruger sin DOM selector på.
    Hele udfordringen er: Hvad vi gør når vi begynder at sætte disse komponenter sammen? Hvordan sikrer vi at vores applikation forbliver robust? Hvordan sikrer vi at vi kapsler vores komponenter sikkert ind?

    Skal vi fortsætte med at bruge DOM-selectors? Hvordan får vi bedst pakket den HTML og funktionalitet der hører til datePickeren (eller andre komponenter) ind. Skal vi fx lave en datePicker-abstraktion og så kun manipulere komponentet gennem dets abstraktion eller dens model?

    Og skal vi så fortsætte med at lave grupper af komponenter der også er en abstraktion (fx et timespan, med to datepickers der interagerer), med en logisk model vi manipulerer med. Hvordan sikrer vi bedst at dette virker? Er denne strategi med komponenter der kan kombineres på kryds og tværs foreneligt med at bruge DOM-selectors? Hvis det er foreneligt, er der helt sikkert nogle regler man skal følge, når man bruger DOM-selectors, da disse ikke bare uden videre overholder de regler vi har for hvad der hører til i de enkelte komponenter.

    Hvordan sikrer vi på forskellig vis robuste løsninger?

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Carsten, tak for pap-skiltet. Hvad har det så med motorsport og størrelsen på motoren at gøre?

    I øvrigt henvendte du dig til mig - ikke omvendt.

    Så lad mig beskrive min agenda. Risikoen for at lave fejl i programmering er mest afhængig af antallet af anslag du skal lave for at frembringe dit resultat.

    Nej, det skal det lige præcis ikke. Jo stærkere teknologi og jo mere kompleks software, jo større er behovet for at fastholde et robust og vedligeholdelsesvenligt design.

    Det kræver tid, disciplin og en erkendelse af det er nødvendigt.

    Jeg tror vist også vi kan blive enige om ikke at fastholde et design, men at vedligholde og udvikle det sammen med resten af løsningen (http://agilemanifesto.org/).

    Anti-pattern:
    http://en.wikipedia.org/wiki/Anti-p...

    Jeg er udemærket klar over både software patterns og anti-patterns.

    God aften til dig også

    PS: Jeg var iøvrigt ikke ude på at flytte fokus. Jeg synes bare den statistik der blev brugt til at drage en konklusion på i teksten var tynd. Ligesom jeg synes konklusionen er af en så generel art, at den kan benyttes på alt. Her bragte du noget op om Motorsport, A-våben, knive og risiko.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Allan:

    Jeg er sådan set enig med dig. Men mener stadig det er generelt og ikke kun omkring HTML/JS udvikling. Men f.eks. i store SOA/EDA opsætninger er der samme problem bare på flere fronter. Først lokalt indenfor det team som frembringer en eller anden komponent der skal arbejde sammen med andre komponenter. Dernæst mellem de distribuerede teams der sammen frembringer den egentlige løsning. Til sidst i forhold til alle mulige ekstern interessenter og samarbejdspartere hvor der skal laves integrationer.
    Her handler det om at definere og vedligeholde en måde at vill samarbejde på.

    F.eks. er det jo sjovt hvordan Internet Browsere bliver ved med at vise forståelige sider, selvom folk har skrevet det værste hø af HTML som hverken overholder den ene eller anden specifikation, eller er well formed.

    Det kan vi lære noget af i generel udvikling. For uden Browserens liberale holdning til hvad den viser, havde internettet ikke fungeret.
    Postels Law er defineret ved "be liberal in what you receive, but be conservative in what you send". Med andre ord: Gør alt hvad du kan for at det skal lykkedes med det du får smidt i hovedet, men overhold specifikationerne når du kommunikerer udadtil med andre.

    Jeg tror ovenstående er et meget godt fundament, og det vil også få alle de klovner som laver XML Schema med en Person type der har en Sequence med FirstName og LastName til at lave det om til en All. Rækkefølgem på fornavn og efternavn elementerne er altså ligegyldig.
    Man kan sammenligne det lidt med at submitte en form på internettet i en net butik. Optimalt vil form submit blive godkendt så længe der lige nøjagtigt blev indtastet nok oplysninger til købet kan gennemføres, og ikke som på nogle webshops hvor f.eks. telefonnummer er mandatory, og man kan nøjes med at indtaste 12345678. Der er åndsvagt og fordre ikke nem samarbejde eller validt indhold.

    • 0
    • 0
    Carsten Sonne

    Risikoen for at lave fejl i programmering er mest afhængig af antallet af anslag du skal lave for at frembringe dit resultat.

    Hvordan hænger det sammen med

    Jeg er udemærket klar over både software patterns og anti-patterns.

    Antipatterns som Big ball of mud, God object og Cargo cult programming? Hvordan hænger det så sammen med det agile begreb technical dept?

    Det kan godt være jeg er på vildspor, men du famler da i tågen.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    Risikoen for at lave fejl i programmering er mest afhængig af antallet af anslag du skal lave for at frembringe dit resultat.

    Ok, jeg prøver igen. Antallet af fejl i software er ligefrem proportionalt med antallet af liniers source kode som programmet består af. Er du uenig? Svar venligst - for er du uenig så har vi ikke mere at tale om - så er du for useriøs til at jeg kan tage dig alvorligt.

    Hvordan hænger det sammen med

    Den sammenhæng er det vist dig der prøver at lave. Men iøvrigt er de 2 udsagn ikke i modstrid.

    Jeg synes software patterns er rigtig fine og benytter dem hver eneste dag, ligesom du sikkert gør. Jeg følte nok ligesom du en revolution da GoF bogen udkom - og har købt og læst pattern bøger som henvender sig til både Java, Smalltalk og andre sprog.

    Anti-patterns er jeg også udemærket klar over, som konsulent er det min opgaven at enten rydde op i det, og/eller forhindre de opstår.

    Antipatterns som Big ball of mud, God object og Cargo cult programming? Hvordan hænger det så sammen med det agile begreb technical dept?

    Det hænger fint sammen, jeg forstå ikke spørgsmålet?

    Man skal dog holde sig fra at bruge anti-patterns eller andre emner man har læst op på i en bog til at dunke nogen oven i hovedet med, sådan som du gør i dit indlæg.
    Så har de totalt mistet deres værdi, ligesom patterns og andre samlinger af best-practices og worst-practices gør.

    Det kan godt være jeg er på vildspor, men du famler da i tågen.

    Jeg troede du var til at have en debat med, og jeg ville bare have du skulle komme med belæg for dine påstande om motorsport, a-bomber og knive. Men ok du er af typen der hvis du ikke får ret, bliver personlig og skal svine andre til.
    Du fremstiller dermed dig selv komplet useriøst og usympatisk - jeg er ikke sikker på det er sådan du gerne vil fremstå, eller...?

    PS: Hvornår forholder du dig til mit spørgsmål til din påstand om at riskoen for uheld i motorsport er afhængig af motorens størrelse?

    • 0
    • 0
    Carsten Sonne

    Antallet af fejl i software er ligefrem proportionalt med antallet af liniers source kode som programmet består af. Er du uenig? Svar venligst - for er du uenig så har vi ikke mere at tale om - så er du for useriøs til at jeg kan tage dig alvorligt.

    Ja, jeg er uenig.

    Du fremstiller dermed dig selv komplet useriøst og usympatisk - jeg er ikke sikker på det er sådan du gerne vil fremstå, eller...?

    Ditto.

    Hvornår forholder du dig til mit spørgsmål til din påstand om at riskoen for uheld i motorsport er afhængig af motorens størrelse?

    Jeg tog fejl.

    • 0
    • 0
    Nikolaj Brinch Jørgensen

    @Carsten:

    Ja, jeg er uenig.

    Fint så skal jeg ikke forstyrre dig mere omkring dette emne, men du kunne jo så læse http://en.wikipedia.org/wiki/Source_lines_of_code, måske du kunne lære noget?

    Konsulenter burde tit og ofte betales for liniers kode de sletter og ikke kode linier de tilføjer.

    Ditto.

    Kan du forklare mig hvad det er du føler dig så fornærmet over jeg har sagt. Du kan vel ikke være fornærmet over at jeg har påpeget at din analogi med motorsport ikke holder?

    Jeg tog fejl.

    Ja, så slut med den - men det var åbenbart meget svært at indrømme.

    • 0
    • 0
    Log ind eller Opret konto for at kommentere