10 Grundläggande programmeringsprinciper Varje programmerare måste följa

Vem som helst kan skriva kod. Men bra kod? Det är där det blir svårt.

Vi har alla hört skräckhistorier om spaghettikod, massiva if-else-kedjor, hela program som kan bryta sig bara genom att ändra en variabel, funktioner som ser ut som de var förvirrade och så vidare. Det är vad som händer när du försöker göra en leveransbar produkt med bara en termin av programmeringserfarenhet under ditt bälte.

Förnjut dig inte för att skriva kod som Arbetar. Syfte att skriva kod som kan bibehållas - inte bara av dig själv utan av någon annan som kanske hamnar på programvaran någon gång i framtiden. För det ändamålet finns här flera principer för att hjälpa dig att rensa upp din handling.

1. KISS

De “håll det enkelt, dumt” princip gäller stort sett hela livet, men det är särskilt nödvändigt i medelstora programprojekt.

Det börjar sättet i början när du definierar omfattningen av det du vill skapa. Bara för att du är passionerad om spelutveckling betyder inte att du kan skapa nästa World of Warcraft eller Grand Theft Auto. När du tror att du har förenklat nog, förenklar du en nivå ytterligare - funktionskryp är oundviklig, så börja små.

Men även efter att kodningen har börjat, behåll det enkelt. Komplex kod tar längre tid att designa och skriva, är mer benägen för fel och fel, och är svårare att ändra senare på vägen. I Antoine de Saint-Exuperys kloka ord, “Perfektion uppnås, inte när det inte finns något att lägga till, men när det inte finns något kvar att ta bort.”

2. Torka

De “repetera inte dig själv” princip är avgörande för ren och lättanpassad kod. När du skriver kod vill du undvika dubbelarbete och dubbelarbete. Om du märker att samma bit av kod skrivs om och om igen, bryter du den här principen.

Det motsatta av DRY-koden är WET-kod: “skriv allt två gånger” (eller “slösa allas tid”). Ett av de bästa sätten att diagnostisera WET-koden är att fråga dig själv: för att ändra programmets beteende på något sätt, hur många områden av kod skulle du behöva ändra?

Antag att du skriver en podcast-katalogapp. På söksidan har du kod för att hämta en podcasts detaljer. På podcastsidan har du kod för att hämta den aktuella poddsändningsinformationen. På favoritsidan, samma hämtningskod. Överväg att abstrahera allt detta till en funktion så att om du behöver redigera det senare kan du göra allt på en plats.

3. Öppna / Stängda

Oavsett om du skriver objekt Vad är objektorienterad programmering? Grunderna förklaras i Laymans villkor Vad är objektorienterad programmering? Grunderna förklaras i Laymans villkor De flesta moderna programmeringsspråk stöder "OOP-paradigmet" med objektorienterad programmering. Men vad är OOP och varför är det så användbart? Läs mer i Java eller moduler i Python, du bör sikta på att skapa din kod öppen för förlängning men stängd för modifiering. Detta gäller alla typer av projekt, men är särskilt viktigt när man släpper ut ett bibliotek eller ram som är avsedd för andra att använda.

Anta till exempel att du upprätthåller en GUI-ram. Du kan släppa det som, och förväntar dig att slutanvändare direkt ändrar och integrerar din släppta kod. Men vad händer när du släpper ut en stor uppdatering fyra månader senare? Hur implementerar de alla dina tillägg utan att kasta bort allt arbete de har gjort?

Istället släpp kod som förhindrar direkt modifiering och uppmuntrar förlängning. Detta skiljer kärnbeteende från modifierat beteende. Fördelarna? Större stabilitet (användarna kan inte oavsiktligt bryta kärnbeteende) och större underhåll (användare bara oroa sig för utökad kod). Den öppna / slutna principen är nyckeln till att göra ett bra API Vad är API: er och hur är öppna API: er som ändrar Internet Vad är API: er och hur är öppna API: er som ändrar Internet Har du någonsin undrat hur program på din dator och de webbplatser du besöker "prata med varandra? Läs mer .

4. Sammansättning> Arv

De “komposition över arv” princip säger att objekt med komplexa beteenden bör göra det genom att innehålla förekomster av föremål med individuella beteenden snarare än att ärva i en klass och lägga till nya beteenden.

Överförenlighet på arv kan leda till två stora problem. Först kan arvshierarkin bli rörig i ögonkontakt. För det andra har du mindre flexibilitet för att definiera specialfallets beteenden, särskilt när du vill genomföra beteende från en arvsgren i en annan arvsgren:

Sammansättning är mycket renare att skriva, lättare att underhålla, och möjliggör nära oändlig flexibilitet vad beträffar vilka typer av beteenden du kan definiera. Varje enskilt beteende är sin egen klass, och du skapar komplicerade beteenden genom att kombinera individuella beteenden.

5. Enkelt ansvar

De principen om ensam ansvar säger att alla klasser eller moduler i ett program endast bör handla om att ge en viss specifik funktionalitet. Som Robert C. Martin lägger den, “En klass bör bara ha en anledning att ändra.”

Klasser och moduler börjar ofta på det här sättet, men när du lägger till funktioner och nya beteenden är det lätt för dem att utvecklas till gudklasser och gudmoduler som tar upp hundratals eller till och med tusentals kodlinjer. Vid denna tidpunkt bör du bryta dem upp i mindre klasser och moduler.

6. Separation av oro

De separation av principen om bekymmer är som principen om enhetsansvar, men på en mer abstrakt nivå. I huvudsak bör ett program utformas så att det har många olika icke överlappande inkapslingar, och dessa inkapslingar bör inte veta om varandra.

