Debugging den tabte generation

Dagens debug-summit var en utrolig positiv oplevelse for mig.

Det er meget tydeligt, i hvertfald i det selskab, at der sker en hastig professionalisering af IT branchen.

Det har jeg savnet i ca. 20 år.

På sin vis vil jeg påstå at dagens møde kunne være holdt præcist magen til i 1993, dengang, inden IT branchen exploderede med en faktor 1000, talte man også om at professionalisere programudviklingen, at undgå debugging ved at forbedre koden på forhånd osv. osv.

Intet sted var det tydeligere end med foredraget om debugging af Linux kernen, der om noget software har repræsenteret dot-com generationen i trods-alderen.

Som en stor fan af den naturvidenskabelige metode er det naturligvis rart at se at de genopfinder præcis de samme løsninger som alle andre har fundet år, eller i visse tilfælde årtier tidligere, men efterhånden burde nogen i den lejr begynde at lugte lunten og stoppe "Kan Selv!" flippet.

I virkeligheden var der ikke ret meget nyt idag.

Den ene teknologi vi så idag der ikke var mainstream i 1993, var grafiske IDE'er.

De fandtes dengang, på Rational R1000 Ada maskiner, men mainstream var de bestemt ikke.

Det er de idag, men med al respekt for foredragsholderne, så var de grafiske IDE'er ikke stjernerne idag.

Jeg skal ikke gøre mig klog på om man faktisk kan debugger Java på anden vis, men IDE som fremtidens debugging-mirakel køber jeg ikke.

En anden ting jeg bed mærke i idag, var at Microsoft er faldet i samme hul som IBM's mainframes: Et mareridt af dump-typer, dump-fortolkere der skal gøre bunkerne af rå bits nemmere at læse, men som ofte kun hjælper marginalt.

At Microsoft og IBM begge er havnet i denne blindgyde har samme underliggende årsag: Det koster at være default platformen hvor selv de ringeste programmører kan få job.

Forestil jer, at hver programmør på Windowsplatformen bare en gang i sit liv finder hvad de tror er en OS fejl og sender en dumpfil til Microsoft.

De tager næsten alle fejl, men hos Microsoft vælter dumpfilerne ind og man har brug for værktøjer der gør det nemmere at returnere "blame-allocation" serven.

For enden af det mareridt ligger "dumpfils-analysers" med en komplex plug-in-arkitektur således at hvert stykke buggy middelware kan plugge sig selv ind og lave lort i debug-processen også. Inden længe skal man til at analysere dumpfiler fra dump-fil analysator programmet...

Nej, dump-filer er helt klart ikke vejen frem.

Konklusionen idag, idet omfang der var en, er at debugging handler rigtig meget om erfaring, ikke mindst den erfaring at debugging overhovedet ikke er sjovt og at det derfor bedre kan betale sig at bruge 10-30% af tiden up front på program-kvalitet, frem for 120% senere på debugging.

Det er et budskab mange virksomhedsledere og politikere har brug for at få banket ind i hovedet med al nødvendig magt.

Digital Tinglysning skandalen handlede f.eks i bund og grund om at man "ikke havde tid og råd til alle de tests" -- med helt forudsigelige resultater.

Den påståede "ældre-visere" korrelationen er bestemt relevant, hvilket bringer mig til dagens to første og på sin vis vigtigste foredrag: Hvordan håndterer vores IT uddannelser debugging.

Forskellen på Ballerup og Herning var ikke større end i så mange andre emner: I Jylland får man tingene til at virke, på den ene eller den anden måde, nær København er der ingen ting der kan lade sig gøre uden at der går politik i det. Det lyder utroligt bekendt.

Min personlige mistanke har altid været at debugging forudsætter at man faktisk forstår hvad der sker mens computeren kører.

Forstår man ikke run-time miljøet, kan man ikke formulere gode og brugbare hypoteser for hvad der kan være galt og dermed ikke opstille forsøg der skal afgøre deres sandhedsværdi.

Alle kender den tendens mennesker til at pege på ting man ikke forstår som ondets rod: Det er en compiler-fejl, det er en fejl i garbage-collect, det er databasen der ikke kan finde ud af at bruge sine index osv.

Selvfølgelig forstår man i et eller andet omfang hvad der sker i Python, JVM eller på toppen af en zMachines elfenbenstårn, men man forstår det ikke rigtigt for der er tusinder stumper kode at forstå, fra garbage-collect til CICS og VTAM.

