Extreme Programming ( Extreme Programming , XP ) är en av de agila metoderna för mjukvaruutveckling . Författarna till metodiken är Kent Beck , Ward Cunningham , Martin Fowler m.fl.
Namnet på metodiken kommer från idén att tillämpa användbara traditionella metoder och metoder för mjukvaruutveckling, vilket tar dem till en ny "extrem" nivå. Så, till exempel, praxis att utföra kodrevision , som består i att en programmerare kontrollerar koden som skrivits av en annan programmerare, i den "extrema" versionen är "parprogrammering", när en programmerare skriver kod, och hans partner vid samtidigt granskar kontinuerligt precis vilken kod som skrivits.
Metodiken utvecklades av Kent Beck under hans arbete med Chrysler Comprehensive Compensation System (C3) löneprojekt . Beck blev ledande projektspecialist i mars 1996. Han började förbättra utvecklingsmetodik som användes i projektet och skrev en bok om det, Extreme Programming Explained (publicerad i oktober 1999). [1] Projektet avslutades i februari 2000.
De tolv grundläggande extremprogrammeringsteknikerna (enligt den första utgåvan av Extreme programmering förklaras ) kan grupperas i fyra grupper:
XP innebär att man skriver automatiserade tester (kod skriven specifikt för att testa logiken i annan kod). Särskild uppmärksamhet ägnas åt två typer av tester:
En utvecklare kan inte vara säker på att koden han skriver är korrekt förrän absolut alla enhetstester av systemet han utvecklar fungerar. Enhetstest (enhetstester) låter utvecklare se till att var och en av dem fungerar korrekt. De hjälper också andra utvecklare att förstå varför en viss bit kod behövs och hur den fungerar - under studietiden av testkoden blir logiken i koden som testas tydlig, eftersom det är tydligt hur den ska användas. Enhetstester gör det också möjligt för utvecklaren att refaktorera utan rädsla .
Funktionstester är utformade för att testa funktionen hos logiken som bildas av samverkan mellan flera (ofta ganska imponerande storlek) delar. De är mindre detaljerade än enhetstester, men de täcker mycket mer – det vill säga tester som, när de körs, påverkar en större mängd kod, har uppenbarligen större chans att upptäcka eventuellt felaktigt beteende. Av denna anledning, i industriell programmering, har skrivning av funktionella test ofta företräde framför skrivning av enhetstester.
För XP är ett tillvägagångssätt som kallas TDD (från engelskan testdriven development - development through testing ) högre prioritet. I enlighet med detta tillvägagångssätt skrivs först ett test som först misslyckas (eftersom logiken som det ska kontrollera helt enkelt inte existerar ännu), sedan implementeras den logik som krävs för att testet ska klara. TDD, på sätt och vis, låter dig skriva kod som är mer bekväm att använda - för när du skriver ett test, när det inte finns någon logik ännu, är det lättast att ta hand om bekvämligheten med det framtida systemet.
Huvudmålet med planeringsspelet är att snabbt forma en grov arbetsplan och hela tiden uppdatera den i takt med att förutsättningarna för uppgiften blir tydligare. Artefakterna i planeringsspelet är en uppsättning papperskort som innehåller kundens önskemål (kundhistorier) och en grov arbetsplan för utgivningen av nästa en eller flera små versioner av produkten. Den kritiska faktorn som gör denna planeringsstil effektiv är att i det här fallet är kunden ansvarig för att fatta affärsbeslut och utvecklingsteamet ansvarar för att fatta tekniska beslut. Om denna regel inte följs faller hela processen isär.
"Kunden" i XP är inte den som betalar räkningarna, utan slutanvändaren av mjukvaruprodukten. XP hävdar att kunden måste vara i kontakt hela tiden och tillgänglig för frågor.
Parprogrammering förutsätter att all kod skapas av par av programmerare som arbetar på samma dator. En av dem arbetar direkt med programmets text, den andra tittar på sitt arbete och följer helhetsbilden av vad som händer. Om det behövs överförs tangentbordet fritt från en till en annan. När du arbetar med ett projekt är paren inte fixade: det rekommenderas att blanda ihop dem så att varje programmerare i teamet har en bra uppfattning om hela systemet. Således förbättrar parprogrammering interaktionen inom teamet.
Om du integrerar systemet under utveckling tillräckligt ofta kan du undvika de flesta problem som är förknippade med det. I traditionella metoder utförs integration som regel i slutet av arbetet med produkten, när det anses att alla komponenter i systemet som utvecklas är helt klara. I XP utförs kodintegrering av hela systemet flera gånger om dagen, efter att utvecklarna har sett till att alla enhetstester fungerar korrekt.
Refaktorering är en teknik för att förbättra kod utan att ändra dess funktionalitet. XP innebär att när koden väl har skrivits kommer den nästan säkert att göras om många gånger under ett projekts gång. XP-utvecklarna omarbetar hänsynslöst tidigare skriven kod för att förbättra den. Denna process kallas refactoring. Bristen på testtäckning provocerar avvisandet av refactoring på grund av rädslan för att bryta systemet, vilket leder till en gradvis försämring av koden.
Versioner (releaser) av produkten bör gå i produktion så ofta som möjligt. Arbetet med varje version bör ta så kort tid som möjligt. Samtidigt bör varje version vara tillräckligt meningsfull när det gäller användbarhet för företag.
Ju tidigare den första fungerande versionen av produkten släpps, desto tidigare börjar kunden få ytterligare vinst på grund av det. Kom ihåg att pengar som tjänas idag är värda mer än pengar som tjänas i morgon. Ju tidigare kunden börjar använda produkten, desto snabbare får utvecklarna information från honom om vad som uppfyller kundens krav. Denna information kan vara till stor hjälp när du planerar din nästa utgåva.
XP utgår från det faktum att under arbetets gång kan förutsättningarna för problemet ändras upprepade gånger, vilket gör att produkten som utvecklas inte ska vara helt och fullständig i förväg utformad. Att försöka designa systemet i detalj redan i början av arbetet är ett slöseri med tid. XP föreslår att design är en så viktig process att den måste göras kontinuerligt under hela projektets livslängd. Design bör utföras i små steg, med hänsyn till ständigt föränderliga krav. Vid varje tidpunkt bör du försöka använda den enklaste designen som passar det aktuella problemet, och ändra det när förutsättningarna för problemet förändras.
Kent Beck och Martin Fowler [2] föreslår att "enkel design" ska beskrivas som uppfyllandet av följande fyra kriterier:
Robert Martin håller med [3] med dessa regler, men i sitt tidigare arbete [4] föreslår han också att beskriva "enkel design" med följande tre principer:
Arkitektur är en representation av komponenterna i ett system och deras relationer till varandra. Utvecklare måste analysera mjukvaruarkitekturen för att förstå var i systemet de behöver lägga till ny funktionalitet och vad den nya komponenten kommer att interagera med.
Systemmetaforen är analog med vad de flesta tekniker kallar arkitektur. Systemmetaforen ger teamet en uppfattning om hur systemet för närvarande fungerar, var nya komponenter läggs till och vilken form de ska ha.
Att välja en bra metafor gör det lättare för utvecklingsteamet att förstå hur systemet fungerar. Ibland är detta inte lätt att göra.
Vid det här laget har Bob Martin erkänt att systemmetaforen är föråldrad och bör ersättas av Domain Driven Design .
Alla gruppmedlemmar under arbetets gång måste uppfylla kraven i vanliga kodningsstandarder. Därigenom:
Om teamet inte använder enhetliga kodningsstandarder blir det svårare för utvecklare att refaktorera; när man byter partner i par finns det fler svårigheter; i allmänhet är projektets framsteg svår. Inom ramen för XP är det nödvändigt att göra det svårt att förstå vem som är författaren till den eller den biten kod - hela teamet arbetar på ett enhetligt sätt, som en person. Teamet måste bilda en uppsättning regler, och sedan måste varje gruppmedlem följa dessa regler när de skriver kod. Listan över regler bör inte vara uttömmande eller alltför omfattande. Uppgiften är att formulera allmänna riktlinjer som gör koden begriplig för var och en av teammedlemmarna. Kodningsstandarden bör vara enkel till en början, sedan kan den gradvis bli mer komplex i takt med att utvecklingsteamet får erfarenhet. Det finns ingen anledning att lägga för mycket tid på att förbereda en standard.
Kollektivt ägande innebär att varje gruppmedlem är ansvarig för all källkod . Således har alla rätt att göra ändringar i vilken del av programmet som helst. Parprogrammering stöder denna praxis: genom att arbeta i olika par blir alla programmerare bekanta med alla delar av systemets kod. En viktig fördel med kollektivt kodägande är att det påskyndar utvecklingsprocessen, eftersom när en bugg inträffar kan vilken programmerare som helst fixa det.
Varje programmerares rätt att ändra kod löper risken att buggar introduceras av programmerare som tror att de vet vad de gör men som inte överväger vissa beroenden. Extrema programmerare tror att väldefinierade enhetstester löser detta problem: om ogranskade beroenden genererar buggar, kommer nästa körning av enhetstester att misslyckas och avslöja problemet.
| Mjukvaruutveckling | |
|---|---|
| Bearbeta | |
Koncept på hög nivå | |
| Vägbeskrivning |
|
| Utvecklingsmetoder _ | |
| Modeller |
|
| Anmärkningsvärda siffror |
|