Hvordan man bliver programmør: 8 trin til at bygge en app fra bunden

Intro

“Hvad er den bedste måde at lære at kode på?”

“Hvordan man bliver programmør”

“Hvordan man bygger en app”

Dette er almindelige spørgsmål, der stilles hver dag af begyndere, der er ivrige efter at lære at kode. Du har uden tvivl allerede googlet noget i den retning og læst nok artikler/svar til det punkt, hvor du er træt af de “standardiserede” råd.

Hvis du ikke har, eller hvis du på en eller anden måde tror, at jeg har noget nyt at sige og gerne vil høre det alligevel (det vil jeg ikke), så er her et kort og temmelig meningsløst svar (jeg skal give det et SEO-venligt click-bait navn: “3 trin til at blive programmør”):

Strin 1: Vælg et sprog

Strin 2: Lær sproget

Strin 3: Byg ting og bliv ved med at lære

Hey, lad være med at kaste med sko efter mig. Hvor meget jeg end gerne vil sige, at der er en one-size fits all-metode til at lære at kode, så er der virkelig ikke. (Lad mig tilføje et trin 0: accepter, at alle lærer forskelligt).

Der findes allerede utallige mere detaljerede svar, der uddyber trin 1 & 2 på nettet, men det almindelige svar på trin 1 er at lære Python eller Ruby som dit første sprog (lad være med at hænge dig for meget op på sproget, så kommer du aldrig i gang). Hvis du har brug for læringsressourcer, har vi kurateret flere guides, som du kan tjekke ud:

• Lær Python
• Lær Ruby on Rails
• Lær JavaScript (Lær altid JavaScript før du lærer frameworks som AngularJS eller React )
• Lær iOS-udvikling
• Lær Android-udvikling

Flere af jer vil komme til dette punkt:

Hvis du har det øjeblik, hvor du er blevet et fortabt får, skal du ikke flippe ud, for du er ikke alene.

Så godt som hver gang du spørger “hvordan bliver jeg programmør”, vil udviklere fortælle dig, at du skal bygge ting, da det er ved at bygge ting, at du kan forbedre dig som programmør, og det er den bedste måde at lære det på osv. osv. osv.

Du kan altid følge eksisterende tutorials om, hvordan du bygger en Twitter/Pinterest/Instagram/etc-klon med det sprog & teknologi, du bruger, men husk på, at forfatterne af disse tutorials faktisk har gjort det meste af arbejdet for dig, og det eneste, du gør, er at forstå koden og deres logik.

Denne artikel vil forsøge at give dig en oversigt, som du kan følge, når du bygger din egen app fra bunden.

Forudsætninger

De fleste apps vil have brug for en database, så hvis du selv skal bygge din egen app (ergo front- og backend), skal du sandsynligvis kende et databaseforespørgselssprog (normalt SQL). Medmindre du bygger noget, der ikke har brug for at interagere med en database som f.eks. Flappy Bird.

Hvis du vil bygge en web-app, skal du desuden have kendskab til grundlæggende DevOps for at kunne opsætte dit udviklingsmiljø/din server og for rent faktisk at kunne lancere appen.

Hvis du kun sigter mod at blive en webudvikler i front-end, kan du finpudse dine HTML-, CSS- og JavaScript-færdigheder på Codepen eller JSfiddle. Hvis du kun kan JavaScript og ikke ønsker at lære et andet sprog, kan du prøve Node.js, da det er en JavaScript-platform til backend-udvikling (Du kan også bruge MongoDB som din database, da den også er baseret på JavaScript.)

Så bør du også kunne et af følgende sprog (og normalt en webramme), hvis du har til hensigt at bygge en komplet webapp:

• Ruby
• Python
• PHP
• Java

Go

• C#

Hvis du vil bygge spil, kan du overveje at lære Lua, selvom C# også er et rigtig godt valg takket være Unity 3D-spilmotoren og dens massive fællesskab. Hvad angår native udvikling af mobilapps, skal du kunne Swift/Objective-C til iOS-udvikling og Java til Android-udvikling.

Så lad os uden videre komme til, hvordan du bygger en app fra bunden.

Trin 0: Forstå dig selv

Først og fremmest skal du bygge noget, som du brænder for. Interesse er den bedste måde at holde dig selv motiveret på, så spørg dig selv, hvad du interesserer dig for, eller hvad du kan lide at lave.

