Innehåll
- Felsökningskod: Hur den är klar
- Stridande buggar
- Varför buggar undviker fångst
- Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
- Debuggingens filosofi
Källa: Abscent84 / iStockphoto
Hämtmat:
Tankeväckande ledare har drömt upp en mer flytande mjukvarufrigörande struktur för att överbrygga utvecklings- och produktionsmiljöerna, men datorprogrammering har fortfarande ett element av trolldom.
Alla som har arbetat med kodning även de mest grundläggande projekten vet att processen kräver lite tålamod. De många fallgroparna med att försöka skriva kod från grunden är en låt och dans på alla de många sätt som en mänsklig programmerare eller utvecklare kan göra fel. Det är en lång lista, och den innehåller allt från syntaxfel, som vanligtvis kommer att fastna av kompilatorn, till djupare "vision-level" -fel som kräver mer intelligent granskning. I detta syfte lär skolor och utbildningscentrum datorstudenter hur man "felsöker" ett program. Det intressanta är dock att varje individ utvecklar sitt eget mycket unika svar på denna utmaning. I själva verket kan detta vara ett område där mer än lite personlig insikt krävs. (Läs om några av programmets viktigaste figurer i The Pioneers of Computer Programming.)
Felsökningskod: Hur den är klar
I vissa fall kan datavetenskapspersonal använda resurser från utvecklingsstudior eller programmeringsmiljöer för att isolera buggar i ett program. När dessa typer av felhantering eller system inte är tillgängliga eller användbara, kräver dock felsökning gå igenom kod rad för rad. Många programmeringsmiljöer, till exempel Microsoft Visual Basic Studio, har funktioner som möjliggör tydlig, visuell linje-för-rad "steg" genom kod.
Att gå igenom koden hjälper på två huvudsakliga sätt: för det första kan programmerare se vad som händer när datorn läser koden, och vart fokuset går när det gäller rekursiva funktioner och andra kodinteraktioner. För det andra kan programmeraren ofta se värdena på olika variabler genom att använda mus-över-kommandon eller andra delar av gränssnittet. Att veta vilka värden som finns i variabler är ett viktigt sätt att förstå vad datorn gör med koden som den ges.
Stridande buggar
Processen som beskrivs ovan kan låta enkel, men den faktiska utmaningen med felsökning kan vara mycket mer komplicerad. Ett utmärkt exempel på denna process på jobbet kan hittas i den tekniska thrilleren med titeln "The Bug" av Ellen Ullman, en tidigare utvecklare och IT-professionell vars prosa lyser på ett litterärt sätt. Även om boken är fiktion, avslöjar den mycket om vad som faktiskt händer när programmerare och datorer interagerar.
Ullmans porträtt av två personer, en testare och en programmerare, visar några av de mörka personliga detaljerna i boken, och visar några av de stora utmaningarna som dessa karriärtekniker mötte under den tidigare eran av mjukvaruutveckling. I grund och botten undanröjde hennes bugg, som hon kallar "The Jester", alla på ett mjukvaruföretag på 1980-talet, anstränger anställdas relationer, kollapsade investerarnas förtroende och generellt orsakade en skurk. Samtidigt reflekterar författaren ganska mycket på hur datorer påverkar oss, och varför, om vi vill segra över deras idiosynkrasier, måste vi "tänka som en maskin." (För att lära dig mer om programmeringshistoriken, kolla in datorprogrammering: från maskinspråk till artificiell intelligens.)
Varför buggar undviker fångst
En anledning till att felet i Ullmans bok var så svårt att hantera är att det bara dök upp vid udda tillfällen. Den här utmaningen ringer verkligen för många andra sådana problem (kom bara ihåg Toyotas omfattande prövningar efter rykten om användarna om en språng Prius). Anta att någon säger att du har ett fel. Om du inte kan göra datorn manifest ett problem, var börjar du till och med att fixa den?
Anledningen till denna glitchiness, som avslöjades i slutet av boken, är ett annat bra exempel på komplexiteten i att skriva kod för persondatorn i den eran - och kanske fortfarande i vår. I huvudsak döljdes felet i en liten kapslad funktion som helt enkelt gav en grundorientering till andra kodstycken. Eftersom det skrevs av en tredje parts programmerare och på grund av brist på kommunikation mellan programmerare förblev den verkliga källan till problemet dold i månader - ett verkligt bevis på problemen kan uppstå från felaktigt dokumenterat teamarbete.
När det gäller ett datorfel kan en knepig detalj kasta ett annat ordnat system i kaos. Bra kodningskunskaper kan därför ibland vara mer konst än vetenskap (Ullman kallar det "galenskap"), vilket gör kodning till ett iboende rörigt företag.
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
Debuggingens filosofi
Programmerare måste ofta arbeta med datorer - inte människor - för att uppnå resultat. Ullman föreslår att kodare och testare ofta är mest effektiva när de kan undanröja alla nyanser av mänsklig tanke och remsa resonemang till bas logik datorer använder. Detta innebär att avsätta mycket av det vi alla arbetar med varje dag för att få en tydlighet i fokus. Det är denna kvalitet som gör att många proffs inom datavetenskapen kan frodas, även i en tid då mycket mer ramverk har införts för de flesta projekt.
Tankeväckande ledare har drömt upp en mer flytande mjukvarufrigörande struktur för att överbrygga utvecklings- och produktionsmiljöerna, men datorprogrammering har fortfarande ett element av trolldom. Det är därför de bästa programmerarna är mer än bara strukturella kodare; de har instinktet att rota ut och fixa buggarna som hotar funktionaliteten hos de maskiner som vi i allt högre grad förlitar oss på.