10 Grunnleggende programmeringsprinsipper Hver programmerer må følge

Alle kan skrive kode. Men god kode? Det er der det blir tøft.

Vi har alle hørt horrorhistorier om spaghetti kode, massive if-else-kjeder, hele programmer som kan knekke bare ved å endre en variabel, funksjoner som ser ut som de var forvirret, og så videre. Det er det som skjer når du prøver å lage et overførbart produkt med bare et semester med programmeringserfaring under beltet ditt.

Ikke sett deg for å skrive kode som virker. Sikt å skrive kode som kan opprettholdes - ikke bare av deg selv, men av noen andre som kanskje ender med å jobbe med programvaren på et tidspunkt i fremtiden. Til dette formål er det flere prinsipper for å hjelpe deg med å rydde opp din handling.

1. KISS

De “gjør det enkelt dummen” prinsipp gjelder stort sett hele livet, men det er spesielt nødvendig i mellomstore programmeringsprosjekter.

Det starter måte i begynnelsen når du definerer omfanget av det du vil opprette. Bare fordi du er lidenskapelig om spillutvikling, betyr ikke at du kan opprette det neste World of Warcraft eller Grand Theft Auto. Når du tror du har forenklet nok, forenkle det ett nivå videre - funksjonskryp er uunngåelig, så begynn liten.

Men selv etter at kodingen har begynt, hold det enkelt. Kompleks kode tar lengre tid å designe og skrive, er mer utsatt for feil og feil, og er vanskeligere å modifisere senere nedover veien. I Antoine de Saint-Exuperys vise ord, “Perfeksjon oppnås, ikke når det ikke er noe å legge til, men når det ikke er noe igjen å ta bort.”

2. Tørk

De “Gjenta ikke selv” prinsipp er avgjørende for ren og lett å endre kode. Når du skriver kode, vil du unngå duplisering av data og duplisering av logikk. Hvis du oppdager at det samme stykket kode blir skrevet om og om igjen, bryter du dette prinsippet.

Det motsatte av DRY-koden er WET-kode: “skriv alt to ganger” (eller “kaste bort alles tid”). En av de beste måtene å diagnostisere WET-koden er å spørre deg selv: For å endre programmets oppførsel på en eller annen måte, hvor mange områder av kode vil du trenge å endre?

Anta at du skriver en podcast-katalogapp. På søkesiden har du kode for å hente en podcasts detaljer. På podcastsiden har du kode for å hente den podcastens detaljer. På favorittsiden, samme hentekode. Vurder å abstrahere alt dette til en funksjon, slik at hvis du trenger å redigere det senere, kan du gjøre alt på ett sted.

3. Åpne / Lukkede

Enten du skriver objekter Hva er objektorientert programmering? Grunnleggende forklart i Laymans vilkår Hva er objektorientert programmering? Grunnleggende omtalt i Laymans vilkår De fleste moderne programmeringsspråk støtter OOP-paradigmet (Object Oriented Programming). Men hva er OOP og hvorfor er det så nyttig? Les mer i Java eller moduler i Python, du bør sikte på å lage koden din åpen for forlengelse, men lukket for endring. Dette gjelder for alle typer prosjekter, men er spesielt viktig når du slipper bibliotek eller rammer som er ment for andre å bruke.

For eksempel, anta at du opprettholder et GUI-rammeverk. Du kan frigjøre det som, og forventer at sluttbrukere direkte endrer og integrerer den utgitte koden. Men hva skjer når du slipper en stor oppdatering fire måneder senere? Hvordan implementerer de alle dine tillegg uten å kaste bort alt arbeidet de har gjort?

I stedet slipper du kode som hindrer direkte modifikasjon og oppmuntrer forlengelse. Dette skiller kjernegang fra endret oppførsel. Fordelene? Større stabilitet (brukerne kan ikke ved et uhell bryte kjerneadferd) og større vedlikeholdsevne (brukerne bare bekymre seg for utvidet kode). Det åpne / lukkede prinsippet er nøkkelen til å lage en god API Hva er APIer, og hvordan er åpne APIer forandre Internett Hva er APIer, og hvordan er åpne APIer forandre Internett Har du noen gang lurt på hvordan programmer på datamaskinen din og nettstedene du besøker "snakke med hverandre? Les mer .

