Featureflaggor i AI-genererad kod: ta bort döda grenar utan att tappa beteendet

Flaggan är utrullad – men vad betyder det?

Tänk dig en AI-assisterad ändring i en tjänst som beräknar frakt. Den nya beräkningen aktiverades bakom en tillfällig releaseflagga. I produktion ser teamet nu bara den nya varianten. En utvecklare ber assistenten ”städa koden” och får en diff som tar bort villkoret och den gamla funktionen. Diffen ser liten ut, men underlaget säger ännu inte vad som händer i testmiljö, för en kundgrupp med egen targeting eller när flaggtjänsten inte kan svara.

LaunchDarklys vägledning om flaggskuld skiljer tillfälliga flaggor från permanenta. En tillfällig releaseflagga ska bort ur koden när den har gjort sitt jobb. En permanent flagga kan däremot styra till exempel rättigheter eller avlastning under längre tid. Klassificera därför flaggan först. Om teamet fortfarande behöver kunna stänga av fraktberäkningen snabbt är det ett produktionskrav som måste få en egen lösning och ägare, inte något som råkar bli kvar som gammal gren.

I LaunchDarkly kan en tillfällig flagga märkas ”Ready for code removal” när den inte längre utvärderas eller när den ger samma variation till alla sammanhang. Det är en LaunchDarkly-specifik livscykelmarkör. Den visar inte automatiskt att alla repor, miljöer och reservvärden ger samma beteende. Leverantören rekommenderar också att jämföra miljöer, eftersom en flagga kan vara utrullad i några men inaktiv eller annorlunda konfigurerad i en annan.

Gör en liten inventering innan diffen

Sök efter flaggans nyckel i applikation, tester, konfiguration, migreringsskript och dokumentation. Sök också efter variabelnamn som används runt uppslaget; en inbakad wrapper kan dölja den direkta nyckeln. Notera vilken tjänst som äger varje träff och vilken miljö som kör koden. Den som använder LaunchDarkly kan ta hjälp av dess code references, men en sökning i det faktiska repot behövs även när ett verktyg visar noll referenser.

För varje berörd miljö skriver du ner tre saker: nuvarande variation, explicit targeting och reservvärdet som används om flaggan inte kan utvärderas. Jämför dem med det beteende som produktägaren vill behålla. Om gammal kod fortfarande nås vid fallback är den inte död i praktiken. Antingen ändrar du fallback och verifierar den före rensningen, eller så skjuter du upp borttagningen. Ett dashboardvärde från produktion räcker inte för att avgöra vad en fristående testmiljö gör.

Välj också en tydlig rollbackgräns. Före rensningen kan teamet kanske byta flaggvariation. Efter att grenen tagits bort kräver återgång en ny kodversion, om ingen annan reservmekanism finns. Skriv in den skillnaden i ändringsförslaget och säkerställ att föregående version går att återställa inom den tid verksamheten behöver. Vår artikel om refaktorering utan beteendeändring visar varför ett dokumenterat kontrakt behövs när strukturen ändras.

Ett före/efter-exempel med en avsedd skillnad

Det här är förenklad pseudokod för kodgranskning, inte ett körbart exempel. Antagandet som först måste beläggas är att newShippingPrice ska användas i samtliga berörda fall. Både före- och efterbilden visar samma omslutande funktion och samma indata:

// Före
function shippingPrice(order) {
  const useNewPrice = flags.variation("new-shipping-price", order.customer, false);
  return useNewPrice ? newShippingPrice(order) : oldShippingPrice(order);
}

// Efter
function shippingPrice(order) {
  return newShippingPrice(order);
}

Skillnaden är precis villkoret och den gamla grenen. Den är korrekt bara om beslutet om variation, miljöer och fallback håller. Om oldShippingPrice fortfarande används någon annanstans ska funktionen inte tas bort enbart för att just detta anrop försvinner. Om den nya beräkningen kräver data som saknas i äldre order behöver provet omfatta ett sådant orderfall innan diffen godkänns. Be AI-assistenten visa sökträffarna och den föreslagna diffen; låt inte dess påstående ”oanvänd kod” ersätta kontrollen.

Välj prov för beteendet som ska vara kvar

LaunchDarklys testguide avråder från att försöka prova varje kombination av alla flaggor. Den föreslår definierade scenarier som speglar nuvarande och kommande produktionsläge, fallback och särskilt viktiga feltillstånd. Översatt till fraktexemplet blir en avgränsad provlista mer meningsfull än en stor matris utan koppling till beslutet:

1. Före ändringen: kör ett vanligt orderfall och ett äldre orderfall med den valda variationen. Spara förväntat belopp och avrundningsregel. Kör samma fall mot den föreslagna koden och jämför resultatet.
2. Reservvägen: kontrollera vad tjänsten gör när flaggvärdet saknas eller hämtningen fallerar. Om gammal beräkning då fortfarande används, stoppa rensningen tills teamet har beslutat och provat en ny reservväg.
3. Integrationen: prova en faktisk orderväg genom API eller gränssnitt, inte bara den isolerade funktionen. Säkerställ att fraktbeloppet som sparas och visas motsvarar det beräknade värdet.
4. Efter ändringen: sök igen efter flaggnyckeln och den gamla funktionen. Gå igenom kvarvarande träffar manuellt; en träff i ett historiskt dokument kan få stå kvar medan ett aktivt uppslag inte kan det.

Enhetstester som styrs av en extern flaggtjänst kan ge varierande resultat. Testguiden beskriver mockar och kontrollerade datakällor för bestämda flaggvärden, med stöd som skiljer sig mellan SDK:er. I vårt exempel ska provet jämföra just fraktbeloppet och dess kontrakt, inte bara att newShippingPrice anropades. Vår bredare guide till testning av AI-genererad kod hjälper när enhetstestet behöver kompletteras med ett prov genom hela flödet. Proven ovan är förslag; inga egna tester har körts för den här artikeln.

Rensa i rätt ordning och lämna en väg tillbaka

Gör kodrensningen som en avgränsad ändring: behåll den beslutade grenen, ta bort flagguppslaget och den gamla grenen, uppdatera testerna och granska diffen. Ta bort eventuella oanvända hjälpfunktioner först när sökningen visar att inget annat aktivt anrop behöver dem. Låt en människa som känner fraktreglerna granska resultatet. Om flera flaggor samverkar med samma beräkning bör deras kvarvarande tillstånd beskrivas var för sig.

Först efter att den nya koden har rullats ut och verifierats i berörda miljöer är det dags att avsluta flaggan i dess verktyg. I LaunchDarkly bevarar arkivering historiken medan radering tar bort den; leverantören rekommenderar att kodreferenser tas bort före arkivering. I andra verktyg behöver du kontrollera motsvarande livscykel och återgångssteg. Anteckna versionen som kan återställas och vilket observerbart fel – till exempel avvikande fraktbelopp för äldre order – som utlöser en återgång.

En kort granskningskommentar räcker om den är konkret: ”Flaggan ger ny beräkning i de tre miljöer som kör tjänsten; targeting och fallback är kontrollerade. Före/efter-proven för vanliga och äldre order är gröna, API-provet ger samma belopp och sökningen visar inga aktiva flagganrop. Vid fel återställer vi föregående version.” Skriv bara det som faktiskt har verifierats i ditt projekt. Om ett av bevisen saknas är beslutet fortfarande öppet.