Utvecklingspraxis development-practices

Arbeta enligt definitionen Klar work-according-to-a-definition-of-done

Varje team har en egen definition av vad"gjort" innebär, men det är viktigt att ha en sådan och se till att en berättelse uppfyller de definierade kriterierna innan den godkänns.

Några kriterier som vanligtvis anges av team är:

Utan en väldefinierad DoD är det lätt att hamna i en situation där mycket av saker är halvvägs och inget är helt färdigt.

Definiera och följ kodnings- och formateringskonventioner define-and-adhere-to-coding-and-formatting-conventions

Det kanske inte verkar viktigt med indragsnivåer och tomt utrymme, men att ha rätt formaterad kod går långt i fråga om läsbarhet och underhåll. Konventioner bör diskuteras och godkännas som ett team och sedan följas i koden.

Syfte med hög testtäckning aim-for-high-test-coverage

När en projektimplementering växer i storlek ökar också den tid som krävs för att testa den. Utan god testtäckning kommer testteamet inte att kunna skalas om och utvecklarna kommer till slut att begravas i buggar.

Utvecklarna bör öva på TDD och skriva underkända enhetstester före den produktionskod som uppfyller deras krav. Kvalitetssäkring bör skapa en automatiserad uppsättning godkännandetester för att säkerställa att systemet fungerar som väntat på en hög nivå.

Det finns anpassade ramverk, till exempel Jackalope och Prosper, som gör det enklare för utvecklare att maska av JCR-API:er när de skriver enhetstester.

Håll dig redo för demo stay-demo-ready

Systemet bör vara tillgängligt för demonstration till företaget i slutet av varje upprepning. Genom att hålla systemet i ett demo-färdigt tillstånd kommer teamet alltid att vara i ett skick där det är produktionsfärdigt och tekniska skulder kan hållas på en stabil nivå.

Implementera en kontinuerlig integreringsmiljö och använd den implement-a-continuous-integration-environment-and-use-it

Genom att implementera en kontinuerlig integreringsmiljö kan du enkelt och repeterbart köra enhetstester och integrationstester. Det kommer också att frigöra driftsättningar från utvecklingsteamet, vilket gör att andra delar av teamet kan bli mer effektiva och göra driftsättningen mer stabil och förutsägbar.

Håll utvecklingscykeln snabb genom att hålla byggtiderna låga keep-the-development-cycle-fast-by-keeping-build-times-low

Om enhetstester tar lång tid att köra undviker utvecklarna att köra dem och de förlorar sitt värde. Om det tar lång tid att skapa koden och distribuera den gör man det mindre ofta. Att prioritera korta byggtider säkerställer att den tid vi har investerat i vår testtäckning och CI-infrastruktur kommer att fortsätta göra teamet mer produktivt.

Finjustera Sonar och andra verktyg för statisk kodanalys och agera utifrån deras rapporter fine-tune-sonar-and-other-static-code-analysis-tools-and-act-on-their-reports

Verktyg för kodanalys kan vara värdefulla, men bara om deras rapporter leder till åtgärder från utvecklingsteamets sida. Utan att finjustera den analys som dessa verktyg ger blir rekommendationerna som de genererar inte relevanta och de förlorar sitt värde.

Följ Pojkens Scout-regel follow-the-boy-scout-rule

Pojkens Scout har en regel: "Låt det vara bättre än du hittade det." Så länge alla medlemmar i utvecklingsteamet följer den här regeln och lagar något när de stöter på en enda röra, kommer koden hela tiden att förbättras.

Undvik att implementera YAGNI-funktioner avoid-implementing-yagni-features

YAGNI-funktioner (eller Du kommer inte att behöva dem) är saker som implementeras när vi förväntar oss att vi kommer att behöva något i framtiden, även om vi inte behöver det nu. Vi bör implementera det enklaste som kommer att fungera idag och använda kontinuerlig omfaktorisering för att säkerställa att systemarkitekturen utvecklas med de krav som ställs över tid. Detta gör att vi kan fokusera på det som är viktigt och förhindra att koden blottar och krypar funktioner.