Selve OO-conceptet er formodentlig problematisk, rent undervisningsmæssigt, for der er ikke noget OO over hvad maskinen faktisk gør: OO er et abstraktionslag der skubbes ind imellem sproget vi programmere i og maskinen vi kører på og først når man forstår hvorledes den abstraktion er implementeret, kan man gennemskue hvorledes man debugger på tværs af den.

Jeg de har fat i den rigtige ende i Herning: En lille ARM processor med C kode er en sandkasse man kan overskue og forstå: Timingproblemerne skyldes ikke en dårlig video-driver, den blendede datafil er ikke et resultat af anti-virus programmet: Der er noget hardware, der er noget kode I selv har skrevet. Gæt selv hvor fejlen skal findes. Det er en pædagogisk brugbar situation. Det var ihverfald sådan jeg lærte debugging.

Debugging er ikke bare værktøjer og metode, det er også et arbejde.

Flere af indlægsholderne var inde på at de rigtig svære debug-opgaver havnede samme sted hvergang: Hos en lille flok garvede medarbejdere der bare kan det pis.

I et ikke navngivet firma havde man taget konsekvensen og samlet en håndfuld af dem og givet dem ansvaret og det havde givet pote.

Det fremgik dog mellem linierne, at det ikke var noget de gjorde til en karierre, forstået på den måde at efter et halvt års tid, var det på tide at skifte ud i holdet.

Men spørgsmålet jeg sad tilbage med, var om det i virkeligheden var debugging den gruppe foretog sig og hvis det var, om det var af koden eller udviklingsprocessen ?

Havde man i virkeligheden udstyret dem med et arkitektonisk mandat via bagdøren, så de kunne få rettet de værste stukturelle problemer, få elimineret de arkitektoniske klumsetheder der førte til at der kom så mange fejl til at begynde med ?

Jeg kan ihvertfald sagens forestille mig fire erfarne medarbejdere, behørigt mandateret, ville stikke hovederne sammen og komme frem til at "Nu kan vi endelig slippe af med ${midlertidig_klamphuggeri} modulet."

Kunne man have opnået samme effekt ved at have udpeget en arkitekt til at begynde med ?

Desværre kunne de to ledere der fremlagde denne historie ikke byde ind med den anden halvdel af vinklen: Hvad lærte ledelsen om debugging ? og debuggings plads og allokering i projektforløbet ? Det er ellers også en rigtig øm tå.

Mit eget indlæg endte som en slags opsummering på dagen, for stort set hver evig eneste pointe jeg havde planlagt, var blevet nævnt eller brugt af andre foredrag i dagens løb:

  • Kod defensivt, "smart" kode er for svært at debugge.

  • Brug kode-analyse værktøjer, fra -Wall til Flexelint og Valgrind.

  • Assert() at du ved hvad der foregår, det virker både som dokumentation og fejl-check.

  • Find og reager på fejlen så tidligt som muligt, både i programmet og i udviklingsafdelingen.

  • Når fejlen sker, få programmet til at spytte brugbar high-level debug information ud, frem for bjerge af core-dumps.

  • Test koden, de fejl der ikke er der, tager ingen tid at debugge.

En stor tak til Peter og Kenneth for initiativet, til Mediehuset Ingeniøren/Version2 for lokalerne og Danske Commodities for at sponsere.

phk

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jakub Nielsen

Som leder for et antal software udviklere har jeg taklet problemstillingen på følgende måde: når teamet har været samlet af en eller anden grund, så blev de stillet over for følgende situation: Det er lørdag aften og det mest kritiske lort er braget ned. Driften har givet op og de er nu kaldt på arbejde. Alle ledelseslagene er gået i panik og skælder ud, at det skal fikses nu nu nu.....

Hvad vil de gerne have af hjælp i den situation og hvad vil de ønske var gældende for koden?

På eller anden måde, så kommer vi altid igennem at koden skal være simpel, der er de nødvendige (og ikke flere end det) logstatements, koden har pæn exceptionhåndtering og så videre. Følg op på det et par gange med offentlige kodereviews fra hele teamet, så folk der alligevel spring over hvor gæret er lavest får det lært. Hvis man ser at man kan sidde lørdag aften og skulle debugge kollegaens hovedet-under-armen, så bliver det vi er blevet enige om, fuldt op på.

  • 1
  • 0
