Hvordan man nærmer sig et nyt programmeringsbibliotek (frygtløst)

I din programmeringsrejse har du flere muligheder for at implementere nye rammer, biblioteker og API'er. Uanset om du lærer dem i et klassemiljø, på jobbet eller på egen hånd, vil det bestemt påvirke processen, men det skal ikke skræmme dig væk fra at prøve noget nyt. Nedenfor er en enkel oversigt over, hvordan du nærmer dig et nyt bibliotek på egen hånd. Jeg bruger React Native som et eksempel, men disse trin er enkle nok til at blive anvendt på ethvert bibliotek efter eget valg.

Hvad er et bibliotek?

Et bibliotek er et katalog med kode, der indeholder funktioner, du kan ringe til for at håndtere almindelige opgaver. For eksempel har programmeringssprog (f.eks. JavaScript) normalt biblioteker (JQuery) til alle mulige opgaver, såsom databehandling, plottning af grafer, tekstpersporing osv.

På den anden side er en ramme en generisk struktur, der tilvejebringer en skeletarkitektur, som specifik software kan implementeres med. Strukturen giver mulighed for genanvendelige, omfattende mønstre, der kan anvendes i hele applikationen for at løse problemer.

Et API, der ofte (forkert) bruges synonymt med udtrykket bibliotek og / eller rammer, står for Application Programming Interface og består af funktionerne / metoderne i et bibliotek, som du kan ringe til for at bede det om at gøre ting for dig - grænsefladen til bibliotek.

React and React Native betegnes normalt biblioteker, men der er fremført argumenter for at kategorisere dem som rammer.

Hvor skal man starte?

Først skal du bestemme, hvad du bygger. Har du en opgave eller slutmål i tankerne? Lager du noget bare for at øve kodning? Hvad vil du have, at din app skal gøre mod hvad har du brug for?

Jeg besluttede at dykke ned i et nyt bibliotek i løbet af en 4-dages hackathon. Jeg vidste, at jeg ville oprette en mobilapp, og selvom jeg var interesseret i en ny udfordring, havde jeg ikke tid til at vove sig for langt uden for min komfortzone. Derfor er det bydende nødvendigt at se på det aktuelle arbejde og derefter overveje, hvor lang tid du har til at færdiggøre dit minimums levedygtige produkt med de færdigheder, du allerede har. Derefter trækkes 1-2 dage til læring og fejlsøgning. Det er den tidsramme, du vil arbejde med. Nu, hvis du har mere end 4 dage, opfordrer jeg dig absolut til at prøve noget lidt mere udfordrende.

Før du bygger

Når det kommer til programmering, er Google din bedste ven og din værste fjende. Dette gøres endnu mere klart, når man tager ud i nyt biblioteksland.

Selv om der muligvis er mange svar på dine specifikke spørgsmål (dvs. hvad betyder "React Native Module ikke kan findes"?) På websteder som Stack Overflow og Github, er oplysninger, der er ældre end et par måneder, faktisk ikke nyttige. Da ting har tendens til at gå med teknologi, opdateres biblioteker ofte, og hele rammer kan endda blive udskrevet med et øjeblik.

Således, hvis dit bibliotek har officiel dokumentation, find det, læse det, bogmærke det og henvis til det ofte. Selv hvis du ikke er vild med, hvordan den er organiseret, vil det sandsynligvis være din reddende nåde.

Uddraget ovenfor er for eksempel hentet direkte fra React Native-dokumenter. Selvom det ved første øjekast ligner React, er noget ved en nærmere undersøgelse meget anderledes. Først: det ligner ikke helt JSX, gør det ikke? Der er ingen div-tags. Hvad er disse visnings- og tekstmærker, og er det en form for inline styling? Er CSS inde i komponenten? Er det endda CSS?

Så selvom du muligvis forstår kernen i denne kode og den grundlæggende arkitektur, er der en masse syntaktiske spørgsmål, der opstår i et lille uddrag. Heldigvis gør dokumenterne et meget godt stykke arbejde med at besvare disse spørgsmål.

Dette er dog bare at ridse overfladen på hvilke spørgsmål, der måtte opstå, især når det kommer til fejlfinding. Apropos…

Hvordan fejler du fejl?

Før du overvejer at røre ved din teksteditor, skal du finde ud af, hvordan du vil logge på konsollen, og hvor du vil være i stand til at se disse logfiler.

I eksemplet med React Native kan du muligvis starte med Facebooks værktøj til Create React Native App. Dette installerer og konfigurerer React Native's nuværende build-afhængigheder og bundter dem sammen med Expo (en app, der leverer en mobil emulator på din computer / simulator på din mobile enhed samt dens egne oprindelige afhængigheder). Så længe du forbliver i CRNA / Expo-miljøet, vises din console.log () i din terminal.

På den anden side, hvis du vælger at bruge andre oprindelige afhængigheder, bliver du nødt til at skubbe din app ud. Fremadrettet vises dine logfiler i dit Xcode-arbejdsområde og vil sandsynligvis være lidt sværere at læse.

Overvej et par flere ting, når du undersøger fejlsøgning og logning:

  1. Kan du bruge console.log () eller foretrækker biblioteket en anden funktion / syntaks?
  2. Er du foran eller bagenden (dette vil sandsynligvis påvirke, hvor dine logfiler vises)?
  3. Har din app endda en backend (eller frontend)?

Byg noget - ikke din app

Dette er det trin, du vil springe over. Dette er det trin, jeg sprang over. Venligst ikke. Selvom det kan virke som spild af tid i starten, vil det spare dig for en masse sorg og kræfter senere.

Opret en simpel CRUD (Opret, læst, opdater, slet) todo-app. Hvis du bruger et bredt tilgængeligt bibliotek, er chancerne for, at du kan finde en tutorial, der leder dig gennem strømmen. Dette trin hjælper dig med at blive komfortabel med bibliotekets grundlæggende funktioner og hvordan du forbinder det til din tilstand. Det vil også give dig en enkel model at henvise til på din maskine. Selv hvis du ikke kan finde en omfattende tutorial, skal du være i stand til at finde, hvordan man bygger en app, der udfører disse fire funktioner gennem en vis kollektiv forskning.

Hvorfor insisterer jeg på, at du gør dette vs at læse artikler eller kigge på codebases? Tænk tilbage på, da du først lærte at kode. Så meget af læring absorberes gennem vores muskelhukommelse, herunder forståelse af arbejdsgangen, og det kan være vanskeligt at forstå ved blot at kigge efter en kodebase. Hvis du først opretter din egen mini-app, går du ikke ind i din planlagte app blind eller uorganiseret. Det vil være meget lettere med en guide og lidt selvtillid. For ikke at nævne, din mini-app har al den grundlæggende funktionalitet til at fungere som et skelet til dit mere komplekse projekt. Nu kan du fokusere på raffinering og refactoring i modsætning til at sidde fast på grundlæggende logik.

Begynd med at bygge din app

Hold din guide og dine dokumenter åbne til reference. Du har dette!