Bästa metoder för kodning - Coding best practices

Bästa praxis för kodning är en uppsättning informella regler som mjukvaruutvecklingsgemenskapen använder för att förbättra mjukvarukvaliteten.

Många datorprogram används fortfarande under lång tid, så alla regler måste underlätta både första utvecklingen och efterföljande underhåll och förbättring av andra än de ursprungliga författarna.

I nittionittelregeln tillskrivs Tom Cargill en förklaring till varför programmeringsprojekt ofta går för sent: "De första 90% av koden står för de första 90% av utvecklingstiden. De återstående 10% av koden står för de andra 90% av utvecklingstiden. " Varje vägledning som kan åtgärda denna brist på framsynthet är värd att överväga.

Storleken på ett projekt eller program har en betydande effekt på felprocenten, programmerarens produktivitet och mängden hantering som behövs.

Mjukvarukvalitet

Huvudartikel: Programvarukvalitet

Som anges nedan finns det många attribut kopplade till bra programvara. Några av dessa kan vara ömsesidigt motsägelsefulla (t.ex. vara mycket snabba mot att utföra omfattande felkontroll), och olika kunder och deltagare kan ha olika prioriteringar. Weinberg ger ett exempel på hur olika mål kan ha en dramatisk effekt på både insats som krävs och effektivitet. Vidare noterar han att programmerare i allmänhet kommer att sträva efter att uppnå alla tydliga mål som kan sättas, förmodligen på bekostnad av andra kvalitetsattribut.

Sommerville har identifierat fyra generaliserade attribut som inte berör vad ett program gör, men hur bra programmet gör det:

Weinberg har identifierat fyra mål som ett bra program bör uppfylla:

  • Uppfyller ett program sin specifikation ("korrekt utmatning för varje möjlig ingång")?
  • Är programmet producerat enligt schemat (och inom budgeten)?
  • Hur anpassningsbar är programmet för att klara förändrade krav?
  • Är programmet tillräckligt effektivt för miljön där det används?

Hoare har identifierat sjutton mål relaterade till mjukvarukvalitet, inklusive:

  • Tydlig definition av syfte.
  • Enkel användning.
  • Robusthet (svårt att missbruka, snäll mot fel).
  • Tidig tillgänglighet (levereras i tid vid behov).
  • Pålitlighet.
  • Utökningsbarhet i ljuset av erfarenhet.
  • Korthet.
  • Effektivitet (tillräckligt snabbt för det syfte som det läggs till).
  • Minimikostnad att utveckla.
  • Överensstämmelse med alla relevanta standarder .
  • Tydliga, exakta och exakta användardokument .

Förkunskaper

Innan kodningen startar är det viktigt att se till att alla nödvändiga förutsättningar har slutförts (eller åtminstone har gått tillräckligt långt för att ge en solid grund för kodning). Om de olika förutsättningarna inte är uppfyllda kommer programvaran sannolikt att vara otillfredsställande, även om den är klar.

Från Meek & Heath: "Det som händer innan man kommer till kodningsstadiet är ofta av avgörande betydelse för projektets framgång."

Förutsättningarna som beskrivs nedan omfattar sådana frågor som:

  • hur är utvecklingen uppbyggd? (livscykel)
  • vad är programvaran avsedd att göra? (krav)
  • mjukvarusystemets övergripande struktur (arkitektur)
  • mer detaljerad design av enskilda komponenter (design)
  • val av programmeringsspråk

För små enkla projekt som endast involverar en person kan det vara möjligt att kombinera arkitektur med design och anta en mycket enkel livscykel.

Livscykel

Huvudartikel: Mjukvaruutvecklingsmetodik

En metod för mjukvaruutveckling är ett ramverk som används för att strukturera, planera och kontrollera livscykeln för en mjukvaruprodukt. Vanliga metoder inkluderar vattenfall , prototyper , iterativ och inkrementell utveckling , spiralutveckling , smidig mjukvaruutveckling , snabb applikationsutveckling och extrem programmering .

Vattenfallsmodellen är en sekventiell utvecklingsstrategi; I synnerhet förutsätter det att kraven kan definieras fullständigt i början av ett projekt. McConnell citerar dock tre studier som visar att kraven i genomsnitt ändras med cirka 25% under ett projekt. De andra metoderna som nämns ovan försöker alla minska effekten av sådana kravändringar, ofta med någon form av stegvisa, inkrementella eller iterativa metoder. Olika metoder kan vara lämpliga för olika utvecklingsmiljöer.