Bo Holst-Christensen

Det er desværre ikke helt så simpelt som du gør det til, da du sammenligner to forskellige uddannelser med forskellige formål:

Det jeg udtalte mig om i går var uddannelsen af software ingeniører, mens eksemplet fra Herning drejede sig om embedded design, hvor der fokuseres mere på bottom up.

Det gjorde man også tidligere på software design uddannelserne, men man konstaterede som tiden gik, at man fik et mindre optag. Man har så forsøgt at rette op på dette ved at gøre kursene mere "motiverende" for de studerende, typisk ved at erstatte programmeringskurser med temakurser - så om spilteori, animation, o.s.v. - hvor man forsøger at give programmering som et biprodukt af det overordnede tema.

Man havde typisk også på disse uddannelser et kerne/OS/embedded kursus, men dette er nu typisk erstattet med noget mere motiverende, såsom robotteori, hvor de studerende skal bygge en robot det styres af netop en simpel ARM maskine, der giver adgang til det rå metal.

Det vil sige, at man giver de studerende et formål med at sætte sig ind i et lavniveau område, hvilket som udgangspunkt er en god ide.

Man indfører top down for at løse problemet med at man mener de studerende finder bottom up uinspirerende - hvilket betyder at man lægger mere pensum ind på et højere niveau, som så betyder at hvis belastningen skal være det samme, må man skrue ned for detaljerne på de lavere niveau.

Det vil sige at når jeg ser de studerende igen - typisk i forbindelse med deres afgangprojekt - så er fejlfinding stadig ikke noget de beskæftiger sig særligt meget med - undtagen i de uger i løbet af forløbet hvor alt står stiile mens de prøver at få deres software til at virke.

I forbindelse med embedded uddannelserne - så giver det indlysende også en bedre forståelse for det rå jern - men det er jo så netop også formålet med disse uddannelser - til gengæld er der en hel del af pensum på softwareuddannelserne der ikke medtages - typisk på de højere lag.

De forskellige uddannelsesinstitutioner, herunder DTU, reviderer løbende alle diplomingeniøruddannelser. Som trenden er i øjeblikket, så vil det der idag er en IT ingeniør uddannelse bliver opsplittet i en software ingeniør (der fokuserer på software), og en IT-Elektonik ingeniør (der fokuserer på samspillet mellem hardware og software). Der er også en uddannelse der fokuser på hardware.

Med andre ord en uddannelse der er rent top down, en der er rent bottom up og en der halvt af hvert.

Om denne fokusering er god eller dårlig må tiden vise - det afhænger helt af tilgangen til hvordan undervisningen skrues sammen - og afholdes.

Som jeg ser det så er det ikke så meget uddannelserne der er problemet - men derimod holdningen til:

  • At producere kode hvor man minimerer muligheden for for fejl - og gårsdagen viste at alle de (forhåbentligt) alment brugte teknikker - der har været kendt de sidste par årtier - stadigt virker.

  • At afprøvning og fejlfinding er to specialiserede områder - der (stadigt) skal tages yderst alvorligt.

Fejlfinding afhænger ikke så meget af hvilke værktøjer og teknikker der anvendes, men primært af:

  • hvilken tilgang den der skriver koden har til at uforudsete fejl er noget der opstår - og når de gør, så skal koden skrives på en måde der gør det "lettere" at lokalisere problemet - så man står med andet end bare en core dump, eller en meddelelse om at en "ukendt fejl er opstået".

  • hvilken tilgang den der fejlfinder har til at opgaven er en naturlig del af processen, der skal behandles professionelt og struktureret - også selv i de situationer hvor den der har skrevet koden ikke har gjort det med fejlfinding i tankerne.

  • 5
  • 0
Peter Stricker

Der har været kendt i de sidste fem årtier, men ignoreret de seneste to.


Tal for dig selv! Vi andre har altså hørt og læst om og anvendt Test Driven Development i stadig mere raffineret form i de to seneste årtier, hvor du åbenbart har været fraværende.

Det piner og provokerer mig, at en så stor kapacitet indenfor den danske IT verden, kan udtale sig så ignorant.

  • 0
  • 0
Poul-Henning Kamp Blogger

