Som programmerare är din roll att skriva kod som fungerar korrekt och ger önskat resultat. Koden måste dock också vara lätt att förstå, underhålla och utöka. För att möta denna utmaning är det nödvändigt att kombinera programmerings nyckelbegrepp med principerna för bra kodning.
I det här inlägget kommer jag att dela med mig av mina 10 bästa programmeringsprinciper för att hjälpa dig att förbättra sättet du skriver kod på, vilket gör livet lättare för dig, dina andra utvecklare och dina slutanvändare.
Varför är programmeringsprinciper viktiga?
Om du lär dig några programmeringsprinciper och använder dem i din kod kommer du att bli en bättre utvecklare. Att följa dessa metoder förbättrar den övergripande kvaliteten på koden och gör det lättare för dig eller någon annan att göra ändringar eller lägga till funktioner i framtiden.
Bildkälla: Generös
Programmeringsprinciper hjälper dig att undvika problem som förvirrande eller alltför komplex kod, program som bryter med en enskild inställning och variabler som inte är vettiga. Om du följer dem kommer du också att kunna samarbeta mer framgångsrikt genom att se till att andra programmerare kan förstå din kod.
Oavsett om du bygger ett grundläggande program eller en applikation på företagsnivå är det värt att bekanta dig med dessa 10 principer.
Tio programmeringsprinciper att följa:
1. KYSS (Håll det enkelt, dumt!)
Att hålla din kod enkel och ren är en av de viktigaste programmeringsprinciperna. enterprisVissa utvecklare gillar att visa upp sig genom att skriva för lång eller avancerad kod, men även om det verkar smart är koden kanske inte särskilt tydlig.
Du bör alltid sträva efter att göra din kod lätt att förstå; Om du kan skriva ett manus på en rad, gör det! Du kan dela upp ett komplext problem i mindre delar eller ta bort onödig kod. Målet är att minska komplexiteten och lösa problem, inte imponera på människor.
Att använda tydliga variabelnamn är ett annat sätt att hålla det enkelt. Kom ihåg att utnyttja befintliga kodningsbibliotek och verktyg.
2. Upprepa inte dig själv (TORRA)
Programmerare älskar akronymer, eller hur? Den här är lätt att komma ihåg: den säger åt dig att inte upprepa koden. Upprepning är ett vanligt misstag eftersom om du duplicerar data, logik eller funktioner blir din kod lång och tar längre tid att underhålla, felsöka eller ändra.
Upprepning inkluderar att kopiera och klistra in kod i ditt program. Istället för att duplicera rader är det bättre att hitta en algoritm som använder en loop, eftersom det är mycket lättare att felsöka en loop som hanterar 20 repetitioner än 20 kodblock som var och en hanterar en repetition.
Motsatsen till DRY-principen är WET (naturligtvis), som står för Write Everything Twice eller Waste Everyone’s Time. Ingen av dem är en bra idé.
Bildkälla: tekniskt mål
3. Du kommer inte att behöva det (YAGNI)
Om ett liknande ämne bör du inte skriva kod bara om du har chansen att du kommer att behöva den i framtiden. Med andra ord, YAGNI-principen säger åt dig att bara skriva kod för den aktuella situationen istället för att försöka lösa ett problem som inte finns.
Funktioner och funktioner bör endast läggas till vid behov. Annars kommer din programvara eller ditt program att bli större och mer komplex än nödvändigt. YAGNI kommer från mjukvaruutvecklingsmetoden Extreme Programming (XP), som syftar till att minska ineffektiviteten.
Programmerare bryter ibland mot denna princip när de försöker följa DRY-kodningsmetoderna, så tänk på båda.
4. Dokumentera din kod
Tja, du har skrivit din kod och du förstår den (hoppas jag!). Men bara för att det är vettigt för dig betyder det inte att det blir tydligt för någon annan. Du kan hjälpa dina andra utvecklare genom att dokumentera din kod med kommentarer och förbättra namngivningen av dina variabler och funktioner.
Om du till exempel designade en samtalsdirigeringsalgoritm för användning i VoIP-telefoncenterlösningar, kan du lämna kommentarer för att förklara de olika funktionerna och göra dem lättare att förstå för andra utvecklare eller testare.
Alla programmeringsspråk låter dig bifoga kommentarer till din kod, så du bör vänja dig vid att göra detta. Ja, det är lite extraarbete, men det är viktigt när man samarbetar med andra. Dessutom, om du ändrar koden igen om några månader, kommer du att vara glad att du gjorde det!
Bildkälla: Hon kan koda
5. Sammansättning om arv
Om du återanvänder kod som du redan har skrivit finns det två sätt att göra det: arv och sammansättning. De flesta programmerare föredrar komposition (även om arv har sina fördelar, så uteslut det inte helt).
Principen om komposition framför arv är särskilt användbar om du använder objektorienterad programmering eller OOP (som faktiskt har sin egen uppsättning principer). Den anger att objekt med komplexa beteenden måste innehålla förekomster av objekt med individuella beteenden; De ska inte ärva en klass och lägga till nya beteenden.
Med arv blir klassramar snabbt otympliga, vilket resulterar i otaliga klasser som kanske eller kanske inte uppfyller dina behov. Klasshierarkier är svåra att ändra när de väl har implementerats, eftersom du inte kan ändra en superklass utan att riskera att bryta en användares underklass. Och det finns mindre flexibilitet att definiera speciella fallbeteenden.
Kompositionsprogrammering är renare att skriva och lättare att underhålla, vilket ger en enklare, mer testbar kodbas. Möjliggör beteenden som definierar flexibilitet: du kan designa klasser för enkla tillägg eller ändringar och fördröja skapandet av komponenter tills de behövs.
6. Öppen/stängd
Om du släpper ett bibliotek eller ramverk som andra kommer att använda är Open/Closed en viktig princip. Det betyder att programvaruartefakter, såsom klasser och moduler, är öppna för förlängning men stängda för modifiering. Detta gör koden mer stabil och lättare att underhålla.
Anta att du ombeds skriva kod för ett e-signaturprogramvaruföretags mall för agenturavtal>. Du släpper en version av ramverket för kodare att modifiera direkt och integrera i deras publicerade kod. Men om du släpper en större uppdatering i framtiden kommer koden att gå sönder. Det är bäst att publicera kod som uppmuntrar förlängning samtidigt som man undviker direkt modifiering, vilket minimerar risken för att nya buggar introduceras.
7. Enskilt ansvar
Denna princip säger att varje klass eller modul i ett program endast ska tillhandahålla en specifik funktionalitet och det ska inte finnas mer än en anledning till att en klass ändras. Målet är att undvika att multiplicera biverkningar eller ansvar i en enda metod eller klass.
Bildkälla: Halv
Klasser blir mer komplicerade om du lägger till för många ansvarsområden, och det är svårare att skapa ytterligare funktioner för en specifik modul. Det är bäst att dela upp dem i mindre klasser och moduler, vilket gör det lättare att isolera en viss modul för felsökning.
Single Responsibility och Open/Closed är en del av SOLID-principerna som fastställts av Robert C Martin (de andra är Liskov Substitution, Interface Segregation och Dependency Inversion).
8. SoC: separation av bekymmer
Denna programmeringsprincip är en abstrakt version av enskilt ansvar. SoC säger att ett program ska utformas med olika behållare, som inte ska ha tillgång till varandra. Varje kod är helt oberoende.
Det är ett sätt att dela upp en komplicerad applikation i olika sektioner eller domäner, som var och en gör ett specifikt jobb eller tar upp olika problem. Detta gör det lättare att underhålla, uppdatera, återanvända och felsöka din kod.
Ett välkänt exempel är model-view-controller (MVC) layout, som för närvarande används i populära webbramverk. Ett program är uppdelat i tre distinkta sektioner: data (modell), logik (kontroller) och vad slutanvändaren ser (vy), och varje sektion hanteras oberoende.
9. Minimera kopplingen
Kodkoppling sker när två moduler eller två lager har en viss grad av ömsesidigt beroende, som att dela kod eller ha tillgång till samma data. Detta kan skapa problem, inklusive kod som är svår att följa och underhålla.
Till exempel, om en utvecklare kombinerar sina API-slutpunkter med en specifik vy i en frontend-applikation, till exempel ett telefonsystem med flera linjer, kan slutpunkten inte återanvändas för en annan vy, till exempel en mobilapplikation. (Du kanske undrar: vad är ett telefonsystem med flera linjer?)
Programmerare måste förstå hur kod kopplas ihop för att minimera kopplingen, vilket innebär att man förstår varje lagers ansvar. Ett enda ansvar minskar också kopplingen mellan enskilda mjukvarukomponenter och kod.
Bildkälla: Manning
10. Refaktor
Kodbaser utvecklas alltid, så det kommer att finnas tillfällen då du behöver granska, skriva om eller designa om hela kodbitar. Istället för att se detta som ett misslyckande av ditt första försök, betrakta det som en möjlighet att lära sig.
Refaktorering av kod innebär att granska den och leta efter sätt att optimera den, göra den mer effektiv och hålla resultaten exakt desamma. Du bör dock undvika för tidig optimering. Optimera inte din algoritm i det tidiga utvecklingsskedet eftersom du inte kan förutsäga flaskhalsar och kraven kan ändras.
Slutgiltiga tankar
Om vi skulle koka ner den här listan till en nyckelprincip skulle det vara denna: gör din kod lätt att förstå och underhålla. Flera av programmeringsprinciperna på vår lista har detta syfte i åtanke, från KISS och DRY till ett enda ansvar och att dokumentera din kod.
Genom att följa dessa principer kommer du att kunna skapa enkel kod som gör vad den ska göra och som andra kan förstå. Och du kommer att veta rätt tidpunkt för att optimera det. Ett sista råd: fortsätt lära dig att fortsätta förbättra dig.