For eksempel:

• Hvilke apps nyder du mest at bruge?
• Hvilke apps kan du ikke leve uden?
• Kan du lide at spille spil?
• Kan du lide at designe ting?
• Etc.

Identificer dine interesser, så du arbejder med noget, du vil have det sjovt med. På den måde er du mindre tilbøjelig til at gå i stå og give op halvvejs.

Trin 1: Vælg en idé

Nu, hvor du forhåbentlig har fundet ud af dig selv, er det tid til at vælge en idé at bygge. Start simpelt.

Ja… selv hvis du tænker på at bygge et spil, bør du lige nu ikke tænke på at bygge det næste CounterStrike, men i stedet tænke på, hvordan du kan bygge spil så simple som det berygtede Flappy Bird. Hey, du skal ikke se ned på Flappy Bird – det var en sensation, der fik folk over hele verden til at opdage deres indre masochist. Men jeg er lidt afvigende.

Så, baseret på dine interesser, skal du finde på en idé til en simpel app, der kan gøre noget smart. Det er ligegyldigt, om appen allerede findes (det kan faktisk hjælpe dig, hvis der allerede findes lignende projekter).

Her er nogle tips, der kan hjælpe dig med at få noget inspiration:

• Hvis du kan lide at lave mad, kan du måske tænke på at bygge en app, så folk kan vise deres hjemmelavede opskrifter frem.
• Hvis du altid har villet vide, hvordan Twitter fungerer, kan du prøve at bygge en super simpel Twitter-klon.
• Hvis du er en glemsom person, der er afhængig af opgavestyrere, kan du prøve at bygge en selv.
• Hvis du er afhængig af League of Legends, kan du prøve at kigge Riots API igennem og bygge et websted, der kan indhente & vise spiloplysninger.
• Hvis du kan lide at spille kortspil, kan du prøve at bygge et simpelt spil (f.eks. Black Jack)
• Hvis du er på slankekur, kan du prøve at bygge en app, der kan logge dit kalorieindtag.

Og så videre, og så videre, og så videre. Her er en liste over projektidéer, hvis du har brug for mere inspiration.

Når du har en retning, skal du skrive formålet og eventuelt de vigtigste målbrugere for denne app ned i én sætning.

For eksempel: Trin 2: Definer kernefunktionaliteterne

Tænk over, hvad din app skal kunne gøre, og opstil en liste over dem. Hvis du ender med at liste en masse ting op, skal du kigge bedre efter og spørge dig selv, om denne app VIRKELIG har brug for, for eksempel, Facebook-login for at fungere? Har den VIRKELIG brug for at uploade data til en eller anden sky for at virke?

Det er dejligt at have et drømmeprojekt med fede specifikationer, men lige nu handler det ikke om at bygge noget, der er komplet med en masse fede funktioner. Husk på, at ingen app nogensinde er komplet, og alt starter med at være simpelt.

Du skal aldrig forsøge at bygge en alt-i-en-app. Lad være med at gøre det. Jeg har set det ske selv i et professionelt miljø, og resultatet er en masse smerte og få fremskridt.

Medmindre du har en jernvilje, eller du virkelig elsker udfordringer, ender du bare med at blive frustreret og modløs, hvis dit første projekt er for svært at bygge. Du er en nybegynder … det gælder lige nu om at have det sjovt. Sjov er den mest effektive måde at lære på.

Så tag et kig på den liste over funktioner, du har lavet, og hvis den er for lang, så begynd at strege funktionaliteter over, som din app kan fungere uden.

Husk, dette er din version 1, og du skal bare holde tingene enkle. Fokuser på de ting, der gør det muligt for appen at udføre det, den skal gøre – alt andet kan du lade være til et andet projekt.

For et eksempel på en liste over kernefunktionalitet for en Reddit-klon:

• Brugere kan oprette en konto
• Brugere kan hente mistede adgangskoder
• Brugere kan ændre deres adgangskoder
• Brugere kan sende nye links
• Brugere kan kommentere på links
• brugerne kan upvote/downvote links
• brugerne har en profil, der viser deres historik/aktivitet

De funktioner, der er anført ovenfor, er de centrale funktioner, som du bør fokusere på først. Andre funktioner såsom:

