mboost-dp1
Hvordan sætter i jer ind i andres kode?
Dette spørgsmål er til dem som har erfaring i at arbejde professionelt med softwareudvikling:
Hvordan griber i det an, når i skal sætte jer ind i andre folks kode?
Jeg oplever ofte at skulle hjælpe andre eller overtage andres opgaver og har i den forbindelse behov for at sætte mig ind i det kode de har skrevet.
Koden er som oftest enten helt uden dokumentation eller kommentarer eller med kommentarer som ikke er brugbare for andre end ham som skrev dem i sin tid.
Det hjælper som regel hvis ham som har skrevet koden er tilgængelig til at forklare hvad han har lavet, men hvis jeg er blevet bedt om at overtage hans kode så er han i de fleste tilfælde enten ikke længere ansat eller har så travlt at han ikke har tid til at bruge tid på at forklare hvad den gør.
Min approach til at sætte mig ind i andres kode har indtil videre været at køre det i en debugger, for at se hvad den gør, og så skrive kommentarer på alt den kode jeg kommer igennem, hvilket gør det lettere at overskue.
Det er dog en enormt tidskrævende process, så jeg er interesseret i at vide om der findes bedre metoder til at løse opgaven.
Lad mig høre hvad jeres erfaringer er?
Hvordan griber i det an, når i skal sætte jer ind i andre folks kode?
Jeg oplever ofte at skulle hjælpe andre eller overtage andres opgaver og har i den forbindelse behov for at sætte mig ind i det kode de har skrevet.
Koden er som oftest enten helt uden dokumentation eller kommentarer eller med kommentarer som ikke er brugbare for andre end ham som skrev dem i sin tid.
Det hjælper som regel hvis ham som har skrevet koden er tilgængelig til at forklare hvad han har lavet, men hvis jeg er blevet bedt om at overtage hans kode så er han i de fleste tilfælde enten ikke længere ansat eller har så travlt at han ikke har tid til at bruge tid på at forklare hvad den gør.
Min approach til at sætte mig ind i andres kode har indtil videre været at køre det i en debugger, for at se hvad den gør, og så skrive kommentarer på alt den kode jeg kommer igennem, hvilket gør det lettere at overskue.
Det er dog en enormt tidskrævende process, så jeg er interesseret i at vide om der findes bedre metoder til at løse opgaven.
Lad mig høre hvad jeres erfaringer er?
Hvis jeg kender personen der har lavet det, så spørger ikke ind til selve koden.
Jeg vil normalt have at vide hvad programmet skal kunne gøre, og hvordan den hovedligsageligt gør det.
Detefter burde(!!) de forskellige klasser og metoder give mening.
Det tager dog lang tid før man har et overblik, meget lang tid. Så man skal måske overveje kun at kigge på en bestemt del af et system, hvis det kan lade sig gøre. Især hvis det kun er noget skal ændre en lille smule i.
Men det er svært at sige noget der altid gælder...
Jeg vil normalt have at vide hvad programmet skal kunne gøre, og hvordan den hovedligsageligt gør det.
Detefter burde(!!) de forskellige klasser og metoder give mening.
Det tager dog lang tid før man har et overblik, meget lang tid. Så man skal måske overveje kun at kigge på en bestemt del af et system, hvis det kan lade sig gøre. Især hvis det kun er noget skal ændre en lille smule i.
Men det er svært at sige noget der altid gælder...
Mort (1) skrev:Jeg oplever ofte at skulle hjælpe andre eller overtage andres opgaver og har i den forbindelse behov for at sætte mig ind i det kode de har skrevet.
Du er ikke den eneste. Jeg gætter på at langt over halvdelen af alle software udviklings timer bruges på dette.
http://mindprod.com/jgloss/unmain.html er desværre ikke helt en joke.
Mort (1) skrev:Koden er som oftest enten helt uden dokumentation eller kommentarer eller med kommentarer som ikke er brugbare for andre end ham som skrev dem i sin tid.
Her siger man så et eller meget andet grimt.
Reelt er der tale om et ufærdigt software produkt.
Mort (1) skrev:Hvordan griber i det an, når i skal sætte jer ind i andre folks kode?
I den perfekte verden:
1) læs krav specifikation
2) læs arkitektur dokument
3) læs design dokument
4) læs udvalgt kode og kommentarer
I situationen uden dokumentation er der ikke meget at gøre. Man er nødt til at læse kode.
Jeg er så gammeldags at jeg foretrække at læse print.
Og man bør naturligvis skrive dokumentation som en del af processen således at den næste som skal kigge på koden er bedre stillet end en selv.
Og kommentarer er kun en del af dokumentationen.
Mort (1) skrev:Min approach til at sætte mig ind i andres kode har indtil videre været at køre det i en debugger, for at se hvad den gør, og så skrive kommentarer på alt den kode jeg kommer igennem, hvilket gør det lettere at overskue.
Det er ikke særligt praktisk hvis det er et komplekst system.
apkat (4) skrev:Hvorfor?
Fordi det at arbejde professionelt med software betyder at man ofte har at gøre med software af en hvis størrelse og ikke blot et program med 5-10 klasser.
Jeg har også skrevet meget software, mens jeg studerede (Og før jeg studerede IT). Der har været stor forskel på den kode jeg arbejdede med som studerende og den kode jeg har arbejdet med professionelt.
Som studerende var kode som regel 3rd party libraries, hvilket plejer at være veldokumenterede, open source, hvilket som regel er veldokumenteret, eller samples, som er små.
Professionelt er det ikke unormalt at arbejde med projekter som indeholder 100-300 klasser, hvoraf nogen af klasserne har en størrelse på et par tusind liniers kode.
Derudover er der ofte mange som har arbejdet på samme kode og ikke alle har haft samme idéer til hvad koden skulle gøre eller hvordan.
arne_v (3) skrev:Det er ikke særligt praktisk hvis det er et komplekst system.
Nej, det er netop derfor jeg gerne vil vide hvilket erfaringer andre har, i samme tilfælde :)
Jeg er enig i at dokumentation er nødvendig før kode er færdig. Desvørre oplever jeg sjældent at en sådan eksisterer og når den gør så er den ofte af en kvalitet som gør den ubrugelig, da den kræver at man har forstået koden, for at kunne læse dokumentationen.
Mort (5) skrev:Fordi det at arbejde professionelt med software betyder at man ofte har at gøre med software af en hvis størrelse og ikke blot et program med 5-10 klasser.
Man kan godt være studerende og arbejde med store klasser i store projekter, men undskyld hvis jeg forstyrrer i din tråd.
Mort (6) skrev:Nej, det er netop derfor jeg gerne vil vide hvilket erfaringer andre har, i samme tilfælde
Jeg tror ikke at der er nogen genveje.
Læse læse læse.
Print.
En IDE som kan finde definitioner af noget.
Et godt søge værktøj.
Kode analyse værktøj - fra simpel UML import til noget mere avanceret.
apkat (7) skrev:Man kan godt være studerende og arbejde med store klasser i store projekter,
Givet normal studietid kan det ikke lade sig gøre for en gruppe at smide flere hundrede mandår i et projekt.
Og jeg har aldrig hørt om en gruppe studerende som arbejde videre på en anden gruppes projekt.
Så et stort projekt vil vel typisk komme udefra.
Man har sparet nogle penge ved at springe over hvor gærdet var lavest i første omgang. Nu skal de penge betales tilbage med renter. Jeg håber der er sat penge af til at lave dokumentation af i denne omgang, så man ikke skal betale udgiften igen næste gang en person skal arbejde med koden.Mort (1) skrev:Koden er som oftest enten helt uden dokumentation eller kommentarer eller med kommentarer som ikke er brugbare for andre end ham som skrev dem i sin tid.
Der er også et navn for det fænomen. Jeg kan ikke huske hvad det kaldes.
Fuldstændigt enig. Det er også der jeg ville starte. Hvis ikke man allerede ved hvad formål koden tjener, så find nogen, som ved det. Systemet må have nogle brugere. Hvis ingen ved hvad koden burde gøre, så er det fordi ingen bruger den, og i så fald er der ikke ret meget grund til at arbejde på den.m910q (2) skrev:Jeg vil normalt have at vide hvad programmet skal kunne gøre, og hvordan den hovedligsageligt gør det.
Personligt har jeg ikke stået med behovet for at sætte mig ind i fuldstændigt udokumenteret kode. Jeg har haft det privilegie at arbejde et sted hvor der blev lagt vægt på at lave koden ordentligt i første omgang.
At koden er lavet ordentligt i første omgang betyder ikke at der aldrig er behov for at ændre den, men det betyder f.eks. at der er relevante kommentarer. Man skal ikke indsætte kommentarer bare for kommentarernes skyld. Man skal indsætte kommentarer for at sætte læseren ind i den kontekst koden skal ses i, og for at forklare brudstykker af kode, som ikke er åbenlyse uden kommentarerne.
Et af redskaberne til at sikre at dette blev gjort ordentligt var kodereviews. Alt skulle læses og godkendes af en anden person end den som havde skrevet koden. Først når det var gjort kunne koden checkes ind.
Blot det faktum at man ved at den kode man skriver vil blive læst af en anden person er medvirkende til at man er lidt mere omhyggelig med at gøre den pæn og veldokumenteret. Derudover resulterer reviews ofte i at fejl bliver opdaget og koden bliver forsynet med relevante kommentarer. Og endeligt er der efter reviewet ikke kun en, men to personer som kender koden.
Det er godt at vide hvordan man kan sikrer at koden skrives ordentligt i første omgang, men den viden forhindrer ikke at man en dag kan komme til at stå overfor andres knap så gode kode.
arne_v (9) skrev:Eller 1000-3000
Jeg har heldigvis aldrig været ude for at en enkelt projektfil indeholdte så mange klasser.
Hvis vi snakkede om hele produktets kodebase, med alle solutions inkluderet, ville det let være i tusindvis af klasser, men så mange projekter har jeg heldigvis ikke været nødt til at overtage.
grep, kaffe og et IDE man er fortrolig med (Genveje som CTRL-klik på klasse og funktions navne i netbeans f.eks er uundværlige...)
sidder og arbejder med en custom java businesscore, og der er ca. 4200 klasser, stikket sammen med spring.Mort (14) skrev:Jeg har heldigvis aldrig været ude for at en enkelt projektfil indeholdte så mange klasser.
Det jeg så som den letteste metode, er at finde et kald, og debugge det igennem, så blyant og papir og tegne kaldsmønster/designpattern op.
Når det er gjort tager man lige et par kald mere, for at se de følger ca. samme mønster, og så har jeg en god overordnet forståelse, der gør at jeg kan klare resten med Call Hierarki views o.l.
Mort (14) skrev:Jeg har heldigvis aldrig været ude for at en enkelt projektfil indeholdte så mange klasser.
Hvis vi snakkede om hele produktets kodebase, med alle solutions inkluderet, ville det let være i tusindvis af klasser, men så mange projekter har jeg heldigvis ikke været nødt til at overtage.
Der bør ikke være så mange klasser i et enkelt projekt.
Men det er ret almindeligt at problemer involverer flere projekter.
Kig i den tilhørende testsuite (hvis den findes) og prøv og debug igennem de enkelte test, de skulle gerne have en afgrænset funktionalitet der gør at man kan gennemskue de vigtigste funktioner hurtigt.
Er der ingen testsuite - så er det ok for en voksen mand at græde.
Er der ingen testsuite - så er det ok for en voksen mand at græde.
http://www.mahdiyusuf.com/post/32154944661/reading...
har en ide: læs koden i samme rækkefølge som den er skrevet.
har en ide: læs koden i samme rækkefølge som den er skrevet.
Det forslag efterlader dog også ubesvarede spørgsmål. Skal man gå hele revisionshistorien igennem? Hvis man gør det, så kommer man til at læse en hel del mere kode, end hvis man kun læser den nyeste version.arne_v (22) skrev:læs koden i samme rækkefølge som den er skrevet.
Det skader selvfølgelig ikke at læse lidt mere, hvis det betyder at det man læser er nemmere at forstå. Og hvis man går tilbage til den allerførste version i versionsstyringen, så er den forhåbentlig overskuelig. Hvis man læser den allerførste version er der en god chance for, at man fuldstændigt kan gennemskue arkitekturen af det man læser.
Der er en god chance for at den første version afslører et princip i arkitekturen, som stadigvæk er til stede, men er svært at få øje på i den nyeste version. Hvis det princip ikke er beskrevet i dokumentation, så vil det med tiden være blevet sværere og sværere at få øje på. Hvis man har været med gennem hele udviklingen kender man princippet og ved hvilke linjer af koden man skal læse for at se det.
Men at læse gennem samtlige opdateringer af koden fra første til seneste version kan være lige så uoverkommeligt som at læse hele den nyeste version fra ende til anden.
Det vigtigste er at man kan udnytte det man læser til at afgøre, hvilke dele af koden som er vigtigst for den opgave man står overfor. Måske er det relevant at læse revisionshistorien for en enkelt fil eller en enkelt funktion.
Hvis man sætter sig ned med den nyeste version af en fil og får markeret hver enkelt linje med oplysninger om hvilken version den er tilføjet i, så giver de versionsnumre ikke ret meget ekstra forståelse. Men de kan i nogle tilfælde være nødvendige for at vide, hvilke opdateringer, der er vigtige.
#23
Ideen er vel at starte med den første simple version og så gå gennem revisionerne og skippe dem som man ikke mener er vigtige for forståelsen af ens problem.
Jeg er ikke sikker på at ideen er gennem testet, men interessant ide.
Ideen falder naturligvis helt til jorden hvis der heller ikke bruges source control eller man har mistet history i forbindelse med et skifts a source control software.
Ideen er vel at starte med den første simple version og så gå gennem revisionerne og skippe dem som man ikke mener er vigtige for forståelsen af ens problem.
Jeg er ikke sikker på at ideen er gennem testet, men interessant ide.
Ideen falder naturligvis helt til jorden hvis der heller ikke bruges source control eller man har mistet history i forbindelse med et skifts a source control software.
Jeg er enig i at idéen er interessant. Dog tror jeg ikke at det er en strategi som kan føres ud i praksis, alene pga den store mængde kode som man er nødt til at gennemlæse, uden at miste fokus.
Det svarer lidt til at prøve at læse hele koden fra den ene ende til den anden og så derefter kunne regne ud hvordan alting i koden virker.
Hvis koden blev committed een metode ad gangen, ville det måske være muligt at følge den approach, men oftest bliver der committed store mængder kode ad gangen, hvilket betyder at man skal læse alt den committede kode, for alle de commits der er lavet i projektets historie.
Det svarer lidt til at prøve at læse hele koden fra den ene ende til den anden og så derefter kunne regne ud hvordan alting i koden virker.
Hvis koden blev committed een metode ad gangen, ville det måske være muligt at følge den approach, men oftest bliver der committed store mængder kode ad gangen, hvilket betyder at man skal læse alt den committede kode, for alle de commits der er lavet i projektets historie.
Jeg havde en gang en forelæser som var hooked på at læse kode i en form for state-sekvens. Han lavede diff på revisionerne og kiggede derefter efter tilføjelse af entiteter beskrevet i designdokumentet. Hver tilføjelse af en entitet (f.eks implementering af et pattern) kaldte han en state.
Ved at læse fra state til state, mente han at man bedre fik en forståelse for den tidl. programmørs tanker bag implenteringen, og derfor gav koden ofte mere mening, fordi han mente at kunne forudsige næste skridt (han var rigtig nørd, så det var mest spændende når den næste state ikke stemte overens med hans egen fremgangsmåde).
Det har jeg tidligere brugt med succes i mindre projekter jeg har overtaget, og jeg synes det virker rigtig fint.
Ved at læse fra state til state, mente han at man bedre fik en forståelse for den tidl. programmørs tanker bag implenteringen, og derfor gav koden ofte mere mening, fordi han mente at kunne forudsige næste skridt (han var rigtig nørd, så det var mest spændende når den næste state ikke stemte overens med hans egen fremgangsmåde).
Det har jeg tidligere brugt med succes i mindre projekter jeg har overtaget, og jeg synes det virker rigtig fint.
Gå til top
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
- ⟨
- Programmering
Gå til bund