Testdriven Utveckling (TDD)
TDD (även känt som BDD) är ett hantverk bland software crafters som ofta gäckar utvecklare. Jag har numera en pragmatisk hållning kring TDD; TDD är ett bra verktyg för att träna sina utvecklarmuskler och ett mätinstrument på tydlighet - inte ett gyllene hammare för all utveckling.
Med det sagt är det få tekniska agila idéer som påverkat mig så mycket som TDD. När jag provade första gången 2006 var det som ett paradigmskifte i hur jag såg på programvarutveckling - plöstligt kunde jag forma koden som jag ville den skulle se ut, istället för att designen skulle vara en efterkonstruktion!
Situationer:
- Nyutveckling
- Träna på att utveckla saker i små steg
- Träna på att skriva enhetstester
- Träna på att skriva enkel produktionskod
Möjliggör:
- Hög kvalité på nyskriven kod
- Bättre API mot kod, större läsbarhet
- Ökad förmåga att dela upp kodning i små delar
- Större medvetenhet om när stories/backlog items är för oklara för att utveckla och behöver förtydligas
Mikado Method
Hur får man egentligen till systematiska förändringar av kodbaser/system utan att det blir för stort omfång, och man står där med en massa ändringar som ingen vill code reviewa?
Ett svar är med med Mikado Method. Med Mikado Method skiftar man fokus ifrån att göra en massa ändringar på en gång, till att utföra små experiment på kodbasen, och anteckna vad man lär sig. Det är ett sätt att applicera Kent Becks "Tidy First" steg-för-steg och hela tiden hålla sig i det gröna, sköna läget av kontroll på koden.
Situationer:
- Legacy system, omskrivningar
- Nyutveckling, tillägg
- Uppdateringar av beroenden, plattformsunderhåll
Möjliggör:
- Stora förbättringar av kodbaser
- Att hålla systemet och dess beroenden up-to-date
- Lära sig bli snabbare på faktorisering
- Trunk-based development
Calculations, Actions, Data