• Brugere kan dele til sociale medier
• Brugere kan slette kommentarer
• Brugere kan redigere kommentarer
• Brugere kan slette deres egen konto

Er sekundære og kan gemmes til version 1.x kun arbejde på disse, når du rent faktisk kan lancere version 1.0

Trin 3: Skitsér din app

CC-licens

Ingen ting er hurtigere end en pen & papir. På nuværende tidspunkt bør du have en ret solid idé om, hvad din app skal gøre, så skitsér wireframe af din app’s UI (brugergrænseflade). Hvor knapperne skal være placeret, hvad formålet med den pågældende knap er osv.

Skriv noter ned, og uddyb, hvordan appen skal fungere. Du er stadig i brainstormingfasen, så ændre på tingene, indtil du er nogenlunde tilfreds med det.

Husk, hold tingene enkle. Hvis du har forkortet din liste fra trin 2, skal du holde dig til kun at skitsere de funktioner, der er anført der – lad dig ikke rive med. Hvis du ikke kan lade være, så skitser 2 versioner: en basisversion og den endelige version i dine drømme.

Alt i alt er dette ikke det endelige udseende, men blot et skridt, der skal hjælpe dig med at få et fastere greb om din app.

Trin 4: Planlæg din app’s UI Flow

Okay. Du har en god idé om, hvordan din app skal se ud, hvad hvert enkelt element skal gøre, og hvordan brugerne kan interagere med din app. Nu er det tid til at finde ud af din app’s UI-flow. Det vil sige, hvordan en bruger skal bruge din app fra start til slut. Skitsér alle de trin, de skal tage, og alle de scenarier, de kan støde på. Prøv at overveje alle brugssituationer.

(CC-licens)

Inddrag alle de handlinger, som din bruger kan foretage, i flowdiagrammet. Hvis din app f.eks. kræver, at brugerne skal logge ind, hvordan opretter de så en konto? Hvad sker der, hvis brugerne har glemt deres adgangskode? Hvad hvis de har indtastet en forkert adgangskode? Hvad skal en bruger kunne gøre på hver grænseflade (tilføje et nyt listeelement > gemme; redigere > gemme/slette)? Og så videre, og så videre. Dette gøres hurtigst med pen og papir.

Og da din app skal være forholdsvis simpel, skal dit diagram ikke være for massivt.

Trin 5: Design af databasen

Okay! Når du har planlagt alle mulige scenarier, skal du tage et kig på det for at bestemme, hvilken slags data du skal gemme. Hvis din app f.eks. kræver, at brugerne opretter en konto, skal du holde styr på ting som brugernavn, bruger-id, brugerens e-mail, adgangskode, om brugerens e-mail er bekræftet, hvornår kontoen blev oprettet, samt hver gang brugeren har logget ind i din app.

Hvis du bygger en Twitter-klon, skal du kende tweetets ID, tweetets indhold, hvornår tweetet blev offentliggjort/retweeteret, hvor mange retweets det har, og hvor mange stjerner det har. Du skal også have en registrering af en brugers retweets og stjerner.

Du kan tegne et ERM-diagram (Entity-Relationship Model) for at kortlægge datarelationerne.

Eksempel på et kursusvalgssites Entity-Relationship Diagram CC License

Hvis du desuden har planlagt fremtidige funktioner, er det nu, du skal planlægge dem i din database. Her er en god artikel, som du kan læse, mens du designer en database.

Avanceret

Hvis den app, du planlægger, skal interagere med en server (f.eks. hvis du bygger en fullstack webapp), eller hvis din app skal interagere med en API (f.eks. du forsøger at få oplysninger fra Yahoo! Weather ), så er det sandsynligvis en god idé at tegne et sekvensdiagram, så du kan få en bedre idé om, hvordan processerne skal fungere.

Fra Wikipedia

Trin 6: UX Wireframes

Okay, du har planlagt backenden. Nu er det tid til at planlægge din front-end.

Håbentlig er du stadig lige så begejstret som minionerne ovenfor. Du ved, hvad du har brug for – nu har du en meget bedre idé om, hvordan din app skal se ud.

CC License

