Hvordan man er en god programmør

Hvad adskiller de rigtig gode programmører?

Som vi alle ved, bygger store programmører fantastiske funktioner, websteder, apps og lignende. Men hvad har de til fælles?

I min forskning handler det ikke kun om at kende et sprog rigtig godt eller have en særlig uddannelsesmæssig baggrund. Det er, at de virkelig talentfulde programmører har mestret det grundlæggende. Dette fundament er det, der gør dem i stand til at opbygge store ting og komme med banebrydende ideer.

Tænk på en pyramide. Den har en stor base, men bliver gradvist mindre og tyndere mod toppen. At lære det grundlæggende ved programmering af formularer, der baserer sig. Alt tager derfra.

Så hvad er disse grundlæggende? Baseret på min erfaring og de programmører, hvis baggrund jeg har undersøgt, ser jeg programmeringsfundamental som en todelt tilgang.

Ekstraordinær problemløsning

For det første skal du være en effektiv problemløsning. Dette er et vigtigt sted at starte, da programmering er problemløsning.

Selvom der er mange måder at løse et problem på, er der nogle få dele af processen, der skiller sig ud for mig. Programmører, der også er gode problemløsere, destillerer et problem til dets essens for at identificere deres overordnede mål og starte et problem med formål. Derefter opdeler de hvert problem i små, håndterbare dele - angriber hver del igen og nogle gange visuelt ved at tegne et billede for at gøre det til "den virkelige verden".

Processen er sværere, end den lyder. Da jeg begyndte at programmere, ramte jeg en mur: Som mange andre lærte jeg aldrig, hvordan jeg skulle løse problemer i skolen; det er en færdighed, der ikke let læres. Jeg fik et problem i matematikklassen og dykkede bare ind, hvilket jeg gjorde, da jeg begyndte at programmere. Ikke overraskende drejede jeg unødvendigt mine hjul og ramte vejspærringer på de enkleste problemer.

Ting begyndte at ændre sig, da jeg begyndte at lære om problemløsningsprocessen, og hvordan man effektivt kunne løse problemet. Jeg begynder nu et problem med hensigt. Jeg har George Polyas bog, How to Solve It , til at takke for den smule råd.

Jeg har tilpasset nogle af Polyas ideer til programmering, som at forstå problemet. ”Problemet skal forstås,” skriver Polya. Dette inkluderer at være i stand til at "påpege de vigtigste dele af problemet, det ukendte, dataene og tilstanden." For hvert problem trækker jeg et ark papir ud og skriver svar på disse spørgsmål: hvad løser jeg eller prøver jeg at finde? (ukendt); hvad får jeg? (data); og hvilke begrænsninger eller detaljer skal jeg være opmærksom på? (tilstand).

At forstå problemet kan synes åbenlyst, men det åbenlyse overses let. Ved mere end en lejlighed har jeg kun hældt timer på et problem for først at indse meget senere, at jeg savnede en lille, men kritisk detalje i problemstillingen. At skrive problemoplysninger bremser mig mentalt ned og hjælper mig med at tænke nøjagtigt over, hvad jeg skal gøre, hvilket er halvdelen af ​​kampen.

Derfra laver jeg en plan, som er et andet af Polyas forslag. Det giver mening. Jeg skriver en oversigt, før jeg skriver en artikel. En kunstner laver en skitse af maleriet, inden han arbejder på selve maleriet. En bygherre bruger tegninger og tegninger til at bygge et hus. Det er ikke anderledes med programmering. I stedet for at skynde mig at gøre , er jeg nødt til at starte med at tænke over, hvad jeg vil og lave en plan for angreb.

Der er mange måder at gøre dette på. Nogle gange skitserer jeg de trin, jeg skal tage i numerisk rækkefølge: først gør dette, andet gør det. Andre gange gør jeg problemet visuelt. Da jeg lærte om sløjfer, trak jeg en håndfuld mandler ud og fysisk itererede gennem bunken. Det er et fjollet eksempel, men det hjalp mig med at tænke igennem problemet.

Jeg tegner også billeder eller diagrammer. For et rekursivt problem tegner jeg et diagram over, hvad der sker på hvert rekursivt opkald, indtil jeg rammer basissagen. Næsten altid finder jeg dog en måde at forenkle problemet på for at gøre det mere håndterbart og hjælpe mig med at få øje på et mønster. Frem for alt er målet for mig at komme ind i et problem med formål og opretholde den følelse af formål hele vejen igennem.

På trods af de bedst lavede planer er problemer stadig hårde, og jeg sidder stadig fast. At blive en stor problemløser tager tid; det er en færdighed, jeg stadig arbejder på, og det er bestemt værd at gøre. Det er en forskel, du kan se.

Når jeg læser kode skrevet af en stor problemløser, er den ren og let at forstå. Variabler er godt navngivet. Funktionerne er korte og skarpe. Hver linje kode har et specifikt formål; fnuget fjernes. Kodens klarhed afspejler programmørens tankeproces: Jeg kan læse programmet fra top til bund og vide nøjagtigt, hvad der foregår. Det er fantastisk problemløsning, og det er det, jeg stræber efter.

Hvad med din computer?

At lære datalogi er det andet programmeringsgrundlag. Jeg begyndte for nylig at lære datalogi og elsker det, fordi jeg bevæger mig ud over overfladeniveau. Jeg går "bag kulisserne" for at lære, hvad der sker, når jeg f.eks. Bruger en indbygget funktion. Jeg lærer også om hukommelse og løbetid blandt mange andre emner. Kort sagt lærer jeg, hvorfor en computer gør de ting, den gør.

At kende “hvorfor” forbedrer min kontekstuelle viden og gør mig til en mere informeret programmør. Som et resultat er jeg mere tankevækkende med den kode, jeg skriver. Nu hvor jeg for eksempel ved lidt om kørselstid, vælger jeg at bruge en binær søgning i stedet for at gentage hvert element på en liste.

Det beriger også min forståelse af, hvordan centrale programmeringskoncepter fungerer. For eksempel arbejdede jeg på et rekursivt problem, og jeg fik ikke den løsning, jeg forventede. Efter tæt undersøgelse lærte jeg hvorfor: det havde at gøre med udførelsen af ​​opkaldsstakken, en idé, der ville have undsluppet mig for bare et par måneder siden.

Eller tage klasser. Jeg kæmpede uhyre med klasser i længst tid og var bange for at bruge en. Jeg vidste, hvordan jeg skrev en klasse, men var ikke sikker på, hvornår og hvorfor jeg ville bruge en. Det ændrede sig, da jeg lærte, hvad der faktisk sker på min computer, når jeg opretter forekomster og opkaldsmetoder. Det klikkede endelig, når jeg havde en eller anden kontekst. Til både rekursion og klasser brogede datalogi huller i min viden.

Alt for ofte bliver de grundlæggende skubbet til side. Fremskridt kan være langsomt, og folk har tendens til at vælge flere "sjove" ting at arbejde på, når de får mulighed for det. Det er en skam. Programmører, der mestrer det grundlæggende, ser ud til at kode med tillid: de kender "hvordan" og "hvorfor" i deres programmeringsvalg, hvilket forbedrer deres arbejde og bygger deres troværdighed over for andre.

Plus, en solid forståelse af det grundlæggende gør det lettere at lære nye sprog og teknologier. For eksempel at tage sig tid til virkelig at forstå kernebegreber som iteration, rekursion og abstraktion med et sprog vil hjælpe, når man lærer et andet. Kort sagt, der er meget at vinde og lidt at tabe ved at mestre det grundlæggende.

Jeg er en forfatter (amymhaddad.com) og en begynderprogrammerer.