12 tip og tricks til at lære at kode (fordi 10 var for kort)

1 - Lær det sprog, du kan lide, ikke det, der er øjeblikket

Det er den gyldne regel: lær, mens du har det sjovt eller i det mindste kan lide det, du laver. Fokuser ikke på øjeblikket. Hvis det slukker for dig, kommer du ikke nogen steder. Desuden udvikler dette felt sig så hurtigt. Javascript, for eksempel, blev især diskrediteret, før HTML5 blev nævnt og blev en af ​​søjlerne på nettet. Det vigtige er, at det sprog, du vælger, stimulerer din nysgerrighed og dit ønske om at lære. Det er også mere interessant at have udviklere med flere facetter end nøjagtigt lignende profiler. Derudover finder du altid en løsning for at nå dine mål. F.eks. Har PHP - MySQL-parret altid udsat mig for databasesektoren. Dette forhindrede mig ikke i at overvinde det ved at have det sjovt med sprog og metasprog som Rebol (nu rød), Python og XML.

2 - Find et projekt, som du brænder for, og gennemfør det med succes

Den største mangel ved nogle manualer eller kodeuddannelse er manglen på konkrete sager. Du undervises i kommandoerne en efter en, men bindemidlet er næsten fraværende. Det er som at lære ord, sætninger uden nogensinde at have en samtale. For eksempel fik jeg en klap i ansigtet, første gang jeg virkelig kom til England i et stykke tid. Intet at gøre med skolens engelsk. Heldigvis tog det ikke lang tid at tilpasse mig og fordybe mig i det store sproglige bad. Det store mål er derfor et projekt, der fascinerer dig, som du vil finde tid og energi til at tænke, udvikle, måske og sikkert knække dine tænder for. Det betyder ikke noget, om denne type software allerede findes. Det er altid mere interessant at gøre det selv. Reager på et behov, et ønske. Byg f.eks. Et værktøj til at supplere en anden af ​​dine lidenskaber. Vær kreativ.

3 - De-dramatisering

Du lærer et nyt sprog. Forestil dig dig selv i et fremmed land, hvor du kun kender et par ord, og hvor computeren er din eneste samtalepartner. Du beder ham om saltet. Han svarer dig, at han ikke forstår. Du spørger ham igen på en anden måde. Han bringer dig sukkeret. Intet seriøst. Bare et forståelsesproblem. Dit liv står ikke på spil i øjeblikket, og computeren vil ikke fjerne din digitale kopi med en stor rød blyantlinje eller eksplodere efter at have vist en stor blinkende "syntaksfejl".

4 - Trin for trin og gør lidt hver dag

10 minutter om dagen eller 5 timer hver anden uge gør dig ikke til en udvikler. Det er bedre at lære og øve lidt hver dag. God regelmæssighed gør det lettere for dig at huske. Sigt heller ikke for højt fra starten. Du kunne blive skuffet. Inden for programmering af computere er det let at forestille sig at blive tosproget natten over. Dette kræver lidt mere tålmodighed, men din indsats vil altid blive belønnet.

5 - At vide, hvordan man pauser

Nogle gange er det nødvendigt at vide, hvordan man midlertidigt opgiver, hvad man laver, for at vende tilbage til det bedre. At sidde fast foran computeren giver dig ikke inspiration. Du vil være endnu mere tabt. Når jeg ikke forstår noget mere, går jeg meget ofte væk fra computeren, tager et ark papir og prøver at udtrykke mine tanker på en enkel måde. Dette tillader mig at se mere tydeligt og finde det sted, hvor jeg gik tabt i koden. Du er velkommen til at gå videre til noget andet, noget helt andet. Løsningen af ​​et stykke kode, der torturerede mit sind, har for nylig vist mig, mens jeg shoppede, en pakke nudler i hånden ... Når du løsriver dig fra en aktivitet, frigiver du hjernen, som derefter "ubevidst" kan udforske flere alternative stier . Bevæg dig, gå, ventiler sindet, slap af foran en god bog, tegneserie eller videospil, og der er en god chance for, at alt bliver klart, og at du vil udtrykke dig selv "Jævla det, det er selvfølgelig!".

6 - Kommenter, syntese

Kommentar til koden bliver hurtigt vigtig. På den ene side at forklare, hvad du laver (især vigtigt, når du lige er startet), og på den anden side som en påmindelse. Når du hopper fra et projekt til et andet eller henter et stykke kode seks måneder senere, er det vigtigt at være i stand til hurtigt at finde vej rundt. Det ville være en skam at spilde tid på at undre sig over, hvordan programmet fungerer. Tilsvarende kan det ske med dig af x grunde til ikke at kode naturligt, men at bruge en subterfuge, en bagdør. Seks måneder senere vil du sandsynligvis undre dig over, hvorfor du ikke kodede denne eller den anden funktion på den traditionelle måde. Hvad du vil gøre straks, inden du indser din fejl og "hvorfor, hvordan", du handlede anderledes.

7 - Noter og syntese din viden

Papir eller digitale lærebøger, onlinekurser er meget praktiske, men svarer ikke nødvendigvis til din måde at lære på. Derudover er forklaringerne undertiden ordrette, og du er kun interesseret i et lille stykke tekst, f.eks. En syntaks af en kommando. Lav dig selv et resumédokument, hvorfor ikke i form af et tankekort. Når du mangler information, behøver du ikke at dykke ned i manualen. Et enkelt blik på din syntese giver dig mulighed for at finde de vigtige oplysninger. Det giver dig også mulighed for at udfylde de manglende oplysninger eller give eksempler, der synes mere tydelige for dig end i manualen.

8 - Test og eksperiment