Ett välkänt exempel på detta är modell-view-controller (MVC) paradigmet, som skiljer ett program i tre distinkta områden: data (“modell”), logiken (“kontrollant”), och vad slutanvändaren ser (“se”). Variationer av MVC är vanliga i dagens mest populära webbramar.

Koden som hanterar lastning och lagring av data till en databas behöver till exempel inte veta hur man gör den data på webben. Renderingskoden kan ta in data från slutanvändaren, men skickar sedan in den till logikoden för bearbetning. Varje del hanterar sig själv.

Detta resulterar i modulär kod, vilket gör underhållet mycket enklare. Och i framtiden, om du någonsin behöver skriva om alla återgivningskoder, kan du göra det utan att oroa sig för hur data sparas eller logiken behandlas.

7. YAGNI

De “du behöver inte det” princip är tanken att du aldrig ska koda för funktionalitet som du Maj behöver i framtiden. Chansen är du vana behöver det och det kommer att bli slöseri med tid - och inte bara det, men det kommer oundvikligen att öka din kods komplexitet.

Du kan se detta som en specifik tillämpning av KISS-principen och ett svar på dem som tar DRY-principen för allvarligt. Ofta experterar experter försöker skriva den mest abstrakta och generiska koden som är möjlig för att undvika WET-kod, men för mycket abstraktion hamnar i uppblåst omöjlig att underhålla kod.

Tricket är att tillämpa DRY-principen endast när du behöver. Om du märker bitar av kod som skrivs om och om, så abstrakt dem - men aldrig när du tror ett stycke kod kommer att skrivas om och om igen. Mer gånger än inte kommer det inte att vara.

8. Undvik tidig optimering

De ingen prematur optimeringsprincip liknar YAGNI-principen. Skillnaden är att YAGNI tar upp tendensen till genomföra beteenden innan de är nödvändiga medan denna princip tar upp tendensen till påskynda algoritmer innan det är nödvändigt.

Problemet med för tidig optimering är att du aldrig någonsin kan veta var ett program flaskhalsar kommer att vara förrän efter det faktum. Du kan givetvis gissa, och ibland kan du till och med vara rätt. Men oftast kommer du att slösa bort värdefull tid på att försöka påskynda en funktion som inte är så långsam som du tror eller inte kallas så ofta som du förväntar dig.

Nå dina milstolpar så enkelt som möjligt, då profilera din kod att identifiera sanna flaskhalsar.

9. Refactor, Refactor, Refactor

En av de svåraste sanningarna att acceptera som en oerfaren programmerare är det kod kommer sällan ut rätt första gången. Det kan känna rätt när du implementerar den glänsande nya funktionen, men när ditt program växer i komplexitet kan framtida funktioner hindras av hur du skrev den tidiga.

Kodbaser utvecklas ständigt. Det är helt normalt att återgå, skriva om eller till och med omskapa hela bitar av kod - och inte bara normalt, men hälsosamt att göra det. Du vet mer om ditt projekts behov nu än när du gjorde på Start, och du bör regelbundet använda denna nyskapade kunskap för att refactor gamla koden.

Observera att det inte alltid måste vara en stor process. Ta en sida från Boy Scouts of America, som bor enligt dessa ord: “Lämna campingplatsen renare än du hittade den.” Om du någonsin behöver kontrollera eller ändra gammal kod, rengör den alltid och lämna den i ett bättre skick.

10. Rengör kod> Clever Code

Tala om ren kod, lämna ditt ego vid dörren och Glöm inte att skriva smart kod. Du vet vad jag pratar om: den typ av kod som ser mer ut som en gåta än en lösning och existerar uteslutande för att visa upp hur smart du är. Sanningen är, ingen bryr sig verkligen.

Ett exempel på smart kod packar så mycket logik i en linje som möjligt. Ett annat exempel är att utnyttja språkets komplicationer för att skriva konstiga men funktionella uttalanden. Något som kan få någon att säga “Vänta, va?” när du går över din kod.

Bra programmerare och läsbar kod går hand i hand. Lämna kommentarer när det behövs. Håll dig till stilguider, antingen dikterade av ett språk (som Python) eller ett företag (som Google). Observera per-språk-idiom och sluta skriva Java-kod i Python eller vice versa. Se vår artikel om tips för att skriva renare kod 10 Tips för att skriva renare och bättre kod 10 Tips för att skriva renare och bättre kod Skriva ren kod ser lättare ut än det faktiskt är, men fördelarna är värda det. Så här kan du börja skriva renare kod idag. Läs mer .

Vad gör en bra programmerare?

Fråga fem personer och du får 10 olika svar. För mig är en bra programmerare en som förstår att kodning i slutändan ska tjäna slutanvändaren, som är lätt att arbeta med i ett lag och som avslutar sina projekt till specifikation och i tid.

Om du bara har börjat, oroa dig inte för mycket om det ännu. Fokusera på att lära sig hur man kodar utan stress. Om du känner dig fast, se vår artikel om att övervinna programmerarens block. Och om du inte bara är en bra skrivkod, läs vår artikel om tecken som du inte är avsedd att vara en programmerare. 6 Tecken på att du inte är avsedd att vara programmerare. 6 Tecken på att du inte är avsedd att vara programmerare. Inte alla är klippa ut för att vara en programmerare. Om du inte är helt säker på att du är avsedd att vara programmerare, här är några tecken som kan peka dig i rätt riktning. Läs mer .

Hur skulle du definiera en bra programmerare? Fick några tips för oerfarna programmerare som vill förbättra? Dela med oss ​​ner i kommentarerna nedan!

Utforska mer om: Programmering.