Tal for dig selv! Vi andre har altså hørt og læst om og anvendt Test Driven Development i stadig mere raffineret form i de to seneste årtier, hvor du åbenbart har været fraværende

Jeg har bestemt ikke været fraværende de to sidste årtier, det er netop derfor jeg kan udtale mig om det.

At du og enkelte andre laver et ordentligt stykke håndværk er godt og dejligt, men det forandrer jo ikke på at medianen ligger et helt andet sted.

  • 2
  • 0
Peter Stricker

Godt ord igen. Jeg har ikke forudsætninger for at udtale mig om medianen, men jeg er helt enig med dig i at højere kvalitet bør være en ambition indenfor ethvert fag.

Kommentaren fra Bo tyder nu også på at denne ambition er til stede på uddannelsesstederne. Så det er nok ikke kun der, man skal lede efter årsagerne til de lidt for mange IT-havarier.

  • 0
  • 0
Poul-Henning Kamp Blogger

Kommentaren fra Bo tyder nu også på at denne ambition er til stede på uddannelsesstederne. Så det er nok ikke kun der, man skal lede efter årsagerne til de lidt for mange IT-havarier.

Jeg har meget stor respekt for Bo og enhver anden der påtager sig uddannelse som erhverv og det jeg skrev ovenfor skal bestemt ikke læses som en kritik af Bo, men derimod en kritik af "køvenhavneriet".

Årsagerne til de mange IT-havarier har dog bestemt noget at gøre med uddannelse.

