Ontwikkelingspraktijken

Werken volgens een definitie van Gereed

Elk team heeft een andere definitie van wat "gedaan"betekent, maar het is belangrijk om te hebben en ervoor te zorgen dat een verhaal aan de bepaalde criteria alvorens wordt goedgekeurd voldoet.

Sommige criteria die algemeen door teams worden gespecificeerd omvatten:

Zonder een welomschreven DoD is het gemakkelijk om in een situatie te belanden waarin veel dingen halverwege worden gedaan en niets echt compleet is.

Coderings- en opmaakconventies definiëren en naleven

Dingen als inspringingsniveaus en witruimte lijken misschien niet belangrijk, maar als de code juist is opgemaakt, gaat het veel verder in de richting van leesbaarheid en onderhoudsgemak. Conventies moeten als team worden besproken en overeengekomen en vervolgens in de code worden gevolgd.

Doel van hoge testdekking

Naarmate een projectimplementatie groter wordt, zal ook de tijd die nodig is om deze te testen, toenemen. Zonder goede testdekking, zal het testteam niet kunnen schrapen en de ontwikkelaars zullen uiteindelijk begraven in insecten worden.

Ontwikkelaars zouden TDD moeten gebruiken en ontbrekende eenheidstests vóór de productiecode schrijven die aan hun vereisten zal voldoen. QA zou een geautomatiseerde reeks goedkeuringstests moeten tot stand brengen om ervoor te zorgen dat het systeem zoals verwacht van een hoog niveau werkt.

Er zijn aangepaste frameworks beschikbaar, zoals Jackalope en Prosper, om het kopiëren van JCR API's eenvoudiger te maken om de productiviteit van ontwikkelaars te garanderen terwijl ze eenheidstests schrijven.

Demo gereed houden

Het systeem zou aan het eind van elke herhaling voor demo aan de zaken moeten beschikbaar zijn. Door het systeem in een demo-klaar staat te houden, zal het team altijd binnen een herhaling van klaar zijn voor productie en kan de technische schuld op een houdbaar niveau worden gehouden.

Een ononderbroken integratieomgeving implementeren en gebruiken

Het uitvoeren van een ononderbroken integratiemilieu zal u toestaan om eenheidstests en integratietests gemakkelijk en herhaalbaar in werking te stellen. Het zal ook plaatsingen van het ontwikkelingsteam loskoppelen, die de andere delen van het team om efficiënter en makend voor stabielere en voorspelbaardere plaatsingen toelaat te zijn.

Houd de ontwikkelingscyclus snel door de buildtijden laag te houden

Als de eenheidstests lang duren, zullen de ontwikkelaars vermijden lopend hen en zij zullen hun waarde verliezen. Als het lang duurt om de code te bouwen en op te stellen, zullen de mensen dit minder vaak doen. Het maken van korte bouwtijden een prioriteit verzekert dat de tijd wij in onze testdekking en infrastructuur van CI hebben geïnvesteerd het team productiever zal blijven maken.

Sonar en andere statische hulpmiddelen van de codeanalyse nauwkeurig afstemmen en op hun rapporten handelen

De instrumenten van de codeanalyse kunnen waardevol zijn, maar slechts als hun rapporten tot actie van de kant van het ontwikkelingsteam leiden. Zonder de analyse die deze instrumenten opleveren te verfijnen, zullen de aanbevelingen die ze genereren niet relevant zijn en zullen ze hun waarde verliezen.

Volg de Scout voor de jongen

De Scouten van de Jongen hebben een regel: "Laat het beter staan dan u het hebt gevonden." Zolang alle leden van het ontwikkelingsteam zich aan deze regel houden en iets opschonen wanneer ze een puinhoop tegenkomen, zal de code voortdurend verbeteren.

Gebruik geen YAGNI-functies

YAGNI-functies (of u hebt het niet nodig) worden geïmplementeerd wanneer we verwachten dat we in de toekomst iets nodig hebben, ook al hebben we het nu niet nodig. In het ideale geval moeten we het eenvoudigste ding implementeren dat vandaag werkt en ononderbroken refactoring gebruiken om ervoor te zorgen dat de architectuur van het systeem in de loop der tijd evolueert met de vereisten. Hierdoor kunnen we ons concentreren op wat belangrijk is en codeblok en eigenschapscrupules voorkomen.