Indhold
- Fejlfindingskode: Hvordan det er gjort
- Bekæmpende fejl
- Hvorfor fejl bugs undgå fangst
- Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
- Debuggingens filosofi
Kilde: Abscent84 / iStockphoto
Tag væk:
Tankevækkende ledere har drømt om en mere flydende softwareudgivelsesstruktur for at bygge bro over udviklings- og produktionsmiljøerne, men computerprogrammering har stadig et element af trolddom til det.
Enhver, der har arbejdet med kodning af selv de mest basale projekter, ved, at processen kræver en god smule tålmodighed. De mange faldgruber ved at prøve at skrive kode fra bunden er en sang og dans på alle de mange måder en menneskelig programmør eller udvikler kan misforstå. Det er en lang liste, og den indeholder alt fra syntaksfejl, som normalt vil blive fanget af kompilatoren, til dybere "vision-niveau" -fejl, der kræver mere intelligent gennemgang. Til dette formål lærer skoler og træningscentre computervidenskabelige studerende, hvordan man "debug" et program. Hvad der dog er interessant, er, at ethvert individ udvikler sit eget meget unikke svar på denne udfordring. Faktisk kan dette være et område, hvor mere end lidt personlig indsigt er påkrævet. (Læs om nogle af programmeringens vigtigste figurer i The Pioneerers of Computer Programming.)
Fejlfindingskode: Hvordan det er gjort
I nogle tilfælde er fagfolk inden for datalogi i stand til at bruge ressourcer fra udviklingsstudier eller programmeringsmiljøer til at isolere fejl i et program. Når disse slags fejlhåndtering eller systemer ikke er tilgængelige eller nyttige, kræver debugging imidlertid at gå gennem kode linje for linje. Mange programmeringsmiljøer, såsom Microsoft Visual Basic Studio, har funktioner, der tillader klar, visuel linje-for-linje "trin" gennem kode.
Trinering af kode hjælper på to hovedmåder: For det første kan programmerere se, hvad der sker, når computeren læser koden, og hvor fokuset går med hensyn til rekursive funktioner og andre kodeinteraktioner. For det andet kan programmereren imidlertid ofte se værdierne for forskellige variabler ved hjælp af mus-over-kommandoer eller andre dele af grænsefladen. At vide, hvilke værdier der er i variabler, er en vigtig måde at forstå, hvad computeren laver med den kode, den er givet.
Bekæmpende fejl
Processen beskrevet ovenfor lyder muligvis enkel, men den faktiske udfordring ved fejlsøgning kan være meget mere kompliceret. Et fremragende eksempel på denne proces på arbejdspladsen kan findes i den tech-thriller, der rammende hedder "The Bug" af Ellen Ullman, en tidligere udvikler og it-professionel, hvis prosa lyser på en litterær måde. Selvom bogen er fiktion, afslører den meget om, hvad der faktisk foregår, når programmerere og computere interagerer.
Ullmans skildring af to personer, en tester og en programmator, bortset fra en masse af den mørke personlige detalje i bogen, viser nogle af de største udfordringer, disse karriere teknologier stod overfor i den tidligere æra af softwareudvikling. Grundlæggende undgik hendes bug, som hun kalder "The Jester", alle på et softwarevirksomhed i 1980'erne, idet hun anstrengede medarbejderrelationer, kollapsede investorernes tillid og generelt forårsager en ulykke. I mellemtiden reflekterer forfatteren ganske lidt over, hvordan computere påvirker os, og hvorfor, hvis vi ønsker at sejre over deres idiosynkrasier, er vi nødt til at "tænke som en maskine." (For at lære om programmeringens historie skal du tjekke Computerprogrammering: Fra maskinsprog til kunstig intelligens.)
Hvorfor fejl bugs undgå fangst
En af grundene til, at fejlen i Ullmans bog var så svær at håndtere, er, at den kun dukkede op på ulige tidspunkter. Denne udfordring stemmer virkelig for mange andre sådanne fejl (husk bare Toyotas omfattende forsøg efter brugernes rygter om en løbsk Prius). Antag, at nogen fortæller dig, at du har en fejl. Medmindre du kan få computeren til at manifestere et problem, hvor starter du endda med hensyn til at løse den?
Årsagen til denne uklarhed, som afsløret i bogen, er et andet godt eksempel på kompleksiteten ved at skrive kode til den personlige computer i den æra - og måske stadig i vores. Grundlæggende var fejlen skjult i en lille indlejret funktion, der simpelthen gav en grundlæggende orientering til andre kodestykker. Fordi det blev skrevet af en tredjepartsprogrammør, og på grund af manglende kommunikation mellem programmerere, forblev den sande kilde til problemet skjult i måneder - et sandt bevis på problemerne kan opstå ved forkert dokumenteret teamwork.
Når det kommer til en computerfejl, kan en vanskelig detalje kaste et ellers ordnet system i kaos. Gode kodningsfærdigheder kan derfor undertiden være mere kunst end videnskab (Ullman kalder det "vanvid"), hvilket gør kodning til en iboende rodet forretning.
Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
Du kan ikke forbedre dine programmeringsevner, når ingen er interesseret i softwarekvalitet.
Debuggingens filosofi
Programmerere er ofte nødt til at arbejde med computere - ikke mennesker - for at opnå resultater. Ullman foreslår, at kodere og testere ofte er mest effektive, når de er i stand til at fjerne alle nuancerne i menneskelig tænkning og strip-resonnement ned til de grundlæggende logiske computere bruger. Det betyder, at man afsætter meget af det, vi alle sammen arbejder med hver dag for at få en klarhed i fokus. Det er denne kvalitet, der tillader mange top computervidenskabelige professionelle at trives, selv i en tidsalder, hvor der er indført meget mere af en ramme for de fleste projekter.
Tankevækkende ledere har drømt om en mere flydende softwareudgivelsesstruktur for at bygge bro over udviklings- og produktionsmiljøerne, men computerprogrammering har stadig et element af trolddom til det. Derfor er de bedste programmerere mere end bare strukturelle kodere; de har instinktet til at udrydde og rette de fejl, der truer funktionaliteten af de maskiner, som vi i stigende grad er afhængige af.