Taget i betragtning at vi formodentlig bruger flere penge på IT end på mursten nu om dage, kan man undre sig over en "arkitekt" med fuld overbygning kan tages som 5 ugers kursus hos Teknologisk Institut (http://www.teknologisk.dk/kurser/it-arkitekt/c535) hvis det handler er IT, men er en fuld masteruddannelse, hvis det er mursten. (http://www.ug.dk/uddannelser/kunstneriskeuddannelser/arkitekturkunstogde...)

  • 4
  • 0
Lars Skovlund

aget i betragtning at vi formodentlig bruger flere penge på IT end på mursten nu om dage, kan man undre sig over en "arkitekt" med fuld overbygning kan tages som 5 ugers kursus hos Teknologisk Institut


Det kan jeg nu godt svare dig på, PHK. Det skyldes de danske arbejdsløshedsregler, som giver den arbejdsløse mulighed for et såkaldt "selvvalgt kursus" af max 6 ugers varighed. Det er helt sikkert tanken, at dette kursus skal kunne passe under den ordning.

http://www.ug.dk/flereomraader/maalgrupper/efteruddannelse/6_ugers_selvv...

  • 0
  • 0
Jesper Louis Andersen

Tal for dig selv! Vi andre har altså hørt og læst om og anvendt Test Driven Development i stadig mere raffineret form i de to seneste årtier, hvor du åbenbart har været fraværende.

Handlede hele sagen i går ikke om Debugging i stedet for test? Jeg synes det er en fordel hvis man vælger at skille de to ting fra hinanden.

Jeg tror mestendels af PHKs kritik skal ses i kraft af hvad der skete i 90'erne. Et realistisk bud er at vi fik omkring 100 gange så mange mennesker der skrev IT-systemer som før. I dag er tallet nok tættere på 1000. Når antallet af udviklere stiger med 2-3 størrelsesordener, så medfører det naturligvis at de "gamle ræve" bliver glemt i virvaret.

Resultaterne findes I en masse virkeligt ringe skrevet software, hvor fokus har været på at lange et middelmådigt produkt over disken i stedet for at lave et produkt der virker.

Jeg tror heller ikke at kritikken skal ses som generel. Der findes masser af mennesker, der i de sidste to årtier har haft styr på den slags.

  • 1
  • 0
Lars Skovlund

Det er helt sikkert tanken, at dette kursus skal kunne passe under den ordning.


Og så måske alligevel ikke... der er et stramt prisloft på uddannelsesordningen (3648.32 kr./uge), og den samlede pris for kurserne hos Teknologisk Institut er ca. 113k. Men de regner måske med at folk betaler differencen selv...

http://ams.dk/da/Borgerservice/6%20ugers%20selvvalgt%20uddannelse.aspx

  • 0
  • 0
Carsten Larsen

Når Poul-Henning Kamp snakker om IT-Haveri, skal det nok ses i lyset af FreeBSD om få dage runder 30 år. På den måde er det jo også lidt at et mirakle, at der alene i Danmark kan udvikles systemer i tusindvis af mandetimer, uden de nogen sinde går i produktion. Hvis man samtidig følger lidt med i stillingsannoncer under kategorien Systemudvikling, vil man måske have noteret sig hvordan udviklings-principper skifter over tid. Bl.a. syntes run-time binding, i stil med inversion of control og dependency injection, er være blevet populært.

I et tanke eksperiment med IT-systemer der jævnligt skrifter leverandører og udviklerer, kombineret med en udprægede brug at run-time technologier, skal der ikke meget fantasi til for at forstille sig hvordan debugging bliver til en helt anden kunst / håndværk, end traditionel fejlretning-under-udvikling debugging.

Så med en stigende mængden af aldrende systemer, og skifter hænder til vedligeholdelse af samme, er behovet for at opretholde KISS princippet større end nogen sinde.

  • 1
  • 0
Fredrik Skeel Løkke

Jeg var ikke med til konferencen, så derfor er denne kommentar muligvis malplaceret. Hvis der med "defensiv kodning" menes eksempelvis null reference tjeks, så er det en stil der er med til at introducere kompleksitet i vores software. Brug hellere tiden på at specificere ansvaret imellem kompenenter (funktioner, klasser etc) vha software kontrakter. Dvs pre- og post-conditions, samt invarianter, vha. assertions. De er en fantastisk hjælp i debugging scenarier. En strukturet måde at gøre det på er metoden 'design by contract'.

  • 0
  • 0
Jesper S. Møller

Poul-Henning:

Jeg skal ikke gøre mig klog på om man faktisk kan debugger Java på anden vis, men IDE som fremtidens debugging-mirakel køber jeg ikke.

Jeg er helt klar over at min demo (om Java debugging i Eclipse) fremstod rodet, men du har åbenbart misset min indledende pointe: Debugging af programmer under kørslen er næstsidste udvej inden at skrive koden om, og at udvikling ikke skal ske i debuggeren. Så der er ikke tale om nogen mirakelkur, det synes jeg heller ikke nogen har lovet, eller forsøgt at sælge dig. Mit indlæg var tænkt som et konkret tutorial-agtigt indlæg om debugging i en data-sammenhæng.

Og vedrørende Tinglysning tror jeg du er kommet til at læse Rigsrevisionens rapport som fanden læser biblen: Det var usability tests, de først og fremmest klagede over manglen af. Nok var projektet forsinket, fik en brugergrænseflade, der ikke just henvender sig til menigmand, og var plaget af lav produktivitet i udrulningsfasen, men det er nyt for mig at det fra kvalificeret kilde er anklaget for decideret dårlig kodekvalitet eller lav testdækning.

P.S.: Jeg nåede kun kort at komme ind på fejlfinding af memoryleaks, men jeg kan ihvertfald love dig at Eclipse's heap-dump analysator tager en helt anden (langt mere effektiv) adgangsvinkel end WinDbg. Der findes sikkert også bedre værktøj til .NET...
Men: Generelt er det jo nogle helt andre situationer, man fejlsøger i managed, "sikre", sprog end i C/C++ programmer -- og da specielt i en kerne (men tak for indsigten anyways)

  • 4
  • 0
Peter Makholm

Så der er ikke tale om nogen mirakelkur, det synes jeg heller ikke nogen har lovet, eller forsøgt at sælge dig. Mit indlæg var tænkt som et konkret tutorial-agtigt indlæg om debugging i en data-sammenhæng.

Jeg havde skrevet en længere rant om live-demoer af IDE'er. Det bliver nok til et blog-indlæg senere.

Men jeg mener faktisk at jeg var blevet lovet, om ikke mirakler, så i det mindste noget smart. Dit foredrag hed "10 features du ikke kendte i Eclipse's Java-debugger" og lovede at se på "nogle mindre kendte hjørner af Eclipses debugger."

Men i hvert fald de første fem features var de fem absolut første ting jeg leder efter når jeg starter en debugger. Men jeg så netop frem til noget der var lidt mere advanceret, som jeg så kunne sammenholde til hvordan ville jeg gøre det uden et IDE.

  • 0
  • 0
Jesper S. Møller

Peter:

Jeg havde skrevet en længere rant om live-demoer af IDE'er. Det bliver nok til et blog-indlæg senere.

Det er faktisk lidt af en kunst at få noget så nemt til at se så svært ud ;-)
Jeg har helt sikkert lært et par praktiske punkter:
* Kend dit publikum (jeg troede at tilhørerne ville være langt grønnere end de viste sig at være)
* Undlad at skulle skifte imellem præsentation og IDE så tit som jeg forsøgte
* Brug mirrored display i stedet for at skulle kigge op på lærredet som så var i en grotesk vinkel ifht mig
* Undgå at stå helt forkert i forhold til publikum, de skulle vende sig rundt, jeg skulle have ryggen til jer.
Jeg var ret misundelig på dem som efterfølgende valgte at holde sig til scenen og vise forberedte skærmprint.