Da mennesker for det meste er visuelle væsner, vil du have lettere ved at forstå, hvad du skal gøre, hvis du har et billede af hver enkelt visning, du skal kode. Men hvis du er som mig, og din tegning er så rodet, at du næsten ikke kan forstå det obskure stykke … hoste mesterværk … du har skabt, er det naturligvis uklogt at fortsætte med dette trin ved at misbruge dine stakkels kunstneriske hjerneceller.

Glædeligt nok findes der mange wireframing- og mockup-værktøjer online, der kan hjælpe dig med at planlægge dit UX/UI-flow (f.eks. Gliffy, Mockflow, Framebox, Wireframe.cc, Invisionapp).

Trin 6.5 (valgfrit): Design UI

Dette er et valgfrit trin, men hvis du har til hensigt at specialisere dig i front-end-udvikling, eller hvis du går så meget op i, hvordan din app kommer til at se ud, at en pænere app vil motivere dig til at kode, skal du helt sikkert gå i gang med at designe appen, så alle disse wireframe UI-elementer kan erstattes med pænere elementer.

Hvis du elsker at designe, vil du sandsynligvis designe appen, før du går i gang alligevel – måske har du allerede designet den under trin 2.

Hvis du ikke er til design, men stadig går op i, hvordan din app kommer til at se ud, kan du overveje at bruge elementer fra UI-kits. Her er et par ressourcer til UI-elementer:
(Bemærk: Photoshop påkrævet)

UI Cloud
Graphicburger
UI Dock

Til spil:
Spriters Resource

Du skal dog ikke hænge dig alt for meget op på appens udseende. Lige nu bør du i stedet fokusere på at opbygge en app’s funktioner.

Trin 7: Researching Solutions

Godt! Du er færdig med planlægningsfasen … men hvordan skal du kode alle de ting?

En vigtig færdighed, du skal lære som programmør, er at vurdere, hvornår du skal bruge noget, som en anden udvikler allerede har skrevet, og hvornår du selv skal bygge funktionen.

Da alle bygger en unik app, er det ikke alle brugssituationer, der er ens. Derfor skal du vurdere, hvornår du skal bruge en eksisterende løsning, og hvornår du skal bygge din egen, og det bliver du bedre til at gøre med erfaringen.

Hvis du føler dig som en retningsløs båd, der er fortabt på et stort hav, så tag en dyb indånding, og gå ikke i panik. Du kan godt klare det.

Når du får mere erfaring med at undersøge, finpudse din “Google-fu” og bygge ting, vil du efterhånden få styr på denne proces.

Se på løsninger

Kig på alle de diagrammer, du har tegnet, samt den funktionalitetsliste, du lavede i trin 2.

Hvad er der for nogle ting, du ikke aner, hvordan du skal bygge?

Skal brugerne f.eks. oprette en konto? Er din app afhængig af opdateringer i realtid? Hvilke funktioner har du brug for?

For det meste er det en god idé blot at bruge en eksisterende løsning til store funktioner såsom håndtering af realtidssynkronisering (f.eks. Firebase), netværk/routing (f.eks. AFNetworking til iOS-apps), autentificering og UI-relaterede komponenter (f.eks.f.eks. flipboard eller pinterest-agtig app).

Der findes mange online-databaser, hvor du kan søge efter backend-relaterede komponenter/pakker/perler/etc., men du skal være forsigtig med din vurdering af, hvad andre har skrevet – du skal ikke bare bruge dem blindt. Du kommer forhåbentlig ikke til at bygge noget alt for komplekst lige nu, så lige nu har du sandsynligvis ikke brug for komponenter, som andre har skrevet.

Den bedste måde at starte på er under alle omstændigheder at studere, hvad andre udviklere har gjort før dig, og lære logikken bag deres beslutninger. GitHub er din bedste ven.

For at få et eksempel fra det virkelige liv på en erfaren udviklers researchproces for en bestemt funktion kan du læse dette indlæg om, hvordan Angular-Plunkers skaber byggede Plunker’s drag-and-drop-direktiver.

Valg af værktøjer til at komme i gang med

Hvis du bygger en webapp, kan du måske tjekke Yeoman, da det har til formål at hjælpe dig med hurtigt at kickstarte nye projekter ved at hjælpe dig med at opstille strukturen i dit projekt.

