Stötande programmering
Offensiv programmering är ett namn som används för den gren av defensiv programmering som uttryckligen avviker från defensiva principer när man hanterar fel som beror på programvarubuggar . Även om namnet är en reaktion på extrema tolkningar av defensiv programmering, är de två inte i grunden i konflikt. Snarare lägger offensiv programmering till en uttrycklig prioritet att inte tolerera fel på fel ställen: punkten där den avviker från extrema tolkningar av defensiv programmering är att föredra förekomsten av fel från programmets försvarslinje för att vara flagrant uppenbar framför den hypotetiska säkerhetsfördelen. att tolerera dem. Denna preferens är också det som motiverar att använda påståenden .
Särskiljande fel
Utgångspunkten för offensiv programmering är att skilja mellan förväntade fel, som kommer utanför programmets försvarslinje, hur osannolika de än är, och förebyggbara interna fel som inte ska inträffa om alla dess programvarukomponenter beter sig som förväntat.
Kontrasterande exempel:
| Förväntade fel | Förebyggbara fel |
|---|---|
| Ogiltig användarinmatning | Ogiltiga funktionsargument |
| Utarmning av OS-resurser (som lagring, minne) | Värde utanför definierat intervall (t.ex. enum ) |
| Hårdvarufel (som nätverk, lagring) | Odokumenterat returvärde eller undantag |
Buggdetekteringsstrategier
Offensiv programmering handlar om att misslyckas, så att motbevisa programmerarens antaganden. Att skapa ett felmeddelande kan vara ett sekundärt mål.
Strategier:
- Inga onödiga kontroller: Grundprincipen är att lita på att andra programvarukomponenter beter sig som specificerat, så att inte papper över något okänt problem. I synnerhet kan vissa fel redan garanteras att programmet kraschar (beroende på programmeringsspråk eller körmiljö), t.ex. genom att referera till en nollpekare . Som sådan är nollpekarkontroller onödiga för att stoppa programmet (men kan användas för att skriva ut felmeddelanden).
- Påståenden – kontroller som kan inaktiveras – är det föredragna sättet att kontrollera saker som borde vara onödiga att kontrollera, till exempel designkontrakt mellan programvarukomponenter.
- Ta bort reservkod ( limp mode ) och reservdata ( standardvärden ): Dessa kan dölja defekter i huvudimplementeringen, eller, från användarens synvinkel, dölja det faktum att programvaran fungerar suboptimalt. Särskild uppmärksamhet på oimplementerade delar kan behövas som en del av fabriksacceptanstestning , ännu inte kan oimplementerad kod i något skede av testdriven utveckling upptäckas av misslyckade enhetstester .
- Ta bort genvägskod (se strategimönstret ): En förenklad kodsökväg kan dölja buggar i en mer generisk kodsökväg om den generiska koden nästan aldrig kommer att köras. Eftersom de två är tänkta att ge samma resultat, kan den förenklade elimineras.