Men i hvert fald de første fem features var de fem absolut første ting jeg leder efter når jeg starter en debugger. Men jeg så netop frem til noget der var lidt mere advanceret, som jeg så kunne sammenholde til hvordan ville jeg gøre det uden et IDE.

Det beklager jeg! Der kom til at få for lang tid med de simple ting, så jeg måtte skøjte hen over det mere skjulte såsom at find objektinstanser ud fra klasse, at spore indgående referencer ("hvem peger på dette objekt"), tråd-filtrering og visning af monitorer (no pun intended). Og endnu værre, jeg nåede heller ikke ind i Memory Analyzer, som er guld værd til at analysere størrelsen af datastrukturer, til at finde leaks og diagnosticere heap dumps.
Måske jeg bare skulle holde mig fra live-demoer i fremtiden.

  • 2
  • 0
Peter Makholm

Det er faktisk lidt af en kunst at få noget så nemt til at se så svært ud ;-)

Du er ellers ikke alene om at få live-demoer til at se så besværlige ud.

Personligt havde jeg også lidt svært ved at skyde mig ind på målgruppen og hvilke emner jeg kunne forvente at andre af foredragsholderne havde dækket. Det er også helt klart at den fysiske opstilling var lidt en ulempe for nogle af os. For en gangs skyld havde jeg forberedt mig med et dual-screen setup så jeg kunne have overblikekt over min slides lokalt på skærmen, mens den viste en slide på projektoren. Men sådan blev det ikke.

Der er nogle yderligere ting jeg helt generelt oplever går galt ved live-demoer af IDE'er. For det første er det utydeligt hvad der sker på skærmen. Du øgende godt nok tekststørelsen, men kun for kodevinduet.

For det andet kan vi højst se hvad der sker og ikke hvad du rent faktisk gør. Så jeg er faktisk ikke blevet klogere på hvordan man sætter et breakpoint i Eclipse, kun at man kan og hvis jeg er heldig nåede jeg at opfange hvordan et breakpoint så ud.

Og endelig kan det være svært at gennemskue hvilken detalje på skærmen der tales om. Foredragsholderen siger et eller andet ala "så kan vi se her at der er en fejl på linje 14" og pludselig skifter hovedvinduet til at vise noget der sikkert godt kunne være linje 14. Jeg mangler lige detaljen at det vi ser på er vinduet i øverste venstre hjørne som indeholder et stack trace, at vi ser på den øverste linje og at vi ved at klikke med musen kan komme frem til det rigtige sted i koden.

Men det er faktisk endnu værre med foredragsholdere der forsøger at skrive kode af betydning i IDE'et. For med mindre man holder godt fast og er helt klar over foredragsholderens intention er det slet ikke til at følge med i selve koden for alt det flash af auto-completion popups og template som moderne IDE'er er udstyret med.

Som sagt er dette ikke en personlig kritik af dit specifikke foredrag, men en opsummering af hvad jeg ofte ser gå galt ved live-demoer ud over at systemer selvfølgelig aldrig vil som foredragsholderen.

  • 0
  • 0
Jesper S. Møller

Åhja, skærmstørrelsen overraskede mig faktisk også, normalt plejer der at være for få pixels, og linjerne skal være meget korte.

Men det er faktisk endnu værre med foredragsholdere der forsøger at skrive kode af betydning i IDE'et. For med mindre man holder godt fast og er helt klar over foredragsholderens intention er det slet ikke til at følge med i selve koden for alt det flash af auto-completion popups og template som moderne IDE'er er udstyret med.