Hvis du bygger en React-app, kan du også tjekke startpakker og eksisterende Flux-implementationer. HTML5Boilerplate og Bootstrap er populære front-end-skabeloner til din app. Oftest bruger boilerplates Gulp eller Grunt til opgavestyring.

Da du sandsynligvis kommer til at bruge nogle eksisterende komponenter eller løsninger, bør du også installere bower til afhængighedsstyring (npm for dem, der bruger Node.js, og CocoaPods for iOS-udviklere). Bare rolig – for det meste kommer disse værktøjer med tutorials, der lærer dig at installere dem.

Trin 8: Opbygning af appen

Ja! Du er klar til at bygge appen nu! Her er nogle tips, du bør huske på, når du bygger din app.

Tjekliste

Du bør fokusere på at bygge appen funktion for funktion. Hvis du således ikke er færdig med en opgave som f.eks. et kommentarsystem, skal du ikke pludselig begynde at bygge en brugerprofilvisning. Med andre ord, hvis du f.eks. bygger en formular, bør du arbejde på både front- og backend-koden, indtil funktionen er færdig.

For at holde styr på dine fremskridt kan du skrive en to-do-liste over funktioner ned og bruge den som en tjekliste.

Skriv tests først

Medmindre du bygger en spilapp, er det en god idé at skrive en test for din funktion først, inden du rent faktisk begynder at kode funktionen. Fejl er uundgåelige, men testning vil i høj grad reducere dine fejl og dine chancer for at frigive fejlbehæftet kode til produktion.

Givetvis tager det tid at skrive enhedstests, og du kan nogle gange sætte spørgsmålstegn ved, om det er det værd. Men hvis du ønsker at bygge større projekter i fremtiden, hvor du vil fortsætte med at tilføje nye funktioner, kan dette ske for din app:

Så kan dette (er en overdrivelse af, hvad) ske:

Og gud forbyde det:

Og dette ville være dig, der forsøgte at reparere appen:

…Mere eller mindre.

Det er altså en god idé at starte i det små og vænne sig til at lave testdreven udvikling (TDD), især fordi du starter på en frisk og bygger noget simpelt.

Du er ikke på en deadline med en projektleders høtyv bag din ryg nu, vel?

For tips om unit-testmønstre kan du læse denne artikel. Et andet tip, du skal huske på, er at undgå at hævde for mange trivialiteter.

Der findes mange testværktøjer, som du kan vælge imellem, f.eks. Jasmine eller Karma til JavaScript, Rspec til Ruby, PyTest til Python, PHPUnit til PHP, Quick som et alternativ til xCTest til iOS-udvikling, eller hvilket som helst værktøj, som du føler vil fungere for dig.

Dertil kommer, at hvis du bygger en iOS- eller Android-app, er det en god idé at tjekke Crashlytics.

7 trin til at debugge effektivt og virkningsfuldt

Brug Git

Git er et versionsstyringssystem og et fuldgyldigt repository med komplet historik og fuld versionssporingsfunktionalitet. Det er en god idé at begynde at lære at bruge Git, mens du bygger din første app. På den måde kan du nemt fortryde dine fejltagelser, gendanne tabte data og meget mere. Hvis du desuden planlægger at arbejde sammen med et team af udviklere i fremtiden, skal du alligevel bruge git. GitHub er den mest populære Git repository-hostingtjeneste til open source-projekter, mens Bitbucket er til private repositories.

Hvis du ender med at løbe ind i problemer, når du bruger git, kan dette indlæg om de 10 mest almindelige Git-problemer og hvordan du løser dem måske hjælpe dig.

Hvis du sidder fast…

Som nybegynder vil du føle dig som hamsteren oftere og oftere.

Du er ikke alene. Nogle gange er det eneste, du skal gøre, at tage en pause og lade problemet simre, så du kan få renset dit sind.

Hvis dette stadig ikke virker, er her nogle måder at løsne dig selv på:

Google

Jeg nævnte Google-fu i trin 7, men lad mig igen understrege, at det at lære at google er en vigtig færdighed, som alle programmører skal tilegne sig. Hvis du sidder fast på en fejl, eller hvis du ikke ved, hvorfor din kode ikke virker, er det en god idé at google.

Spørg på StackOverflow

