Har du ikke lært at debugge kode?
På de videregående uddannelser lærer man at udvikle kode (at programmere), men det har slået mig at kunsten at debugge kode lærer man ikke under uddannelse - det er da hul i hovedet. På en af mine t-shirts har jeg teksten "Half of programming is coding. The other 90% is debugging". Ikke helt skævt :)
Jeg har flere gange oplevet, at dygtige unge udviklere kommer til. De viser ofte, at de kan udvikle kode, men kun mindre kode-mængder som de selv står for. Til dagligt arbejder jeg med ca 1.500.000 linier kode, og det er lavet at mange personer og mange år. Jeg er ikke bleg for at hoppe ud i så meget kode, også selvom det til tider er meget komplekst.
Det jeg ikke forstår er hvorfor erfaring i at debugge og arbejde med meget store kodemænger ikke er en del at pensum på det videregående uddannelser. Umiddelbart er det mester-lære i dag - eller eget knofedt, der skal til. Jeg har prøvet at gennemsøge flere af de videregående uddannelsers kursus-databaser (DTU, ITU, Ålborg mv). Ingen steder fandt jeg kurser, hvor man for alvor kommer frem til at arbejde med store kodemængder - som andre har lavet det meste af. Det er skidt!
Jeg har under Open Source Days 2013 konferencen haft en glimrende dialog under og efter mit foredrag om samme emne. En af de ideer der kom frem var at give de studerende en relativt stor kodebase, som skal forstås og forbedres. Det finder jeg ingen steder i de kurser som pt. udbydes.
I sammme kontekst savner jeg uddannelsesmuligheder i
Brug af versionskontrolsystemer såsom Git og Mercurial.
Lære at lave program tests systematisk f.eks. med Jenkins eller lignende.
Lære at kunne debugge. Kunsten i at kunne reducere kode ned i størrelse indtil man ser fejl bør på skemaet. Banale ting som at kunne anvende en debugger eller kunne lave "print"-debugging bør alle lære kort efter at de lære at programmere.
erkende at kode ikke nødvendvis er sund, bare fordi den køre i et eller få tilfælde.
Jeg håber meget at I gode læsere vil forklare nedenfor at man sagtens kan lære at debugge og håndtere store kodemængder under studierne. Skriv meget gerne nedenfor om jeres egen overgang fra at lave små kodestumper til at lave store kodemænger i større udviklingsteams. Var I godt rustet til dette?
/pto
- emailE-mail
- linkKopier link
...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.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Hvornår/Hvor bliver video/slides tilgængelige?
Det er korrekt at der på DIKU er fokus på afprøvning i stort set alle de kurser, der involverer praktisk programmeringserfaring. Men afprøvning egne programmer er ikke det samme som fejlretning i almindelighed - der mangler stadig det, som Peter Toft efterspørger, nemlig erfaring med ændring af systemer der er så store, at man ikke har mulighed for at overskue dem som helhed.
Ovenfor nævnes Buenos, operativsystemet som de studerende skal videreudvikle på et af de obligatoriske bachelorkurser. Selvom Buenos er en større kodebase end det meste andet de studerende møder i løbet af deres uddannelse, så er den stadigvæk meget lille: Knapt mere end ti tusinde linjer C, så vidt jeg husker, og med et enkelt og let forståeligt design. Der findes et par kurser hvor de studerende skal gennemskue store, komplekse og skrøbelige projekter, men desværre er det i disse tilfælde ikke tilsigtet.
Peter,
I think you missed the courses that I teach. Readers have also commented on other courses that do explore these topics, but perhaps not as aggressively as you and I would like (e.g., the Advanced Software Engineering course at ITU or the basic Software Engineering course here at DTU).
See, e.g., my BSc course "Analysis, Design, and Software Architecture with Project" (e.g., https://blog.itu.dk/BDSA-E2011/) and my MSc course "Advanced Models and Programs" (course descriptions appended below).
A huge problem with the course listings and web pages at both DTU and ITU is that they are not public by default—a practice I've been fighting for years.
Some of us take these topics very seriously and we force students to dive into large-scale systems software engineering. My students learn tools and techniques used in companies that work in safety- and mission-critical systems but are equally applicable to "normal" software development.
Joe
Prof. Joseph Kiniry Head of Software Engineering Section, DTU
Name of course (English): Analysis, Design and Software Architecture
Intended learning outcome:
After completing the course and its project work students must:
- be able to describe and apply object-oriented methods for analysis and design,
- explain the principles of software architecture, including the variety of common architectures and design patterns and their use,
- understand and be able to execute all the primary facets of software development within software engineering including analysis, design, implementation, testing, validation, and verification,
- be able to use the common tools of the domain including configuration management, build systems, test frameworks, and version control,
- be able to document the analysis, design, and software architecture of large systems through the use of common standards for documentation including UML, BON, Javadoc, C#'s documentation tools, etc.,
- be able to continuously change (re-factor) a software system through adjustments in its architecture or refinements in its configuration,
- be able to construct useful, coherent, large-scale systems of up to approx. 10 KLOC in size in the C# programming language, including the ability to perform system and domain analysis for a given problem, propose an appropriate software architecture, write a system specification and its implementation, and validate the implementation against its specification.
The design and implementation of such an application may include the use of advanced OO constructs such as generics, callbacks, delegates, events, aliasing, etc., advanced data types and algorithms, the use of third-party APIs and frameworks, distributed systems constructs including sockets, streams, remote procedure calls, concurrency constructs such as threads, semaphores, monitors, messages, tasks, etc., graphical user interface toolkits, and databases.
Content:
- object-oriented analysis and design using a modeling language such as UML or BON
- software architectures and design patterns
- principles of software engineering
- the C# programming language and the .NET platform
- advanced programming in an OO language
Name of course (English): Advanced Models and Programs Intended learning outcome: The course has two major parts as detailed under course form below---a regular course followed by a project.
After the course, the students are expected to be able to:
- describe relevant concepts within the themes of the course,
- account for the practical applications of the covered constructs, and
- compare selected techniques and constructions within a single of the course themes.
On the basis of the project, the students are expected to be able to:
- apply relevant methods and techniques in the chosen project,
- argue for the overall design-decisions in, and correctness properties of, the project, and
- relate the project to the underlying theory.
Content: The subject of the course is programming language foundations and technologies, with special attention to advanced technologies that are likely to influence software practice over the next ten years.
The contents of the course is structured in four themes.
- Axiomatic Reasoning about Models and Programs
In particular, their pragmatic use in program design via model-driven development, implementation, logging, validation, and verification.
The material and structure for this part of the course will likely come from Benjamin Pierce's Software Foundations course using the Coq proof assistant.
- Foundations of Type Systems
In particular, their pragmatic use in model-based programming as evidenced in type-level annotations like those used in Java (JSR 308 and JSR 305), C# (like those supported by ReSharper, Code Contracts, and PEX), and Eiffel (via the Eiffel Information System, or EIS).
The material and structure for this part of the course will likely come from Luca Cardelli's notes and theTwelf system.
- Rigorous Software Engineering
In particular, the concepts, tools, and techniques used for analysis and design (BON and rigorous variants of UML, like those supported by Artisan Studio) in the Java (the Java Modeling Language, JML), C# (Code Contracts and PEX), and Eiffel programming languages and their environments (Eclipse, Visual Studio, and EiffelStudio).
- Design and Development of, and Reasoning about, Modern Concurrent Systems
In particular, the concepts, tools, and techniques used in Java (threads and java.util.concurrent), C# (threads and various .Net frameworks covered in the PPCP course from Microsoft Research and others), and Eiffel (threads and SCOOP).
I think you missed the courses that I teach. Readers have also commented on other courses that do explore these topics, but perhaps not as aggressively as you and I would like (e.g., the Advanced Software Engineering course at ITU or the basic Software Engineering course here at DTU).</p>
<p>See, e.g., my BSc course "Analysis, Design, and Software Architecture with Project" (e.g., <a href="https://blog.itu.dk/BDSA-E2011/">https://blog.itu.dk/BDSA-E2011/</a>) and my MSc course "Advanced Models and Programs" (course descriptions appended below).
Tak - det er selvfølgelig lidt svært at se hvor meget der er vægtet i dit fag, men jeg er super glad for at nogen tager det seriøst :)
Some of us take these topics very seriously [...]
Implying that some of you do not?
Der er ikke mange der er gode til at programmere når de kommer ud af universitetet eller lign. De har en del baggrund i algoritmer, men antallet af timer brugt foran skærmen er forsvindende lille ift. hvad de kommer til at bruge på første job og første år. Kodebaser af en væsentlig størrelse får man ikke ved at starte forfra på hvert semester, med et projekt man selv sætter kravene til. Hvis projektet var, at rette fejl og skabe en et antal nye features i et open source projekt af en hvis størrelse, så var der noget der lignede den situation nye udviklere bliver kastet ud i på deres første job. Det er dog mere ala' mesterlære end forskning, så det er måske lidt svært at retfærdiggøre det i en studieplan for en kandidat. Men man kunne evt. lave det som et ekstra semester, en slags overbygning.
Men man kan heller ikke både blæse og have mel i munden i 4 år. Det vil altid være en afvejning af hvor meget tid der skal bruges på hvert faglige område og på praksis vs. teori. Jeg husker tydeligt fra min studietid hvor der bl.a. blev diskuteret reform af uddannelsen og de studerendes fagråd havde selvfølgelig nogle debatter om hvad de kunne tænke sig ændret, der flere gange mundede ud i at man stod med en liste over ønskede kurser betydeligt længere end normeret studietid. ... man vil jo gerne lære det hele og prøve det i praksis samtidig.Meget enig...
Derfor er det nok også en god ide at der eksisterer forskellige uddannelser med forskellig vægt, så man vælge det der passer til ens mentalitet og folk kan ansætte folk af den type, der passer bedst til deres forretning. Ligefra de meget praktiske uddannelser til de tungt teoretiske og over de tværfaglige uddannelser.
Jeg tror ikke man kan løse det hele i samme uddannelse. Særlig ikke hvis man f.eks. vil undervise praktisk i både C# og Java. (som nævnt ovenfor) Derfor passer det mig sådan set også fint med den tilgang de fleste datalogiske institutter har haft at man lærte folk højst 1 programmeringssprog af hver type (funktionelt, proceduralt, OO, osv...) og så måtte de selv sætte sig ind i resten og de praktiske værktøjer selv. Min erfaring var at et generelt teoretisk kursus sprog og et mere praktisk i compiler-konstruktion satte folk i stand til meget hurtigt at kunne spotte principielle forskelle mellem 2 sprog og dermed lære nye sprog ret hurtigt.
Men det er da rigtigt at vi nok ville have haft god nytte af at der havde været udbudt et ikke merit-givende tilvalgsfag i f.eks. version-styring og måske debugging værktøjer, ligesom der var i alm. UNIX brug og andre basale værktøjer, men det må man jo så bare opfordre de forskellige uddannelsesinstitutioner til at gøre. Ellers kan de studerendes egne organisationer vel kaste sådan nogen sammen som aften-møder på ganske kort tid. Så tungt skulle en intro til Git, Mecurial, Valgrind eller gdb vel heller ikke være.
Kodebaser af en væsentlig størrelse får man ikke ved at starte forfra på hvert semester, med et projekt man selv sætter kravene til.
Men hvis nu man fra undervisernes side formåede at skabe sammenhæng kurserne imellem, f.eks. ved at genbruge nogle af de samme kodebaser/libraries, så ville de studerende netop have mulighed for at komme i dybden hen ad vejen.
Så ville de få styr både på teorien og på praksis.
Det forudsætter selvfølgelig, at ledelsen er i stand til at udstikke en kurs og at de ansatte færdes i en kultur, hvor tæt samarbejde er normen.
Hvor virker det overakademisk elfenbenstårnsagtigt at adskille teori og praksis. Er det ikke indlysende, at de praktiske eksempler ude fra virkeligheden er nødvendige for at retfærdiggøre læringen af de mere teoretiske aspekter?
Problemet er vel, at det faglige miljø på universtiteterne er afkoblet det, der egentlig er brug for ude i virkeligheden. Hvor mange af underviserne på universitetet er vant til at arbejde på en fælles, versionsstyret kodebase - og får kritik/feedback når de laver noget juks for de andre?
Og hvis man ikke er besiddelse af den helt grundlæggende erfaring med den slags fagligt og socialt udviklende fællesskaber, bør man da overhovedet vejlede i, hvordan man laver software?
Problemet er vel, at det faglige miljø på universtiteterne er afkoblet det, der egentlig er brug for ude i virkeligheden. Hvor mange af underviserne på universitetet er vant til at arbejde på en fælles, versionsstyret kodebase - og får kritik/feedback når de laver noget juks for de andre?</p>
<p>Og hvis man ikke er besiddelse af den helt grundlæggende erfaring med den slags fagligt og socialt udviklende fællesskaber, bør man da overhovedet vejlede i, hvordan man laver software?
Lige præcis derfor bør man ikke undervises i det på universitetet!!
Ja, jeg manglede den praktik, da jeg som Ph.D studerende i fysik skulle kode rigtigt meget og skulle styre en efterhånden store kodebase. Men på fysik, skulle vi jo netop også kun lære programmering som håndværk - og der manglede versionsstyring helt klart i værktøjskassen. Den slags hører helt klart med til de grundlæggende programmeringskurser for fysikere, kemikere, statistikere etc.
Jeg har siden fået undervisning i f.eks. revisionsstyring, håndtering af "store" kode baser, unit test mv. på et aftenkursus på datalogi og kunne umiddelbart bruge det på min arbejdsplads.
Men det jeg synes jeg har fået aller mest ud af er programmering i SML. Nej, jeg har ikke på mit arbejde ikke mødt funktionelle programmeringssprog, men jeg kan sagtens bruge noget af teorien i C++ kode.
Da jeg startede på DIKU, var test en del af første års pensum. Det var et godt grundlag for debugging. Jeg ved ikke, om det stadig er en del af pensum.
Til gengæld ville det dengang være utænkeligt at undervise i rene værktøjer som versionsstyring. Man underviste jo heller ikke i emacs eller LaTex. Den slags forventede man, at de studerende selv satte sig ind i. Personligt syntes jeg vældig godt om den holdning og var nærmest chokeret, da man senere lavede et HTML/LaTeX-kursus på DIKU.
Der kommer hele tiden nye værktøjer til. I vores branche er det en del af jobbet at holde sig opdateret med nye værktøjer. Det kan man lige så godt vænne sig til allerede under uddannelsen.
Hvad debugging angår, er jeg dog enig i at der bør undervises i det teoretiske grundlag for debugging, og måske endda best practises.
Men som andre har nævnt kan det være et problem at nå at sætte sig ind i store kodemængder på et 9 ugers kursus.
Hvad debugging angår, er jeg dog enig i at der bør undervises i det teoretiske grundlag for debugging, og måske endda best practises.
Nu afslører jeg måske et hul i min uddannelse, men sådan for det helt generelle begreb "debugging", hvad er så det teoretiske grundlag ud over den alm. videnskabelige metode med at opstille en hypotese, se hvilke forudsigelser den gør og udtænke en test for det?
Jeg kan sagtens se at der er noget grundliggende viden man bør kende for konkrete platforme. Som f.eks. hvordan tillader den her microcontroller at vi single-stepper og inspicerer registre. ... eller kan vi bruge MMU'en til at udløse page faults når der skrives uden for allokeret RAM. Jeg kan også se at man kan gøre det nemmere ved at designe sin kode, så man opstiller faste konventioner for dens state eller invarianter og kan slå passende asserts til, men stadig ... det er mere en pallette af teknikker end teori. Sådan for det helt generelle begreb "debugging", hvad er så det datalogiske grundlag? (Henvisninger til literatur?)
Jeg blev først uddannet fysiker og sidenhen tog jeg nogle kurser på datalogi her i Århus, mens jeg arbejdede som softwareudvikler.
De kurses jeg fik mest ud af var de mere teoretiske. Det praktiske lærte jeg jo på min arbejdsplads! Og før da med min hobby som Mud administrator og udvikler.
Jeg er stor modstander af, at man skal lære det praktiske på universiteterne. Man skal have et solidt teoretisk grundlag, som man så selv må kunne omsætte til praktik - også om 20 år når værktøjerne og sprogene er nogle helt andre end i dag. I min optik devaluere det blot en datalogi uddanelse, hvis man bruger krafter på praktik frem for teori. Teori er mere fremsynet end praktik, da det er værktøjs og teknologi neutralt. Praktik får man nok af, når man er færdig med uddanelsen!
Jeg siger ikke dette gælder alle uddanelser. Nogle er jo meget mere praktisk orienterede. Men så må man også finde sig i at uddanelsen kan være forældet om 10 år.
Jeg mener ikke det kan stilles så skarpt op - at være en god udvikler handler både om solid teoretisk fundering, men i lige så høj grad om praktisk erfaring og teknikker. Det kan godt være at du som håndværker kan mestre at slå et søm lige i en planke på en uges tid, men praktiske programmeringsteknikker kan sagtens tage 10 år at mestre (ja faktisk hele livet) og mange lærer aldrig 10% af disse fordi uddannelserne kun fokusere på det teoretiske og du selv må famle dig frem til det praktiske, præcis som alle andre før dig.
Det er for tåbeligt og ineffektivt. Jeg siger ikke mesterlære skal være alternativet, men jeg foretrækker reelt en der har været et par år i mesterlære fremfor en nyuddanned teoretiker og der kunne universiteterne nok godt lære en ting eller 2.
Det er for tåbeligt og ineffektivt. Jeg siger ikke mesterlære skal være alternativet, men jeg foretrækker reelt en der har været et par år i mesterlære fremfor en nyuddanned teoretiker og der kunne universiteterne nok godt lære en ting eller 2.
Lægerne har deres turnus ordning.
Som naturvidenskabeligt uddanede har vi jo næsten mesterlære i praksis: I starten får man meget lav løn indtil, man har vist, at man kan begå sig. Det der mangler, er en form for papir på man også kan kode i praksis - hvis det altså er det man vil efter 5 år på universitetet. Mange giver sig jo til at lave andre ting og holder selv fingrene fra koden.
Og igen: Virksomhederne har i længden brug for stærke akedemikere, som med en solid basis i teorien kan udføre et solidt stykke praktisk håndværk. Og blive ved med det, når teknikkerne har ændret sig. Vi har ikke brug for en ny generation af typografer med en 5 årig uddanelse.
Det er derimod tåbeligt og ineffektivt, at spilde tiden på en masse "praktiske" opgaver på skolebænken, som alligevel ikke svarer til de opgaver, man har i den virkelige verden. Lad da folk komme ud og lære det i den virkelige verden og samtigdig gør nytte. Virksomhederne skal blot være klar over, at en nyuddannet datalog ikke nødvendigvis kan tingene i praksis; men først skal lære det, og at det tager noget tid.
"Og blive ved med det, når teknikkerne har ændret sig."
Det er det grundlæggende argument der går igen når teori fremhæves over praksis - tilgengæld har jeg endnu aldrig oplevet en praktiker der havde problemer med at følge med udviklingen. Så fundamentalt har programmeringssprog altså heller ikke ændret sig de sidste 30-40+ år.
Så fundamentalt har programmeringssprog altså heller ikke ændret sig de sidste 30-40+ år.
Hvad med udviklingen fra procedural programmering til objekt orienteret? Og nu kan vi se, at funktionelle sprog også langt om længe er ved at vinde indpas i rigtige projekter uden for universiteternes mure. Og det er et noget større paradigme skift en skiftet til OO.
SmallTalk blev udviklet i 70'erne og udgivet til masserne i starten af 80'erne - C++ er ligeledes fra 80'erne og er stadig et af de mest anvendte sprog den dag idag. Det er vist ikke en overdrivelse at sige at skiftet til OOP-udvikling skete allerede i starten af 90'erne - det er altså min. 20+ år siden. Ikke ligefrem det jeg vil betegne som hurtig udvikling.
Funktionel programming har vundet indpas indenfor niche-områder, men jeg tror ikke funktionelle sprog kommer til at erstatte OOP-sprog til general-purpose udvikling. Istedet er trenden at OOP-sprogene tager flere og flere funktionelle koncepter til sig, men det er jo ikke ligefrem rocket-science at sætte sig ind i disse.
Udviklingen indenfor sprog går uhyre langtsomt - jeg startede med Turbo Pascal 5.5 tilbage i 94/95: http://goo.gl/AlxIXog selv om min editor er blevet lidt mere fancy siden, så er der altså ikke meget der har ændret sig. Det er stadig de samme grundlæggende programmerings-koncepter jeg anvender den dag idag - nu blot i sprog såsom Java og C#.
Hvis man ikke kan følge med til denne udvikling, så tror jeg man har fundet sig noget andet at lave længe inden man er endt som professionel udvikler.
Det er et stort problem at skolerne ikke underviser i debugging teknikker, men problemet er nok også at meget få ved hvordan man debugger effektivt og det kræver stor praktisk erfaring at have opnået den viden.
Selvfølgelig bør man vide hvordan man bruger en debugger, men det rækker kun så langt og det at kunne debugge effektivt handler langt mere om tankegang end om at kunne bruge værktøjer. Hvad for en uerfaren udvikler kan tage timer eller dage at debugge, kan for en erfaren udvikler der har lært visse debugging-teknikker tage 5-10 minutter - det er formentlig det mest interessante område man kan fokusere på hvis man som udvikler ønsker at kunne bruge sin tid mere effektivt.
Hvis man endelig lærer noget om debugging i undervisningen eller ved siden af, handler det desuden oftest kun om debugging i forbindelse med udvikling - jeg har oplevet udviklere med 10+ års erfaring som ikke anede hvordan man debuggede produktions-problemer. Hvis man udvikler til Windows betyder det reelt at man bør have et ret solidt kendskab til WinDbg. Har man ikke det, så mangler man noget helt essentiel erfaring der vel næsten svarer til at påstå at kunne kode C# uden at vide hvad OOP betyder. Alligevel er det de færreste der aner noget om produktions-debugging for det er viden og erfaring man pt. skal tilegne sig på egen hånd - det nævnes ikke engang med et ord på hovedparten af alle uddannelser (hvis nogen!).
Når man tager i betragtning hvor meget tid der spildes på debugging for de fleste udvikleres vedkommende, så er det en stor fejl at der ikke fokuseres mere på dette område - det batter ikke meget at være super god til at designe og implementere løsninger, hvis 80% af ens tid går med debugging.
Uanset om man har timer til det eller ej skal det da ind! Så må man gøre det en del af programmeringen!
Jeg er selv 16, og har programmeret i 2-3 års tid. Hvis jeg ikke havde lært det meste selv, og brugt debugging rigtig meget, så ville jeg ikke været nået så langt, af mig selv!
Der findes online kurser der kan sætte en på sporet af gode teknikker til debugging og test af software. Se f.eks. følgende to kurser på udacity.com
- Software debugging (https://www.udacity.com/course/cs259)
- Software testing (https://www.udacity.com/course/cs258)
DTU kursusbasen skal opdateres til den 30. april (for kurserne i efter), så det er på høje tid der kommer klager og forslag.
Jeg har selv tænkt mig mig at ændre i læringsmålene, så unittest (unittest, nose, py.test?) bliver skrevet eksplicit ind. Man kunne eventuelt også tvinge de studerende til at anvende et revisionsstyringssystem gennem læringsmålene.
For at det kan stå i læringsmålene bør det kunne testes. Unittest og revisionsstyring kan man teste fordi man kan bede de studerende om at aflevere testkoden og etv. coverage. Revisionen historik kan man vil også aflevere og derigennem se at revision er brugt.
Det er uklart for mig hvordan man vil teste debugningsfærdigheder. Skal man udleverer et større program med fejl i, der så skal findes?
for kurserne i efteråretfor kurserne i efter)
AT designe algoritmer/databaser/hjemmesider/styresystemer/smarte kommandolinie programmer/brugerflader og meget mere - det er kunst (mere eller mindre). At få skidtet implementeret det er håndværk, punkt 1: man skal have fortalt hvordan man skal gøre af en "mester". Punkt 2: man skal selv gøre det og få sine egne erfaringer. For den der har flair for sagen er det sådan at jo mere man øver sig des bedre bliver man (fuldstændig som f.eks. en møbelsnedker), og en dag kan man måske selv kalde sig mester.
Derfor en " skole"s opgave er at lære folk om værktøjet og dets brug, men det kræves af eleven at hun øver sig.
Den rigtigt gode er så kunstneren der behersker håndværket.
Jeg vil sige at vi støtte på en stor kodebase under "styresystemer og multiprogrammering" på diku. Her kiggede vi på Buenos, som er et MIPS styresystem. men med begrænsningen på 9 uger til et kursus gør også, at det vil være svært at sætte sig ind i store komplekse systemer. Og jeg er enig med Jakub Nielsen i, at fokus er teori og praksis kommer gennem øvelsesopgaver og træning gennem årene på studiet.
Jeg er 10. Semester software ingeniør studerende på Aalborg universitet, og vil gerne give dig ret, decideret undervisning i debugging og de andre ting du nævner er noget man ikke finder i nogen af vores kurser. Men vi har dog arbejdet med de fleste igennem vores projekter, så jeg vil mene at hvis man kommer ud fra hvad jeg anser som Danmarks bedste universitet et man bedre rustet end mange andre er det. Men når det er sagt skal det selvfølgeligt også siges at det jo så er meget mere op til de enkeltes egen disciplin at tage sig sammen til at lære de forskellige ting da man jo kan komme gennem de fleste semesterprojekter uden.
I min erfaring er det oftest mangel på struktur, der gør fejlfinding besværlig mere end om der er 1.000, eller 100.000+ linjer. Hvis koden er ok velstruktureret (og skrevet) kan man normalt rimelig hurtigt zomme ind på det eller de få moduler, hvor problemet er.
Det er ikke meningen, at universiteter eller datamatiker uddannelsen skal undervise i alle mulige scenarier, som man vil opleve når man kommer ud i det virkelige liv. De skal sikre, at personerne har evnerne til at forstå den viden som man har oparbejdet med konkrete situationer, samt at være med til at videre udvikle den.
Enhver person som har lært at udvikle på de nævnte anstalter, har også lært at debugge sig igennem et multi-trådet program hvilket skulle gøre dig tør bag ørene. Der er sikkert en masse tips, vaner mv. som gør sig gældende når vi snakker >1m linjer kode (og 1000 andre specialiteter ala' selvmodificerende programmer), hvis man ikke efterfølgende kan lære det så er det tilbage til skolebænken.
Jeg går på datamatiker uddannelsen Erhvervs Akademi Aarhus (lidt endnu). Vi har godt nok ikke haft et disideret fag/kursus der hedder debugging. Men vi har fået undervisning i at bruge JUint og hvordan man bruger debugging tools i Eclipse og Visual Studio og hvordan man lave strukturet debugging.
Desuden er jeg helt enig i at der skal mere fokus på debugging og test - Sjovt nok har de PBA Software Development studerende et helt kursus i Test, som jeg har hørt skulle være virkelig godt skruet sammen.
Desuden er jeg helt enig i at der skal mere fokus på debugging og test
Hvad skal i givet fald fjernes? Jeg har for så vidt ikke noget imod at øge den generelle arbejdsbelastning, men det har mange studerende nok.
Jeg tror ikke problemet er debugging som sådan - det lærer man nok af sig selv, da de programmer skal skrive i forbindelse med ens uddannelse næppe alle vil være fejlfrie fra starten. Problemer er snarere at overskue systemer, der grundet deres størrelse ikke lader sig overskue som helhed. Dét kunne godt trænge til fokus - evt. med et (valgfrit?) kursus baseret på at skulle brydes med et eller andet bæst af et system på en million linjer kode.
System arkitektur og design er helt klart en vigtigt faktor. Men for eksempel så er vi blevet undervist i C# og JAVA. Hvor jeg mener JAVA ville havde været nok. Der er forskelle i sprogene men den diversitet der er, er ikke stor nok til at skulle undervises i begge, så det kunne man skære væk.
Jeg vil også mene at udgangspunktet er forkert. Det er ikke universiteterne's ansvar at sørge for man lære at debugge og arbejde med store mængde kode. Jeg mener at det er en selv der skal søge denne viden, og jeg ved fra mit eget studie at dette er muligt. F. eks. er jeg en del af et Formula Student team. Hvor vi arbejder med et avanceret netværk, (Ethernet Powerlink) bestående af 6 noder, i en racerbil. Der er tale om store mængder C kode, samt VHDL skrevet af tidligere studerende der har arbejdet på projektet og vi bruger SVN til versionkontrol. Udover dette samarbejder vi med maskin ingeniører og andet godt folk, hvilket gør det mere sammenligenligt med den virkelige verden.
Jeg vil dog ikke afvise at det kunne være godt med et kursus i at debugge. Men er det virkelig nødvendigt? Vil folk ikke blot tilegne sig disse færdigheder når de får brug for dem, ligesom jeg selv har gjort det?
Virker første gang?
Altid. Og hvis ikke, så dropper jeg hele projektet.
For så har man aldrig brug for at afluse.
Hvis debugging skal ind i pensum, hvad skal så ud?
Det er for billigt et argument :-D
Ind skal det...
Det er for billigt et argument :-D</p>
<p>Ind skal det...
Det er ikke sport billigt. Der er tusind ting, man gerne vil have ind i pensum på uddannelserne, men kun begrænset plads.
Jeg har flere gange været med til at revidere studieordninger, og det er i reglen meget nemt at finde ud af hvad nyt, der skal ind i pensummet. Men det er en kamp uden lige, hvis man vil fjerne bare en lille smule af det eksisterende pensum eller blot gøre det valgfrit i stedet for obligatorisk. Det har "vundet hævd", og de folk, der har det som forskningsområde, nedlægger veto mod, at det nedprioriteres.
@Peter Toft
... hvilket så er samme holdning underviserne har, hvorfor der er fuld overbelægning (hvad angår indhold og arbejdsbyrde) på alle kurser. Der er flere kurser der tangere det dobbelte af hvad et 7,5 ects kursus berettiger.
Jeg kan udmærket godt se, at en del af de punkter du efterlyses ikke udbydes på DTU, hvor jeg selv studerer i øjeblikket, men lidt af det har man dog:02161 Software Engineering 1 bruger et automatisk testframework (JUNit) som gennemgående element i hele kurset.02165 Development of Software Products har jeg ikke haft endnu, men jeg tror, at det bl.a. dækker nogle værktøjer til større kodemængder og evt. lærer om håndtering af dette.
Udover disse to eksempler, tror jeg ikke der findes andet, så det var måske noget de skulle tage fat på derude!
De fleste af de kurser jeg har haft har altid været med kedeligt små mængder kode hvor 10000 linier er max. Og ingen debugging overhovedet som et decideret læringsmål. Der var nogen af de gamle kurser, jeg tog tilbage i 2001 hvor det var naturligt at man skulle debugge som en del af undervisningen. Der var endda kursusmateriale der omhandlede remote-debugging. De kurser blev dræbt et par år senere, og kodebasen var vel en 5000 linier oder so.
Effektiv debugging er dog temmelig systemspecifikt og også ahængig af programmeringssprog og hvilke værktøjer man har til rådighed. Og test er afhængig af en afvejning om hvor korrekt programmet skal være kontra den tid det tager at teste. Jeg er selv ret stor tilhænger af property-based-testing (QuickCheck) - men det er ikke alle problemstillinger hvor det vægtes vigtigt nok at køre den kanon i stilling. Hvilket er synd, for det ville nok give hurtigere udvikling med færre fejl.