Dagliga byggen är din vän

From The Joel on Software Translation Project

Revision as of 13:59, 30 January 2006 by Davidhall (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Denna artikel är ännu inte färdigöversatt, tills dess rekommenderas originalartikeln 'Daily Builds Are Your Friend' om du inte vill hjälpa med översättningen och språkgranskningen. This article is a translation in progress and has yet to be copy-edited.

Återstår:

  1. översätta färdigt
  2. införa länkar och formatering
  3. ta bort originaltexten
  4. språkgranska (detta kan du göra!)


Dagliga byggen är din vän

Av Joel Spolsky
Översatt av David Hall, ...
Bearbetat av (ingen)
lördag 27 januari 2001

IBM PC med skrivare

1982 tog min familj emot leveransen av den allra första IBM-PC:n i Israel. Vi for faktiskt till lagret och väntade medan PC:n levererades från hamnen. På något sätt hade jag övertygat min pappa att välja den fullutrustade versionen med två diskettstationer, 128 KiB internminne och både en matrisskrivare och en Brother skönsskriftsskrivare som lät precis som en kulspruta fast högre. Jag tror vi fick nästan alla tillbehör som fanns: PC-DOS 1.0, den tekniska referenshandboken för 75 dollar med en fullständig listning av källkoden i BIOS, makroassembler och den förbluffande IBM Monochrome-skärmen med hela 80 teckens bredd och ... gemena bokstäver! Allt som allt kostade det runt 10 000 dollar inklusive Israels då befängda importtull. Extravagant!

Alla "visste" att BASIC var ett programspråk för barn som kräver att man skriver spagettikod och som förvandlar din hjärna till Camembertost. Så vi pungade ut 600 dollar för IBM Pascal, som kom på tre disketter. Kompilatorns första pass låg på första disketten, andra passet på den andra disketten och länkaren på den tredje disketten. Jag skrev ett enkelt "hello, world"-program och kompilerade. Det tog 8 minuter.

Hmm, det är ganska länge. Jag skrev en batchfil för att automatisera processen och lyckades få ner det till sju och en halv minut. Bättre, men när jag försökte skriva långa program, som min förbluffande version av Othello som alltid lyckades slå mig, ägnades den mesta tiden åt att vänta medan programmet kompilerades. "Japp", berättade en professionell programmerare för mig, "vi brukade ha en situpbräda i kontoret och göra situps under kompileringen. Efter några månader av programmerande hade jag snygga magmuskler."

En dag dök ett fräckt program som hette Compas Pascal upp från Danmark. Philippe Kahn hade köpt och bytt namn på det till Borland Turbo Pascal. Turbo Pascal var nästan chockerande eftersom det gjorde i stort sett allt som IBM Pascal men enbart tog upp 33 KiB minne inklusive textredigeraren. Detta var inget annat än häpnadsväckande. Än mer häpnadsväckande var det faktum att man kunde kompilera ett litet program på under en sekund. Det är som om ett företag du aldrig hört talats om presenterade en klon av Volvo 240 som kunde göra 1 500 000 kilometer i timmen och färdas jorden runt på så lite bensin att en myra skulle kunna dricka det utan att bli illamående.

Plötsligt blev jag mycket mer produktiv.

Det var när jag fick reda på begreppet REP-loop. REP står för "read, eval, print" (ungefär: läs, evaluera och skriv ut) och det beskriver vad en lisp-interpretator gör: den "läser" din indata, evaluerar det och skriver ut resultatet. Ett exempel på en REP-loop visas nedan: jag skriver något, lisp-interpretatorn läser det, evaluerar och skriver ut resultatet.

REP i emacs

Om man tittar i ett större perspektiv är du i en makroversion av REP-loopen när du skriver kod. Denna makroversion kallas redigera-kompilera-testa (eng. Edit-Compile-Test-loop). Du redigerar din kod, kompilerar den, testar den och ser hur bra den fungerar.

En viktig sak att komma ihåg är att du måste gå igenom loopen gång på gång för att skriva ett program. Följaktligen blir du mer produktiv ju snabbare redigera-kompilera-test-loopen är, till en naturlig gräns av omedelbara kompileringar. Det är den formella, datalogiska orsaken till att programmerare vill ha riktigt snabb hårdvara och kompilatorutvecklare gör vad som helst för att få riktigt snabba redigera-kompilera-test-loopar. Visual Basic gör det genom att parsa och lexa varje rad varefter du skriver det, så att den slutliga kompileringen blir jättesnabb. Visual C++ gör det genom att erbjuda stegvisa kompileringar, förkompilerade headerfiler och stegvis länkning.

Men så snart du börjar arbeta i en större grupp med flera utvecklare och testare stöter du på samma loop igen, fast än större (det är en fraktal!). En testare hittar en bugg i koden och rapporterar. Programmeraren åtgärdar buggen. Hur lång tid tar det innan testaren får den åtgärdade versionen av koden? I vissa organisationer kan denna rapportera-fixa-återtesta-loop ta några veckor, vilket innebär att organisationen i sin helhet inte är så produktiv. För att få hela utvecklingsprocessen att löpa på behöver du fokusera på att få rapportera-fixa-återtesta-loop snävare.

Ett bra sätt att åstadkomma detta är med dagliga byggen. Ett dagligt bygge är ett automatiskt, dagligt, fullständigt bygge av hela källkodsträdet.

Automatiskt - eftersom du sätter koden att kompileras vid en bestämd tidpunkt varje dag med hjälp av cron-jobb (på Unix) eller med schemaläggningshanteraren (i Windows).

Dagligt- eller ännu oftare. Det är frestande att göra fortlöpande byggen men det kan du antagligen inte på grund av problem med källkodshantering som jag tar upp strax.

Fullständigt - det är inte helt omöjligt att din kod har flera versioner. Flera språkversioner, flera operativsystem eller en avancerad/enkel variant av programmet. Det dagliga bygget behöver bygga alla vesioner och varje gång från början utan att lita på kompilatorns bristfälliga funktioner för stegvis kompilering och länkning.

Några av fördelarna med dagliga byggen är:

  1. När en bugg är åtgärdad får testarna en ny version snabbt och kan testa igen för att se om buggen verkligen är åtgärdad.
  2. Utvecklare kan känna sig mer säkra på att en ändring de gjort inte kommer att sabba någon av de 1024 versionerna av det aktuella systemet, även om de inte har en dator med OS/2 på skrivbordet att testa på.
  3. Utvecklare som checkar in deras ändringar strax före det schemalagda dagliga byggen vet att de inte kommer att sabba för alla andra genom att checka in något som "förstör bygget" -- alltså något som gör att kompileringen inte går igenom för någon. Detta är motsvarigheten till blåskärm (Blue Screen of Death) för en hel programmeringsgrupp och inträffar ofta när en programmerare glömmer att lägga till filen de just skapat till det centrala systemet som hanterar all källkod. Bygget går fint på deras maskin men om någon annan checkar ut får de länkningsfel och kan inte köra programmet.
  4. Andra grupper, som marknadsföringsavdelningen, beta-testande kunder och liknande, som behöver en icke-färdig produkt kan hämta ett bygge som de vet är någorlunda stabilt och använda det ett tag.
  5. Genom att ha ett arkiv med alla dagliga byggen kan man, när man upptäcker en ny, riktigt skum, bugg som man inte vet varifrån den kommer, använda intervallhalvering på arkivet för att bestämma exakt när buggen först uppstod. Kombinerat med bra källkodshantering kan man antagligen bestämma exakt vilken incheckning som orsakade problemet.
  6. När en testare rapporterar ett problem som programmeraren tror är åtgärdat kan testaren säga vilket bygge som problemet inträffat i. När programmeraren sedan tittar på när han checkat in fixen kan han avgöra om det verkligen är åtgärdat.

Så här gör du: Du behöver en server för dagliga byggen, som antagligen är den snabbaste dator som du kan få tag på. Skriv ett skript som checkar ut en komplett kopia av det nuvarande källkodsträdet (du använder väl källkodshantering?) och som sedan bygger varje version av koden du skeppar, från grunden. Om du har ett installationsprogram, bygg det också. Allt som du levererar till kunderna bör byggas av den dagliga byggprocessen. Lägg varje bygge i sin egen katalog, kodad efter datum. Kör ditt skript på en bestämd tidpunkt varje dag.

  • Det är avgörande att allt som krävs för ett slutligt bygge genomförs av det dagliga byggskriptet, från att checka ut koden till att sätta rättigheterna på webbserverkatalogen där allmänheten kan ladda ner (även om det under utvecklingsfasen, förstås, rör sig om en testserver.) Detta är det enda sättet att verkligen säkerställa att inget i byggprocessen bara finns "dokumenterat" i en persons huvud. Då kommer du aldrig i positionen där du inte kan släppa en ny produkt eftersom bara Shaniqua vet hur man skapar installationsprogrammet och hon blev överkörd av en buss. När jag jobbade på Juno, det enda du behövde veta för att skapa ett fullständigt bygge var att känna till var byggservern fanns och hur man dubbelklickade på ikonen för "Dagligt bygge".
  • Inget är värre för din mentala hälsa än när du försöker skeppa koden och den har en enda liten bugg som du fixar direkt på byggservern för att strax därefter skeppa iväg koden. Som en gyllene regeln bör du bara skeppa kod som är produkten av ett fullständigt, dagligt bygge från grunden som startats från en fullständig utcheckning av koden.
  • Sätt kompilatorerna på högsta varningsläget (-W4 i Microsofts värld, -Wall i gcc-land) och ställ in dem att stanna även på den minsta varning.
  • Om ditt dagliga bygge är trasigt riskerar du att stanna hela din grupp. Upphör med allting annat och fortsätt bygga om tills att det är fixat. För vissa dagar kommer du att ha flera dagliga byggen.
  • Ditt skript för dagliga byggen bör rapportera om fel, via e-post, till hela programmeringsgruppen. Det är inte särskilt svårt att söka i loggarna för "fel" och "varning" (köra grep på "error" eller "warning") och bifoga i e-postmeddelandet. Skriptet kan också lägga till statusrapporter till en webbsida så att programmerarna och testarna snabbt kan avgöra om byggena gick igenom utan fel.
  • En regel vi följde i Microsoft Excel-gruppen, med bra resultat, var att vem som hade sönder bygget blev ansvarig för att vakta byggen tills någon annan hade sönder det. Utöver att tjäna till en piska att ge fungerande byggen ledde det till en arbetsrotation så att nästan alla fick uppdraget som byggmästare och därmed insikt hur byggen genomförs.
  • Om din grupp arbetar i en tidszon är lunchen en bra tidpunkt att genomföra byggena. På det sättet checkar alla in sin senaste kod strax före lunch, bygget körs medan de äter och när de kommer tillbaka finns alla tillgängliga för att fixa eventuella fel. Så fort som bygget fungerar kan alla checka ut sin senaste version utan att vara rädd för att sabba på grund av ett trasigt bygge.
  • Om din grupp arbetar i två tidszoner så schemalägger du det dagliga bygget så att de i en ena tidszonen inte sabbar för dem i den andra. På Juno checkade folket i New York in koden 19.00 lokal tid och gick hem. Om bygget gick fel skulle den indiska gruppen, som kom till jobbet runt 20.00 New York-tid, sitta fast under en hel dag. Vi löste det problemet genom att börja med två dagliga byggen, en timme före respektive grupp gick hem.

Ytterligare läsning:


Originalartikeln på engelska heter Daily Builds Are Your Friend

Personal tools