Krav

Huvudartikel: Kravsteknik

McConnell säger: "Den första förutsättningen du måste uppfylla innan du börjar bygga är ett tydligt uttalande om problemet som systemet ska lösa."

Meek and Heath betonar att en tydlig, fullständig, exakt och entydig skriftlig specifikation är målet att sikta på. Observera att det kanske inte är möjligt att uppnå detta mål, och målet kommer sannolikt att ändras ändå (som nämnts i föregående avsnitt).

Sommerville skiljer mellan mindre detaljerade användarkrav och mer detaljerade systemkrav. Han skiljer också mellan funktionella krav (t.ex. uppdatera en post) och icke-funktionella krav (t.ex. svarstid måste vara mindre än 1 sekund).

Arkitektur

Huvudartikel: Programvaruarkitektur

Hoare påpekar: "det finns två sätt att konstruera en mjukvarudesign: ett sätt är att göra det så enkelt att det uppenbarligen inte finns några brister; det andra sättet är att göra det så komplicerat att det inte finns några uppenbara brister. Den första metoden är mycket svårare. "

Programvaruarkitektur handlar om att bestämma vad som måste göras och vilken programkomponent som ska göra det (hur något görs lämnas till den detaljerade designfasen nedan). Detta är särskilt viktigt när ett mjukvarusystem innehåller mer än ett program eftersom det effektivt definierar gränssnittet mellan dessa olika program. Det bör också innehålla en viss hänsyn till alla användargränssnitt, utan att gå in i överdriven detalj.

Alla icke-funktionella systemkrav (responstid, tillförlitlighet, underhållbarhet etc.) måste beaktas i detta skede.

Programvaruarkitekturen är också av intresse för olika intressenter (sponsorer, slutanvändare, etc.) eftersom det ger dem en chans att kontrollera att deras krav kan uppfyllas.

Design

Huvudartikel: Programvarudesign

Det huvudsakliga syftet med design är att fylla i de detaljer som har överskådats i den arkitektoniska designen. Avsikten är att designen ska vara tillräckligt detaljerad för att ge en bra guide för faktisk kodning, inklusive detaljer om specifika algoritmer som ska användas. Till exempel på arkitektonisk nivå kan det ha noterats att vissa data måste sorteras, medan det på designnivå är nödvändigt att bestämma vilken sorteringsalgoritm som ska användas. Som ett ytterligare exempel, om en objektorienterad metod används, måste detaljerna i objekten bestämmas (attribut och metoder).

Val av programmeringsspråk

Mayer säger: "Inget programmeringsspråk är perfekt. Det finns inte ens ett enda bästa språk; det finns bara språk som är väl lämpade eller kanske dåligt lämpade för särskilda ändamål. Att förstå problemet och tillhörande programmeringskrav är nödvändigt för att välja det språk som passar bäst för lösning."

Från Meek & Heath: "Kärnan i konsten att välja språk är att börja med problemet, bestämma vad dess krav är och deras relativa betydelse eftersom det förmodligen kommer att vara omöjligt att tillfredsställa alla lika bra. De tillgängliga språken bör då mätas mot kravlistan och den mest lämpliga (eller minst otillfredsställande) valda. "

Det är möjligt att olika programmeringsspråk kan vara lämpliga för olika aspekter av problemet. Om språken eller deras kompilatorer tillåter det kan det vara möjligt att blanda rutiner skrivna på olika språk inom samma program.

Även om det inte finns något val om vilket programmeringsspråk som ska användas, ger McConnell några råd: "Varje programmeringsspråk har styrkor och svagheter. Var medveten om de specifika styrkorna och svagheterna hos det språk du använder."

Kodningsstandarder

Huvudartikel: Kodningskonventioner

Detta avsnitt är också en förutsättning för kodning, som McConnell påpekar: "Upprätta programmeringskonventioner innan du börjar programmera. Det är nästan omöjligt att ändra kod för att matcha dem senare."

Som listat nära slutet av kodningskonventioner finns det olika konventioner för olika programmeringsspråk, så det kan vara kontraproduktivt att tillämpa samma konventioner på olika språk. Det är viktigt att notera att det inte finns någon särskild kodningskonvention för något programmeringsspråk. Varje organisation har en anpassad kodningsstandard för varje typ av programvaruprojekt. Det är därför absolut nödvändigt att programmeraren väljer eller gör en särskild uppsättning kodningsriktlinjer innan mjukvaruprojektet påbörjas. Vissa kodningskonventioner är generiska som kanske inte gäller för varje mjukvaruprojekt skrivet med ett visst programmeringsspråk.