4. Sammensetning> Arv

De “sammensetning over arv” prinsipp sier at objekter med komplisert oppførsel bør gjøre det ved å inneholde forekomster av objekter med individuell oppførsel fremfor å arve en klasse og legge til ny oppførsel.

Overreliance på arv kan føre til to store problemer. For det første kan arvshierarkiet bli rotete i blikket på øyet. For det andre har du mindre fleksibilitet for å definere spesielle saker, spesielt når du vil implementere atferd fra en arvavdeling i en annen arveavdeling:

Sammensetningen er mye renere å skrive, lettere å vedlikeholde, og muliggjør nesten uendelig fleksibilitet så langt som hva slags oppførsel du kan definere. Hver enkelt oppførsel er sin egen klasse, og du oppretter komplisert oppførsel ved å kombinere individuelle oppføringer.

5. Enkelt ansvar

De enkeltansvarsprinsipp sier at hver klasse eller modul i et program bare skal omhandle seg med å gi en bit av spesifikk funksjonalitet. Som Robert C. Martin setter det, “En klasse skal bare ha en grunn til å forandre seg.”

Klasser og moduler starter ofte på denne måten, men når du legger til egenskaper og ny oppførsel, er det enkelt for dem å utvikle seg til gudklasser og gudmoduler som tar opp hundrevis eller tusenvis av kodelinjer. På dette tidspunktet bør du bryte dem opp i mindre klasser og moduler.

6. Separasjon av bekymringer

De separasjon av bekymringer prinsipp er som ettansvarsprinsippet, men på et mer abstrakt nivå. I hovedsak bør et program utformes slik at det har mange forskjellige ikke-overlappende innkapslinger, og disse innkapslingene burde ikke vite om hverandre.

Et godt eksempel på dette er modell-view-controller (MVC) paradigmet, som skiller et program inn i tre forskjellige områder: dataene (“modell”), logikken (“kontrolleren”), og hva sluttbrukeren ser (“utsikt”). Variasjoner av MVC er vanlige i dagens mest populære webrammer.

Koden som håndterer lasting og lagring av data til en database, trenger for eksempel ikke å vite hvordan du gjengir dataene på nettet. Renderingskoden kan ta innspill fra sluttbrukeren, men passerer deretter den innmatningen til logikkoden for behandling. Hver del håndterer seg selv.

Dette resulterer i modulær kode, noe som gjør vedlikehold mye enklere. Og i fremtiden, hvis du noen gang trenger å omskrive all renderingskoden, kan du gjøre det uten å bekymre deg for hvordan dataene blir lagret eller logikken blir behandlet.

7. YAGNI

De “Du trenger ikke det” prinsipp er ideen om at du aldri skal kode for funksjonalitet som deg kan trenger i fremtiden. Sjansen er, du vil ikke trenger det, og det vil bli bortkastet tid - og ikke bare det, men det vil unødvendigvis øke kodens kompleksitet.

Du kan se dette som en spesifikk anvendelse av KISS-prinsippet og et svar på dem som tar DRY-prinsippet for alvor. Ofte uerfarne programmerere prøver å skrive den mest abstrakte og generiske koden som er mulig for å unngå WET-kode, men for mye abstraksjon ender opp i oppblåst umulig å vedlikeholde kode.

Trikset er å anvende DRY-prinsippet bare når du trenger det. Hvis du oppdager at stykker av kode skrives om og om igjen, så abstrakt dem - men aldri når du synes at Et stykke kode vil bli skrevet om og om igjen. Flere ganger enn ikke, vil det ikke være.

8. Unngå tidlig optimalisering

