En grundlæggende guide til valg af den rigtige teknologiske stak til klientarbejde

Foto af Robert Anasch på Unsplash

At forstå virkningen af ​​at vælge den rigtige tech-stack er en vigtig succesfaktor for freelance-udviklere. Denne guide undersøger de vigtigste spørgsmål, du skal svare på, når du vælger de bedste teknologier til din klients applikation eller websted. Vi opfordrer dig til at læse det, før du skødesløst hopper over de nyeste JavaScript-rammer.

Som de fleste udviklere, der har lidt erfaring, ved, bygger software professionelt ikke kun om levering omgående. Det handler også om at optimere for vedligeholdelighed, skalerbarhed og sikkerhed, og niveauet for hver afhænger af klientens forretning.

En ordentlig analyse af projektet dikterer, hvilke teknologier du skal bruge, ikke omvendt. Dette enkle princip vil fremme store, langsigtede forretningsforbindelser.

Virkningen af ​​dine tekniske valg vil mærkes i næsten ethvert lag af virksomheden, fra HR til finansiering, fra ledelse til markedsføring. Manglende vision kan ødelægge dit omdømme - et aktiv, som ingen freelancer skal gå på kompromis med.

For at opbygge den følgende liste interviewede vi senior freelance-udviklere om de vigtige spørgsmål, de stiller sig selv, før de skriver en enkelt kodelinje. Vi delte resultaterne i 3 blokke: forstå projektet (forretningsperspektiv), vælge stakken (teknisk perspektiv) og videregive faklen (HR-perspektiv).

Lad os komme igang.

Forstå projektet

Det er obligatorisk, at du forstår produktvisionen, klientens forretning og projektets tidsramme.

Hvad er projektets omfang, budget og tidsramme?

Har din klient brug for alt, der leveres inden for 2 uger for at overleve, eller er det et langsigtet projekt, der kræver robusthed og maksimal vedligeholdelsesevne?

Du burde vide:

  • Hvornår skal det leveres?
  • Hvor mange af dine timer kan de betale for?
  • Hvad er det forventede resultat?

Svarene definerer den uslebne ramme for følgende spørgsmål. Det er også en meget god måde at vide, om din klient har realistiske forventninger, før du starter (for mere information om signaler til at identificere forfærdelige klienter, kan du læse dette indlæg).

Er det en en-timer eller et langsigtet projekt?

Et kortvarigt projekt, der øjeblikkeligt bliver papirkurven efter en begivenhed eller en bestemt milepæl, bør ikke benyttes som et årti-projekt.

Der er ingen mening i at overkonstruere arkitekturen af ​​en prototype - det er bare en god måde at spilde dyrebart budget på. På den anden side, hvis klienten planlægger at ansætte 20 udviklere i de næste 5 år til at iterere på din kodebase, skal du opbygge robuste søjler på omfattende testede teknologier.

Kan de håndtere den tekniske gæld?

En klient, der er presset til at generere indtægter, tåler lidt teknisk gæld for at komme til markedet ASAP. Hvis indsamling af markedsføringsdata er det vigtigste mål, er de ligeglad med kontinuerlig integration og procentdel af testdækning. Forretningsmæssige mål først, tekniske mål for det andet.

En smule uddannelse kan være nødvendig her. Det er dit ansvar at få dem til at forstå konsekvenserne af akkumulering af teknisk gæld i det lange løb. At demonstrere sådan fremsyn er en god måde at opbygge troværdighed på.

Hvor sikker skal det være?

Tænk nu på din klients aktivitetsområde et øjeblik. Chancerne er, at deres datafølsomhed varierer, ikke? Nå, de teknologier, du vælger, skal afspejle denne unikke virkelighed. Du har ikke brug for en 4096-bit RSA- og DDoS-beskyttelse til den lokale festivals websted.

Men at integrere et eksperimentelt plugin med kendte udnyttelser til en app, der er vært for økonomisk info? Lidt risikabelt, ven.

Tråd dog stadig let, når det kommer til sikkerhedsbesatte klienter. Nogle af dem hører uhyggehistorier, der holder dem op om natten:

”Men jeg er overbevist om, at disse russiske hackere, jeg har set på tv, stjæler vores restaurants mailingliste.”

Nej, kære klient. De vil sandsynligvis ikke.

Kan jeg håndtere projektet?

At vælge et projekt, der er langt over dit færdighedsniveau, vil næsten helt sikkert ende med et rod.

Dine uuddannede valg vil lægge byrden på arbejdsgangen, og milepæle vil blive savnet. Vær ikke hensynsløs med din klients penge - juridiske konsekvenser er aldrig for langt væk.

Hvis du er i tvivl om din evne til at levere et projekt, skal du sørge for at gøre din research, inden du kommer om bord.

Vælg den rigtige stak

Lad os nu gå videre fra projektledelsesproblemerne. Lad os tale om, hvad der virkelig betyder noget: stakken. At vælge de rigtige teknologier skulle komme temmelig naturligt, hvis du har lidt erfaring og en klar vision om, hvad du har brug for at bygge.