Manualer har ikke altid svaret på alt, og nogle gange er det problem, du støder på, ikke dokumenteret. Jeg tager ofte eksemplet med labyrinten i træning. Du sidder ikke fast i slutningen af ​​en gyde. Du går tilbage til dine trin for at teste den næste sti, indtil du finder udgangen. I koden er det samme. Hvis det ikke fungerer med metode A, er måske metode B den rigtige, eller metode C eller metode D eller metode E ... Du mister ikke noget for at prøve. Nogle gange er det endnu bedre at isolere en kommando, teste den uden for dit program for at kontrollere, at du har forstået, hvordan det fungerer, og at det opfylder dine behov nøjagtigt.

For nylig kiggede jeg for eksempel på en kommando i en manual til at slette et specifikt tegn fra en streng, såsom at fjerne kommaer fra en sætning. Dog ønskede jeg at fjerne al tegnsætning, og manualen angav ikke, hvordan man fjerner flere tegn på samme tid. Jeg kunne have gentaget den samme kommandokarakter efter karakter, men det virkede lidt trættende for mig. Jeg tilføjede simpelthen andre karakterer mellem anførselstegnene, der angav den, der skulle slettes, og miraklet var. Jeg kunne have spildt min tid på at søge på Internettet eller sidde fast. En simpel test gjorde det muligt for mig at komme videre.

9 - Sikkerhedskopier regelmæssigt, og brug versionering

Regelmæssig backup skal være en naturlig refleks. Ingen er immun mod tekniske problemer eller håndteringsfejl. Og farvel koden, der er indtastet i lange, feberlige minutter… Gem regelmæssigt, og tøv ikke med at oprette flere filer, der hver har et versionnummer. Dette giver dig mulighed for at føre en historie med dine fremskridt og lettere at identificere fejl. Hvis version 0.43 af din kode fungerede perfekt, er der ingen tvivl om, at fejlene skyldes, hvad du tilføjede til version 0.44.

I konvention kaldes versioner med decimaler som "mindre", dvs. ændringerne, der er foretaget til dem, er ikke signifikante. Versioner med et helt antal kaldes større, fordi de betragtes som funktionelle og bringer en reel innovation i udviklingen. Hvis jeg sammenligner det med vandreture, viser versionerne 0.43 og 0.76, at du gør fremskridt på vejen, angiver version 1.0 at du har nået dit første stop, den syngende ugns tilflugt på Big Thunder Mountain. Version 1.0 er lidt speciel, fordi det er den første virkelig funktionelle version.

For eksempel koder jeg i øjeblikket en tekstanalysator i Rødt for sjov og jeg er i version 0.56, hvilket betyder, at mit program kører korrekt, men det er endnu ikke funktionelt for offentligheden, og at der stadig er store forbedringer, der skal foretages.

Du kan bruge onlinetjenester som Git (og Framagit for franske læsere) til at gemme din kode og være i stand til at spore historikken lettere, men for at komme i gang er det muligvis ikke nødvendigt.

10 - Forenkle, optimer din kode

Din kode fungerer perfekt? Smuk! Smuk! Men arbejdet er ikke færdig. Det er tid til at forenkle og optimere programmet. Forenkle ved at kontrollere, om der ikke er nogen mulighed for at have en mere kortfattet kode eller bruge hurtigere metoder. For eksempel kan nogle ordrer kombineres til en. Forenklet og optimeret kode er mere elegant, lettere at læse og frem for alt fungerer hurtigere. Dette betyder mindre brugt maskintid, mindre energiforbrug.

Optimering, gevinst i hastighed og ressourcer betyder også at pleje ældre udstyr. Hvad er poenget med dit program, hvis du altid har brug for den nyeste computer til at køre det? Brugere er mere tilbøjelige til at henvende sig til økonomiske løsninger, og din bekymring for optimering viser din dygtighed og alvor i koden.

Optimering betyder også at pleje brugeren og mulige fejl. Vi forsøger derefter at sætte os selv i sidstnævnte sko og liste over de problemer, han eller hun kan støde på. Du er velkommen til at teste dit program sammen med andre. Når du har din næse i styret, er det ofte vanskeligt at få øje på dine fejl.

Et eksempel på en fejl? Mange onlineformularer gennemgår indtastningen under indtastning og viser en fejlmeddelelse i rødt lidt for systematisk. Når du indtaster en e-mail-adresse og ser meddelelsen "ugyldig e-mail-adresse" vises, kan du have spørgsmål. Faktisk så længe hele adressen ikke er indtastet, er den nødvendigvis ugyldig. En informeret bruger vil vide, hvad det handler om. Andre blokeres. Den enkle løsning er at kontrollere indtastningen, når brugeren validerer formularen og ikke når han skriver. Designfejl, fejl fra udviklere, der ikke har lagt sig selv i brugerens sko….

11 - Sammenlign, undersøge andres kode

Vi lærer ved at observere. At observere er ikke at kopiere, at tage kodestykker tilbage uden virkelig at vide, hvad det er til. At observere er at undersøge, analysere, prøve at forstå metoden for denne eller den anden udvikler og derefter finde sin egen metode. Når det er muligt, er du velkommen til at se på andres arbejde og komme med dine egne løsninger.

12 - Stil spørgsmål

Der er specialiserede fora, sider fulde af artikler. Det problem, du arbejder med, kan muligvis ikke finde dets svar med det samme, men chancen for, at du ikke er den eneste i dit tilfælde, eller at et andet problem nærmer sig det. Efter at have undersøgt, dokumenteret dit problem, er du velkommen til at stille spørgsmålet på et forum ikke uden klart at forklare situationen, der blokerer for dig. Et "Det fungerer ikke" løser aldrig noget.