De ingen for tidlig optimeringsprinsipp ligner YAGNI-prinsippet. Forskjellen er at YAGNI adresserer tendensen til implementere atferd før de er nødvendige mens dette prinsippet adresserer tendensen til Fremskynde algoritmer før det er nødvendig.

Problemet med for tidlig optimalisering er at du aldri kan vite hvor et programs flaskehalser vil være før etter det faktum. Du kan selvsagt gjette, og noen ganger kan du til og med være riktig. Men oftere enn ikke, vil du kaste bort verdifull tid på å prøve å få fart på en funksjon som ikke er så sakte som du tror eller ikke blir kalt så ofte som du forventer.

Nå dine milepæler så enkelt som mulig, da profil koden din å identifisere sanne flaskehalser.

9. Refactor, Refactor, Refactor

En av de vanskeligste sannhetene å akseptere som en uerfaren programmør er det kode kommer sjelden ut akkurat første gang. Det kan føle akkurat når du implementerer den skinnende nye funksjonen, men når programmet ditt vokser i kompleksitet, kan fremtidige funksjoner hindres av hvordan du skrev den første.

Kodebaser utvikler seg kontinuerlig. Det er helt normalt å revidere, omskrive eller til og med omorganisere hele biter av kode - og ikke bare normalt, men sunt å gjøre det. Du vet mer om prosjektets behov nå enn når du gjorde på start, og du bør regelmessig bruke denne nylig oppnådde kunnskapen til å reflektere gammel kode.

Legg merke til at det ikke alltid må være en stor prosess. Ta en side fra Boy Scouts of America, som bor ved disse ordene: “La campingplassen renere enn du fant den.” Hvis du noen gang trenger å sjekke eller endre gammel kode, må du alltid rydde den opp og la den stå i en bedre tilstand.

10. Clean Code> Clever Code

Når du snakker om ren kode, forlater du ditt ego ved døren og glem å skrive smart kode. Du vet hva jeg snakker om: den typen kode som ser mer ut som en gåte enn en løsning, og eksisterer bare for å vise frem hvor smart du er. Sannheten er at ingen virkelig bryr seg.

Et eksempel på smart kode pakker så mye logikk inn i en linje som mulig. Et annet eksempel er å utnytte et språks vanskeligheter for å skrive merkelige, men funksjonelle utsagn. Alt som kan få noen til å si “Vent, hva?” når poring over koden din.

Gode ​​programmerere og lesbar kode går hånd i hånd. Legg igjen kommentarer når det er nødvendig. Følg stilguider, enten diktert av et språk (som Python) eller et selskap (som Google). Vær oppmerksom på per-språk-idiomer og slut på å skrive Java-kode i Python eller omvendt. Se vår artikkel om tips for å skrive renere kode 10 Tips for å skrive renere og bedre kode 10 Tips for å skrive renere og bedre kode Skrive ren kode ser enklere ut enn det egentlig er, men fordelene er verdt det. Slik kan du begynne å skrive renere kode i dag. Les mer .

Hva gjør en god programmerer?

Spør fem personer, og du får 10 forskjellige svar. For meg er en god programmerer en som forstår at kodingen i siste instans skal gi sluttbrukeren, hvem som er lett å jobbe med i et lag, og som fullfører prosjektene sine til spesifikasjon og til tiden.

Hvis du bare har begynt, ikke bekymre deg for mye om det ennå. Fokus på å lære å kode uten stress. Hvis du føler deg fast, kan du se vår artikkel om å overvinne programmeringsblokken. Og hvis du bare ikke er glad for å skrive kode, les vår artikkel om tegn du ikke er ment å være programmerer. 6 Tegn på at du ikke er ment å være programmerer. 6 Tegn på at du ikke er ment å være programmerer Ikke alle er kutt ut for å være programmerer. Hvis du ikke er helt sikker på at du er ment å være programmerer, er det noen tegn som kan vise deg i riktig retning. Les mer .

Hvordan ville du definere en god programmerer? Fikk noen tips for uerfarne programmerere som vil forbedre? Del med oss ​​ned i kommentarene nedenfor!

Utforsk mer om: Programmering.