Användningen av kodningskonventioner är särskilt viktig när ett projekt involverar mer än en programmerare (det har funnits projekt med tusentals programmerare). Det är mycket lättare för en programmerare att läsa kod skriven av någon annan om all kod följer samma konventioner.

För några exempel på dåliga kodningskonventioner ger Roedy Green en lång (tunga-i-kind) artikel om hur man producerar ohållbar kod.

Kommenterar

På grund av tidsbegränsningar eller entusiastiska programmerare som vill ha omedelbara resultat för sin kod, tar kommentarerna till koden ofta baksätet. Programmerare som arbetar som ett team har funnit det bättre att lämna kommentarer bakom sig eftersom kodning vanligtvis följer cykler, eller mer än en person kan arbeta med en viss modul. Vissa kommentarer kan dock minska kostnaderna för kunskapsöverföring mellan utvecklare som arbetar på samma modul.

Under de första dagarna av datorer var en kommenterande metod att lämna en kort beskrivning av följande:

  1. Modulens namn
  2. Syftet med modulen
  3. Beskrivning av modulen
  4. Originalförfattare
  5. Ändringar
  6. Författare som ändrade koden med en beskrivning av varför den ändrades.

"Beskrivningen av modulen" ska vara så kort som möjligt men utan att offra tydlighet och omfattning.

De två sista objekten har dock i stort sett blivit föråldrade av tillkomsten av revisionsstyrsystem . Ändringar och deras upphovsrätt kan spåras på ett tillförlitligt sätt med hjälp av sådana verktyg snarare än genom att använda kommentarer.

Om komplicerad logik används är det också bra att lämna ett "block" -kommentar nära den delen så att en annan programmerare kan förstå vad som händer.

Enhetstestning kan vara ett annat sätt att visa hur koden är avsedd att användas.

Namnkonventioner

Se även: Ungerska notation

Användning av riktiga namnkonventioner anses vara god praxis. Ibland tenderar programmerare att använda X1, Y1, etc. som variabler och glömmer att ersätta dem med meningsfulla, vilket orsakar förvirring.

Det brukar anses vara god sed att använda beskrivande namn.

Exempel: En variabel för att ta in vikt som en parameter för en lastbil kan kallas TrkWeight eller TruckWeightKilograms, varvid TruckWeightKilograms är att föredra, eftersom den är direkt igenkännbar. Se namngivning av variabler i CamelCase .

Håll koden enkel

Koden som en programmerare skriver ska vara enkel. Komplicerad logik för att uppnå en enkel sak bör hållas på ett minimum eftersom koden kan ändras av en annan programmerare i framtiden. Logiken som en programmerare implementerade kanske inte är perfekt för en annan. Så håll alltid koden så enkel som möjligt.

Tänk till exempel på dessa ekvivalenta rader med C -kod: 

if (hours < 24 && minutes < 60 && seconds < 60)
{
    return true;
}
else
{
    return false;
}

och 

if (hours < 24 && minutes < 60 && seconds < 60)
    return true;
else
    return false;

och 

switch (hours < 24 && minutes < 60 && seconds < 60){
    case true:
        return true;
    break;
    case false:
        return false;
    break;
    default:
        return false;
}

och 

return hours < 24 && minutes < 60 && seconds < 60;

Den första metoden, som är mycket vanligare, är betydligt större än den fjärde. I synnerhet förbrukar den 5 gånger mer vertikalt utrymme på skärmen (rader) och 97 tecken mot 52 (även om redigeringsverktyg kan minska skillnaden i faktisk skrivning). Det kan dock argumenteras, vilket är "enklare". Den första har ett uttryckligt om/då annat, med ett uttryckligt returvärde som uppenbarligen är kopplat till var och en; även en nybörjare bör inte ha svårt att förstå det. Den andra kastar bara hängslen, skär den "vertikala" storleken till hälften med liten förändring i konceptuell komplexitet. På de flesta språk kan "retur" -uttalanden också bifogas de tidigare raderna, vilket ger "vertikal" storlek till bara en rad mer än den fjärde formen.