Du vil sikkert bemærke, at dine google-resultater for det meste vil pege på spørgsmål og svar på StackOverflow. Hvis du stadig ikke kan finde en løsning på dit problem efter at have googlet røven ud af bukserne, kan du prøve at stille et spørgsmål på StackOverflow.

Husk at vise, at du har lavet din research i dit spørgsmål – på den måde er der større sandsynlighed for, at du får et svar.

Alternativ: Find en mentor

Nogle vil sige, at StackOverflow ikke er begyndervenligt, fordi nybegyndere ikke ved, hvordan de skal formulere deres spørgsmål. Men hvad nu, hvis du ikke engang ved, hvad dit problem er?

Hvis du kommer til at headdeske (eller hvis du allerede headdesker…), behøver du ikke at misbruge din pande (hvis du slår dit hoved hårdt nok, mister du bare hjerneceller).

Et godt alternativ til at lette din udvikling og din læringsproces er at få hjælp fra en erfaren programmør. Du behøver ikke at føle, at du på en eller anden måde er dum, fordi person X er en berømt ekspert og en selvlært programmør. Folk lærer simpelthen forskelligt, og alle begyndere vil have gavn af personlig vejledning, da du måske begår fejl, som ikke er noget særligt lige nu, men som faktisk er en dårlig praksis.

Husk, dengang havde mange autodidakte udviklere ikke de tjenester, som du nu har adgang til.

Du kan derfor få hjælp fra erfarne programmører via live 1:1-sessioner på Codementor, hvor priserne for mentorer starter fra 15 dollars/minutter. Under disse sessioner kan du have en videochat med en erfaren udvikler og dele din skærm/kode med dem, og mentoren vil lære dig, hvordan du retter din kode, samt fortælle dig, hvad du har gjort forkert, så du kan undgå fejlen i fremtiden. Du kan også gennemgå koden fra sessionen eller optage sessionen på din lokale disk via videochat-værktøjet. Tilmeld dig nu, og prøv de første 15 minutter gratis med mentorer, der tilbyder tilbuddet.

Sidste tip

Programmører laver fejl hele tiden, så du skal ikke føle dig modløs, hvis du ikke engang kan bestå en test, du har skrevet, eller hvis du konstant snubler over dig selv. Jeg mener, tænk på iOS9, Android Lollipop eller en eller anden app du elsker at bruge. Selv de mest modne apps derude har sikkert stadig fejl, så du skal ikke gå ud fra, at du kan bygge den mest perfekte, fejlfri app derude (det betyder selvfølgelig ikke, at du skal sætte lave standarder for dig selv – du skal altid stræbe efter at bygge kvalitetsapps).

Det er desuden meget almindeligt, at du kan bruge timer eller endda dage på en ting og alligevel have svært ved at få den til at fungere, som du ønsker. Hvis det var nemt at programmere nye funktioner hurtigt, ville verden ikke have brug for nye programmører. For fanden, så ville vi sikkert være på et fejlfrit iOS100 nu, og vi ville have bygget en digitaliseret verden som den i Matrix.

Så ville man ofte høre udtrykket “lav fejl”, når folk opfordrer dig til at begynde at bygge ting. De mener det. En ting, du bliver nødt til at acceptere som programmør, er, at du ikke bliver en badass-kodningsmaskine, der kan fremtrylle funktioner på et øjeblik. Du kommer til at fejle meget, og det er ok.

Og husk igen, at du er nybegynder, så mange ting vil uundgåeligt være vanskelige i starten. Du kommer til at bruge meget tid på noget, som du tror burde være simpelt, og det vil virke som en svær kamp op ad bakke, men efterhånden som du får mere erfaring, vil tingene blive lettere. Glæd dig til følelsen af at have opnået noget, når det endelig lykkes dig at bygge din første app, og du kan endda overveje at sælge din app, hvis du finder det passende.

Happy Coding!

Author Bio

Yi-Jirr Chen || Content Maketing & Operations
Din typiske massive nørd, der spiller og elsker videnskab/teknologi. Udgiver også fiktion under et pseudonym, der er et pseudonym af en grund

Andre artikler, du måske er interesseret i:

• Sådan får du dit første udviklerjob (selvom du ikke har en CS-eksamen)
• Developer Community’s 9 Tips for Coding Beginners
• 40 Side Project Ideas for Software Engineers
• Hvordan du starter din karriere og lander din første kunde som freelanceudvikler