Ja, det er rigtigt. Jeg forsøgte faktisk at holde mig fra at bruge for mange genvejstaster undervejs, for det gør det også svært at følge med.

Jeg tror jeg næste gang vil lægge mine æg i én kurv: Enten ren demo - men et projekt for hvert talepunkt, og de vigtigste pointer indlejret i kildeteksten, eller ren præsentation. Demoer er nu en gang bedre i et mindre (og dermed mere interaktivt) setup.

Tak for konstruktive indspark [og måske vi er lidt off-topic i forhold til professionalisering af branchen, beklager PHK]

  • 0
  • 0
Pelle Söderling

Nu var jeg ikke til foredraget, men personligt er jeg ret stor fan af WinDBG som hænges lidt ud her (og jeg bruger det både til native og til .NET _produktions_debugging) - det er dog et værktøj der tager tid at sætte sig ind i og lære, MEN det væsentlige her er at det er et tool der i meget høj grad er beregnet til debugging af produktionskode.

Altså når man har de her cases hvor noget går galt i et real-life scenarie ude på serveren med 10.000 brugere der alle foretager random ting man ikke er istand til umiddelbart at genskabe i sit testmiljø.

Det er altså et tool helt ude i allersidste led af debugging-kæden.

Jeg ved ikke hvor klart dette blev gjort, men hvis man bruger et sådant tool til at debugge fejl under udvikling - then you're doing it wrong.

  • 0
  • 0
Pelle Söderling

Generelt er dump-analyse af produktionssystemer temmelig nørdet - det er imo også tilfældet med GDB.

Forskellen ligger nok lidt i at GDB også bruges til mere general purpose debugging formål og den slags er væsentlig lettere at have med at gøre og outputtet væsentlig "nicere".

Til det formål anvendes der i Windows verdenen andre værktøjer, værd at nævne er nok IDE debuggeren i Visual Studio.

Kerneområdet for WinDBG er dump analyse helt ned på laveste niveau - det er toolet der kan det hele, men som tilgengæld også er temmelig nørdet i brug og kræver et vist kendskab til de basale kommandoer for at kunne bruges effektivt (samt forståelse for ens runtime miljø naturligvis!).

Men har du brug for at se assembler outputtet der afvikles af CLR'en når du loader et .NET library, eller har brug for at se om du har et heap corruption problem, har brug for at tjekke hvilke objekter der holder hvilke låse, se præcis hvilke objekter der ligger i hvilke generations i garbage collectoren etc. så er WinDBG toolet der kan give svar på det hele.

WinDBG er plugin baseret og det er nok også med at skabe lidt af forvirringen, eks. er .NET debugging et selvstændigt plugin der har sit eget kommando format der er lidt anderledes end instruktionssættet til native debugging.

  • 0
  • 0
Steffen Villadsen

Håber ikke tråde er helt dødt.
Først og fremmest var der mange gode oplæg og meget stof til eftertanke.

Debugging med IDE'er:
IDE skal bestemt ikke ses som en mirakel kur, men en lettere måde at komme i gang når man ikke kender GDBs syntax. Jeg repræsentere nok meget godt den tabte generation, der tildels var/er afhængig af et godt IDE.
I lang tid har jeg levet i Matlab og taget alle dets debug og benchmark værktøjer for givet. At skifte til C# gik ret glat, men det vil jeg nok give Visual Studio æren for. Skiftet fra C# til C++ gik egenligt også rimelig smerte frit ... i hvert fald på en windows platform med Visual Studio.

Ved skiftet til embbeded udvikling under Linux kom jeg lidt til kort. Lige pludselig var der ikke åbenlyst hvilket IDE der bruges.
Det tog faktisk lidt tid at finde et brugbart.
Efter at have prøvet 5-10 forskellige IDE under linux, fandt jeg Eclipse som værende det mest uoverskueligt og samtidigt det tungeste program at arbejde med.
Det var faktisk lidt betryggende at se/høre jeg ikke var den eneste der ikke er fan af dette IDE.
Jeg synes dog det er lidt urimeligt at generalisere det til at være et generelt problem for alle IDE'er.
Der findes bestemt IDE'er der kan gøre det lettere at debugge, men jo selvfølgelig er der situationer, hvor de ikke rækker og man må gå mere manuelt til værks.

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