Den fjärde formen minimerar uppenbarligen storleken, men kan öka komplexiteten: Den lämnar de "sanna" och "falska" värdena underförstådda och blandar begreppen "villkor" och "returvärde". Det är sannolikt uppenbart för de flesta programmerare, men en nybörjare kanske inte omedelbart förstår att resultatet av utvärdering av ett tillstånd faktiskt är ett värde (av typen booleskt, eller dess motsvarighet på vilket språk som helst), och kan därmed manipuleras eller returneras. I mer realistiska exempel kan det fjärde formuläret ha problem på grund av operatörens företräde , kanske returnera en oväntad typ, där de tidigare blanketterna på vissa språk skulle rapportera ett fel. Således är "enkelhet" inte bara en fråga om längd, utan om logisk och konceptuell struktur; att göra koden kortare kan göra den mindre eller mer komplex.

För stora, långlivade program som använder generösa alternativ kan bidra till uppblåsthet .

Kompaktitet kan göra det möjligt för kodare att se mer kod per sida, vilket minskar rullningsgester och knapptryckningar. Med tanke på hur många gånger koden kan ses under processen att skriva och underhålla, kan det uppgå till en betydande besparing i programmeringstryckningar i kodens livslängd. Detta kanske inte verkar betydelsefullt för en elev som först lärde sig programmera, men när man producerar och underhåller stora program kan minskningen av hur många kodrader det finns för att mer av koden ska passa på skärmen, mindre kodförenkling kan förbättra produktiviteten och även minska finger-, handleds- och ögonbelastning, som är vanliga medicinska problem som produktionskodare och informationsarbetare lider av.

Terser -kodning hastigheter kompilering mycket, eftersom färre symboler behöver bearbetas. Dessutom kan det tredje tillvägagångssättet tillåta att liknande kodrader lättare jämförs, särskilt när många sådana konstruktioner kan visas på en skärm samtidigt.