Hvordan kan jeg ikke kode?

Hundredvis af rammer og tusinder af plugins vedligeholdes af aktive samfund af udviklere. Spild ikke din dyrebare tid på at genudvikle noget, der allerede er poleret i årenes løb.

Måske har du ikke engang brug for en server! Generøse og lidenskabelige mennesker forsøger at gøre dit job lettere - ikke se bort fra deres indsats. At opfinde hjulet er dumt.

Udviklingstid bør altid fokusere på det, der gør projektet unikt: den brugerdefinerede forretningslogik. Inden du skriver en enkelt kodelinje, skal du sørge for, at den tilføjer værdi til projektet.

Er det overdreven, eller underdrevet?

Din klient planlægger at sælge tilpassede t-shirts til lokale kunder gennem en lille e-handel? Du behøver ikke en høj tilgængelighed, belastningsafbalanceret, klynget, ikke-SQL front-end cache-mekanisme, klar til at støtte en million samtidige kunder. Dette ville være som at flytte ud af din lejlighed med et lasteskib.

På den anden side er det ikke supereffektivt at prøve at nedtage en tyr med en slangebøsse. En klient, der planlægger at sælge tusindvis af varer på daglig basis, vil videresende dig for at vælge en gratis CMS-løsning, der er implementeret i et billigt eksempel.

Vælg det rigtige værktøj til jobbet.

Er disse teknologier veldokumenterede og understøttede?

At grave i en kommentarfri japansk kodebase, fordi en arkane plugin pludselig stoppede med at fungere, er ikke den bedste måde at overnatte på. Sørg for, at der er et aktivt samfund omkring hver teknologi, du vælger. Hvis den sidste opdatering af lageret var for 4 år siden, skal du være bekymret.

Denne følelse af hjælpeløshed, når du får 3 ubrukelige Google-resultater til dit tekniske spørgsmål, er endnu værre, når klienten skriger til dig i telefonen.

Forstår jeg de risici, der er forbundet med den nye teknologi?

Denne tendensramme på HackerNews blev sandsynligvis ikke testet korrekt. Du kan måske føle dig hård, fordi du bruger den som den centrale søjle i et produktionsprojekt, men bare ved, at det tilføjer en masse unødvendig ekstern risiko.

Hvis du stadig føler dig skødesløs, kan du i det mindste eksperimentere med det nok til at vide, om det understøtter din klients brugssager. De er ligeglad med, at din ramme får 300 stemmer, hvis du skal ændre det dagen før en vigtig milepæl.

At sende faklen: det handler ikke kun om dig

Kilde

Jeg hader at nedbryde det på denne måde, men din klient ønsker ikke at stole på dig for evigt. Selvfølgelig kan din stak muligvis være robust, veldokumenteret, sikker og lynhurtig.

Men hvis kun et lille samfund af udviklere over hele verden ved, hvordan man får det til at fungere, skaber du en dødvande. Kunder hader deadlocks.

Vil de være i stand til at finde udviklere til at arbejde med din Stack?

Det kan skyldes, at du ikke kan arbejde sammen med dem, eller fordi de ønsker at skalere holdet, eller måske ønsker de at repatriere udviklingsindsatsen internt. Men til sidst har din klient brug for en anden udvikler til at skubbe kode til kodebasen.

Hvis de er nødt til at gennemgå hvert eneste jobbræt i verden for at finde en enkelt udvikler med en bestemt ekspertise, gæt du, hvem der får skylden?

Vil de have penge til at betale for sådanne udviklere?

Hvis de eneste mennesker, de kan ansætte for at arbejde på din alt for komplicerede tech-stack, er dyre guruer med 20 års erfaring, kan det være mere omkostningseffektivt at få en anden til at gøre alt sammen med mainstream-teknologier.

Må ikke visionere om udviklingsindsatsen, det handler ikke kun om dig.

Konklusion

Vi håber, at denne korte artikel hjælper dig med at undgå rædhistorier, stressende aftener og akavede diskussioner. At gå i gang med de tekniske beslutninger, inden du besvarer centrale spørgsmål, sparer ikke dig tid i det lange løb. Dette er oplevelse af at tale.

Tag dig tid til at vurdere situationen korrekt, selvom du har lyst til at åbne din IDE eller kodeditor allerede.

Glade kunder = Gentag / henvisningsvirksomhed = Mindre Bizdev-indsats = Mere tid brugt på udvikling.

Bemærk: dette indlæg er lavet i tæt samarbejde med Philip Barclay, en god ven af ​​mig. Phil har lavet digitale produkter i årevis og bygger nu fantastiske ting hos Mirego og Picks.

Fortæl os, hvis vi har gået glip af nogle vigtige spørgsmål i kommentarerne!

Oprindeligt offentliggjort på Snipcart-bloggen og deles i vores nyhedsbrev.