Michael Fisher
0 
2266
204
Alle kan skrive kode. Men god kode? Det er her, det bliver hårdt.
Vi har alle hørt skrækhistorier om spaghettikode, massive hvis-ellers kæder, hele programmer, der kan bryde bare ved at ændre en variabel, funktioner, der ser ud som om de blev tilsløret osv. Det er hvad der sker, når du prøver at fremstille et produkt, der kan sendes med kun et semester med programmeringserfaring under dit bælte.
Du må ikke nøjes med at skrive kode der arbejder. Formålet med at skrive kode, der kan opretholdes - ikke kun af dig selv, men af alle andre, der muligvis ender med at arbejde på softwaren på et tidspunkt i fremtiden. Med henblik herpå er her flere principper, der hjælper dig med at rydde op i din handling.
1. KISS
Det “hold det enkelt, dumt” princip gælder stort set hele livet, men det er især nødvendigt i mellemstore til store programmeringsprojekter.
Det starter i starten, når du definerer omfanget af det, du vil oprette. Bare fordi du brænder for spiludvikling, betyder det ikke, at du kan oprette det næste World of Warcraft eller Grand Theft Auto. Når du tror, at du har forenklet dig nok, skal du forenkle det et niveau yderligere - funktionskryp er uundgåelig, så start i det små.
Men selv efter kodning er begyndt, skal du holde det enkelt. Kompleks kode tager længere tid at designe og skrive, er mere tilbøjelig til fejl og fejl og er sværere at ændre senere ned ad vejen. Med de kloge ord fra Antoine de Saint-Exupery, “Perfektion opnås, ikke når der ikke er noget mere at tilføje, men når der ikke er noget tilbage at tage væk.”
2. TØRR
Det “gentag ikke dig selv” princip er afgørende for ren og let at ændre kode. Når du skriver kode, ønsker du at undgå duplikation af data og duplikering af logik. Hvis du bemærker, at det samme stykke kode bliver skrevet igen og igen, bryder du dette princip.
Det modsatte af DRY-kode er WET-kode: “skriv alt to gange” (eller “spild alles tid”). En af de bedste måder at diagnosticere WET-kode er at spørge dig selv: For at ændre programmets adfærd på en eller anden måde, hvor mange kodeksområder ville du have brug for at ændre?
Antag, at du skriver en podcast-katalogapp. På søgesiden har du kode til hentning af en podcast's detaljer. På podcast-siden har du kode til at hente podcastens detaljer. På favorittsiden er den samme hentningskode. Overvej at abstrahere alt dette til en funktion, så hvis du har brug for at redigere det senere, kan du gøre det hele på ét sted.
3. Åben / lukket
Uanset om du skriver objekter Hvad er objektorienteret programmering? Det grundlæggende forklaret i Laymans vilkår Hvad er objektorienteret programmering? Det grundlæggende forklaret i Laymans vilkår De fleste moderne programmeringssprog understøtter "objektorienteret programmering" (OOP) paradigme. Men hvad er OOP nøjagtigt, og hvorfor er det så nyttigt? i Java eller moduler i Python, skal du sigte mod at lave din kode åben for udvidelse, men lukket for ændring. Dette gælder for alle slags projekter, men er især vigtigt, når du frigiver et bibliotek eller rammer beregnet til andre at bruge.
Antag f.eks., At du opretholder en GUI-ramme. Du kan frigive den som den er og forvente, at slutbrugerne direkte ændrer og integrerer din frigivne kode. Men hvad sker der, når du frigiver en større opdatering fire måneder senere? Hvordan implementerer de alle dine tilføjelser uden at smide alt det arbejde, de har gjort, væk?
Slip i stedet kode der forhindrer direkte ændring og tilskynder udvidelse. Dette adskiller kerneopførsel og ændret adfærd. Fordelene? Større stabilitet (brugere kan ikke ved et uheld bryde kerneadfærd) og større vedligeholdelighed (brugere bekymrer sig kun om udvidet kode). Det åbne / lukkede princip er nøglen til at skabe et godt API Hvad er API'er, og hvordan ændrer åbne API'er Internettet Hvad er API'er, og hvordan ændrer åbne API'er Internet Har du nogensinde spekuleret på, hvordan programmer på din computer og de websteder, du besøger "tale med hinanden? .
4. Sammensætning> Arv
Det “sammensætning over arv” princip siger, at objekter med kompleks opførsel skal gøre det ved at indeholde forekomster af objekter med individuel adfærd i stedet for at arve en klasse og tilføje ny adfærd.
Overtiltro til arv kan føre til to hovedspørgsmål. For det første kan arvehierarkiet blive rodet med et øjeblik. For det andet har du mindre fleksibilitet til at definere adfærd i specielle tilfælde, især når du vil implementere adfærd fra en arvegren i en anden arvegren:
Komposition er meget renere at skrive, lettere at vedligeholde og giver mulighed for næsten uendelig fleksibilitet, hvad angår hvilke former for opførsel, du kan definere. Hver individuel adfærd er sin egen klasse, og du skaber kompleks adfærd ved at kombinere individuel adfærd.
5. Enkeltansvar
Det princip om enkelt ansvar siger, at hver klasse eller modul i et program kun skal beskæftige sig med at levere en smule specifik funktionalitet. Som Robert C. Martin udtrykker det, “En klasse skal kun have en grund til at ændre sig.”
Klasser og moduler starter ofte på denne måde, men når du tilføjer funktioner og ny adfærd, er det let for dem at udvikle sig til Gudsklasser og Gud-moduler, der optager hundreder eller endda tusinder af kodelinjer. På dette tidspunkt skal du opdele dem i mindre klasser og moduler.
6. Adskillelse af bekymringer
Det adskillelse af bekymringsprincippet er som princippet om enkeltansvar, men på et mere abstrakt niveau. I bund og grund skal et program designes, så det har mange forskellige ikke-overlappende indkapslinger, og disse indkapsler bør ikke vide om hinanden.
Et velkendt eksempel på dette er model-view-controller (MVC) -paradigmet, der adskiller et program i tre forskellige områder: dataene (“model”), logikken (“controller”), og hvad slutbrugeren ser (“udsigt”). Variationer af MVC er almindelige i dagens mest populære webrammer.
Billedkredit: Wikimedia
F.eks. Behøver koden, der håndterer indlæsning og lagring af data til en database, ikke at vide, hvordan man gengiver disse data på Internettet. Gengivelseskoden kan indtaste input fra slutbrugeren, men videresender derefter dette input til den logiske kode til behandling. Hver del håndterer sig selv.
Dette resulterer i modulær kode, der gør vedligeholdelse meget lettere. Og i fremtiden, hvis du nogensinde har brug for at omskrive al renderingskoden, kan du gøre det uden at bekymre dig om, hvordan dataene gemmes, eller logikken behandles.
7. YAGNI
Det “du har ikke brug for det” princip er ideen om, at du aldrig skal kode for funktionalitet, som du kan behov i fremtiden. Det er chancerne for dig vil ikke har brug for det, og det vil være spild af tid - og ikke kun det, men det vil unødvendigt øge din kodes kompleksitet.
Du kan se dette som en specifik anvendelse af KISS-princippet og et svar til dem, der tager DRY-princippet for alvorligt. Ofte prøver uerfarne programmerere at skrive den mest abstrakte og generiske kode muligt for at undgå WET-kode, men for meget abstraktion ender i oppustet umulig at vedligeholde kode.
Kunsten er at anvende DRY-princippet kun, når du har brug for det. Hvis du bemærker, at kodestykker bliver skrevet om og om igen, abstraher dem - men aldrig når du tænke et stykke kode vil blive skrevet om og om igen. Flere gange end ikke, vil det ikke være.
8. Undgå for tidlig optimering
Det intet for tidligt optimeringsprincip svarer til YAGNI-princippet. Forskellen er, at YAGNI adresserer tendensen til implementere adfærd før de er nødvendige, mens dette princip adresserer tendensen til fremskynde algoritmer før det er nødvendigt.
Problemet med for tidlig optimering er, at du aldrig rigtig kan vide, hvor et programs flaskehalse vil være, før efter faktum. Du kan selvfølgelig gætte, og nogle gange har du endda ret. Men oftere end ikke spilder du værdifuld tid på at prøve at fremskynde en funktion, der ikke er så langsom, som du tror eller ikke bliver kaldt så ofte, som du ville forvente.
Nå dine milepæle så simpelt som du kan profil din kode at identificere ægte flaskehalse.
9. Refactor, Refactor, Refactor
En af de sværeste sandheder at acceptere som uerfaren programmør er kode kommer sjældent ud rigtigt første gang. Det må føle lige når du implementerer den skinnende nye funktion, men når dit program vokser i kompleksitet, kan fremtidige funktioner blive hindret af, hvordan du skrev den tidlige.
Kodebaser er i konstant udvikling. Det er helt normalt at revidere, omskrive eller endda redesigne hele kodestykker - og ikke bare normalt, men sundt at gøre det. Du ved mere om dit projekts behov nu end da du gjorde det ved Start, og du bør regelmæssigt bruge denne nyligt opnåede viden til at refaktorere gammel kode.
Bemærk, at det ikke altid behøver at være en stor proces. Tag en side fra Boy Scouts of America, der lever efter disse ord: “Lad campingpladsen være renere, end du fandt den.” Hvis du nogensinde har brug for at kontrollere eller ændre gammel kode, skal du altid rense den op og lade den være i bedre stand.
10. Rens kode> Smart kode
Apropos ren kode, lad dit ego stå ved døren og glemme at skrive smart kode. Du ved, hvad jeg taler om: den slags kode, der ligner en gåte end en løsning og kun findes for at vise, hvor smart du er. Sandheden er, at ingen virkelig bryder sig.
Et eksempel på smart kode er at pakke så meget logik på en linje som muligt. Et andet eksempel er at udnytte et sprogs forviklinger til at skrive underlige, men funktionelle udsagn. Alt, der kan få nogen til at sige “Vent, hvad?” når du porer over din kode.
Gode programmerere og læsbar kode går hånd i hånd. Efterlad kommentarer, når det er nødvendigt. Overhold stilguider, hvad enten det er dikteret af et sprog (som Python) eller et firma (som Google). Iagttag idiomer per sprog, og stop med at skrive Java-kode i Python eller omvendt. Se vores artikel om tip til skrivning af renere kode 10 tip til skrivning af renere og bedre kode 10 tip til skrivning af renere og bedre kode At skrive ren kode ser lettere ud, end det faktisk er, men fordelene er det værd. Her er, hvordan du kan begynde at skrive renere kode i dag. .
Hvad der gør en god programmør?
Spørg fem personer, så får du 10 forskellige svar. For mig er en god programmør en, der forstår, at kodning i sidste ende skal tjene slutbrugeren, som er let at arbejde med i et team, og som afslutter sine projekter til specifikation og til tiden.
Hvis du føler dig sidder fast, kan du se vores artikel om at overvinde programmerers blok. Og hvis du bare ikke er glad for at skrive kode, skal du læse vores artikel om tegn, du ikke er beregnet til at være programmør.
Hvis du lige er startet, skal du fokusere på at lære at kode uden stress. Er du ikke sikker på, hvilket programmeringssprog du først skal dykke på? C # er et godt sted at begynde af praktiske grunde 7 Praktiske grunde til at lære C # Programmering 7 Praktiske grunde til at lære C # Programmering Der er mange programmeringssprog, så hvilken skal du vælge et at lære? Her er flere grunde til at lære C #. . Og hvis du vælger det, skal du også overveje disse C-programmeringstips 5 C-programmeringstip, du skal lære at komme i gang 5 C-programmeringstip, du skal lære at komme i gang. C-programmeringssprog har et hårdt omdømme. Men hvis du får fat på det, kan du programmere hvad som helst, som disse tip viser. .