Slutligen kan mycket korta layouter bättre utnyttja moderna bredbildsskärmar, beroende på bildskärmens layout och inställningar. Tidigare var skärmarna begränsade till 40 eller 80 tecken (sådana gränser härstammar långt tidigare: manuskript, tryckta böcker och till och med rullar har i årtusenden använt ganska korta rader (se till exempel Gutenberg Bible ). Moderna skärmar kan enkelt visa 200 eller fler tecken, vilket möjliggör extremt långa rader. De flesta moderna kodningsstilar och standarder tar inte upp hela bredden. Således, om man använder ett fönster så brett som skärmen, slösas mycket tillgängligt utrymme. Å andra sidan, med flera fönster, eller med hjälp av en IDE eller annat verktyg med olika information i sidorutor, är den tillgängliga bredden för kod i det område som är bekant från tidigare system.

Det är också värt att notera att det mänskliga visuella systemet påverkas kraftigt av linjelängd; mycket långa rader ökar läshastigheten något, men minskar förståelsen Textkolumner: Hur lång är för lång? och lägg till till ögonspårningsfel. Vissa studier tyder på att längre rader går bättre på nätet än i tryck Human Factors International , men detta går fortfarande bara upp till cirka 10 tum, och främst för råproshastighet.

Bärbarhet

Programkoden bör inte innehålla "hårdkodade" (bokstavliga) värden som hänvisar till miljöparametrar, såsom absoluta filvägar, filnamn, användarnamn, värdnamn, IP-adresser, URL: er, UDP/TCP-portar. Annars kommer programmet inte att köras på en värd som har en annan design än förväntat. En noggrann programmerare kan parametrera sådana variabler och konfigurera dem för värdmiljön utanför rätt applikation (till exempel i egendomsfiler, på en applikationsserver eller till och med i en databas). Jämför mantrat för en "single point of definition" (SPOD).

Som en förlängning bör resurser som XML -filer också innehålla variabler snarare än bokstavliga värden, annars kommer applikationen inte att vara bärbar till en annan miljö utan att redigera XML -filerna. Till exempel, med J2EE -applikationer som körs i en applikationsserver, kan sådana miljöparametrar definieras i JVM: s omfattning och programmet bör hämta värdena därifrån.

Skalbarhet

Designkod med skalbarhet som designmål eftersom det ofta i programvaruprojekt alltid läggs till nya funktioner i ett projekt som blir större. Därför blir möjligheten att lägga till nya funktioner till en programvarukodbas en ovärderlig metod för att skriva programvara

Återanvändbarhet

Återanvändning är ett mycket viktigt designmål för mjukvaruutveckling. Återanvändning minskar utvecklingskostnaderna och minskar också tiden för utveckling om komponenterna eller modulerna som återanvänds redan är testade. Mycket ofta börjar mjukvaruprojekt med en befintlig baslinje som innehåller projektet i dess tidigare version och beroende på projektet återanvänds många av befintliga programvarumoduler och komponenter vilket minskar utvecklings- och testtid vilket ökar sannolikheten för att leverera ett mjukvaruprojekt enligt schemat .

Byggriktlinjer i korthet

En allmän översikt över allt ovan:

  1. Vet vad kodblocket måste utföra
  2. Behåll namnkonventioner som är enhetliga genomgående.
  3. Ange en kort beskrivning av vad en variabel är till för (hänvisning till kommentarer)
  4. Korrigera fel när de uppstår.
  5. Håll din kod enkel
  6. Designkod med skalbarhet och återanvändning i åtanke.

Kodutveckling

Kodbyggnad

En bästa praxis för att bygga kod innebär dagliga byggnader och tester, eller ännu bättre kontinuerlig integration , eller till och med kontinuerlig leverans .

Testning

Huvudartikel: Programvarutestning

Testning är en integrerad del av mjukvaruutveckling som måste planeras. Det är också viktigt att testningen görs proaktivt; vilket innebär att testfall planeras innan kodningen startar och testfall utvecklas medan applikationen utformas och kodas.

Felsöka koden och korrigera fel

Programmerare tenderar att skriva hela koden och sedan börja felsöka och leta efter fel. Även om detta tillvägagångssätt kan spara tid i mindre projekt, tenderar större och komplexa att ha för många variabler och funktioner som kräver uppmärksamhet. Därför är det bra att felsöka varje modul när du är klar och inte hela programmet. Detta sparar tid i längden så att man inte slutar slösa mycket tid på att ta reda på vad som är fel. Enhetstester för enskilda moduler och/eller funktionstester för webbtjänster och webbapplikationer kan hjälpa till med detta.

Spridning

Huvudsakliga artiklar: programdistribution och distributionsmiljö

Distribution är det sista steget för att släppa en applikation för användare. Några bästa metoder är:

  1. Håll installationsstrukturen enkel: Filer och kataloger bör hållas till ett minimum. Installera inte något som aldrig kommer att användas.
  2. Behåll bara det som behövs: Programvarukonfigurationshanteringsaktiviteterna måste se till att detta tillämpas. Oanvända resurser (gamla eller misslyckade versioner av filer, källkod, gränssnitt, etc.) måste arkiveras någon annanstans för att hålla nyare byggnader smala.
  3. Håll allt uppdaterat: Programvarans konfigurationshanteringsaktiviteter måste se till att detta tillämpas. För deltabaserade distributioner, se till att de versioner av de resurser som redan distribueras är de senaste innan du distribuerar deltorna. Om du inte är säker, utför en distribution från början (ta bort allt först och distribuera sedan om).
  4. Anta en strategi i flera steg: Beroende på projektets storlek krävs ibland fler distributioner.
  5. Har en roll back-strategi: Det måste finnas ett sätt att rulla tillbaka till en tidigare (fungerande) version.
  6. Lita på automatisering för repeterbara processer: Det finns alldeles för mycket utrymme för mänskliga fel, distributioner bör inte vara manuella. Använd ett verktyg som är inbyggt i varje operativsystem eller använd ett skriptspråk för plattformsoberoende distributioner.
  7. Återskapa den verkliga distributionsmiljön: Tänk på allt (routrar, brandväggar, webbservrar, webbläsare, filsystem, etc.)
  8. Ändra inte implementeringsprocedurer och skript direkt och dokumentera sådana ändringar: Vänta på en ny iteration och registrera sådana ändringar på lämpligt sätt.
  9. Anpassa distributionen: Nyare mjukvaruprodukter som API: er, mikrotjänster etc. kräver särskilda överväganden för framgångsrik distribution.
  10. Minska risken från andra utvecklingsfaser: Om andra aktiviteter som testning och konfigurationshantering är felaktigt misslyckas distributionen.
  11. Tänk på vilket inflytande varje intressent har: Organisatoriska, sociala, statliga överväganden.

Se även

Referenser

Allmän

externa länkar