10 verste mareritt for webutviklere

Mange mennesker rundt meg tror jobben min som en webutvikler er enkelt. Vanligvis ser de meg pummel tastaturet hjemmefra, med en fin varm kopp kaffe eller te ved siden av meg. Det de ikke ser er hva som skjer i maskinen foran meg .

Nesten alle utviklere vil møte de samme problemene jeg står overfor: de verre tilfellene, de marerittfremkallende horrorene; noen ganger uheldig; noen ganger "noen må trekke en fryktelig prank på meg" følelser - til tider å hoppe av en bro virker som det enklere å gjøre. Hvis du er en erfaren webutvikler som har jobbet med mange kunder og prosjekter, har du kanskje kommet over noen av disse situasjonene.

For de av dere som tenker på å bli en web- eller apputvikler, er det noen av situasjonene du kanskje kan finne deg i. Vær forberedt på å møte dem, og ikke si at du aldri ble advart. Dette er de 10 verste mareritt utviklerne må møte .

1. Fastsetting av andre utviklere forvirrende koder (og feil)

Hvis du nettopp har sluttet seg til et nytt selskap, vil du sannsynligvis finne deg selv i stand til å rydde opp et prosjekt etterlatt av utvikleren du nettopp har erstattet . Sjansene er at koden er lang, ekte kompleks, ulæselig, kritisk ridd med feil ... og allerede live online. Selvfølgelig kan du være heldig 5% som ikke trenger å fikse en annen utviklers kode, men ærlig kodefiksing skjer oftere enn ikke .

Problemet oppstår fordi utviklere, som forfattere, har sin egen kodestil . Det er her dokumentasjonen blir en godsend - hvis du alltid har hatet å gjøre dokumentasjonen (ikke vi alle?), Så vet at dette er avgjørende for sunnheten til alle som må røre ved koden din .

Uten riktig dokumentasjon må den nye utvikleren skanne gjennom kodelinjer for å finne ut din (eller den opprinnelige utviklerens) tankeprosess. Det er tider som dette at vi ønsker telepati faktisk eksisterer.

2. Bugs vises i det verste mulige øyeblikk

Etter måneder med hardt arbeid og tonnevis av koffein, la du endelig ut appen din til massene eller presentere den til klienten din. Du er veldig spent og kan se lyset på enden av tunnelen, etter måneder med å dra gjennom det samme prosjektet natt etter natt.

Så treffer den. En kritisk feil oppstår i løpet av demoen, eller fremkaller klager fra hundrevis av nye brukere. Din perfekte utsikt over ditt perfekte prosjekt kommer ned. Men slå "pause" et øyeblikk.

Først av alt, vet at dette kan skje med noen - selv til strålende utviklere av store produkter som Facebook og Twitter. For de som har vært der, vet du hvor frustrerende denne situasjonen kan være; De dårlige vurderingene fortsetter bare å komme inn, eller kundene ser på deg som om du har begått den ultimate forbrytelsen eller smurt familienavnet .

Du vet hva du kan gjøre? Hold deg rolig . Fest feilene ASAP, og hold bare et rett ansikt. Ikke la dette dra deg ned for lenge ... med mindre reparasjonen fører til at andre feil oppstår!

3. Fixed a Bug; forårsaker nye

Feilfiksering er et nødvendig onde. Torturøs, uproduktiv og bare en hjerteproblem-inducerende aktivitet som gjør at du spørsmålet hvorfor du vil være en utvikler i utgangspunktet. Hver utvikler har vært der. Etter timer med å trykke på tastaturet, fikser du endelig den opprinnelige feilen bare for å finne ut at du har opprettet flere!

Det kan være at du har oppdatert et bibliotek fordi det ikke var kompatibelt med et annet bibliotek du brukte, bare for å finne ut at det nye biblioteket var i konflikt med koden din . I mellomtiden holder tidsfristen på, samtalene for å sjekke deg fortsetter å komme inn, og antall feil bare fortsetter å hakke opp.

Stopp tugging på håret ditt og prøv å planlegge for dette. For å hindre at en lignende situasjon skjer med fremtidige prosjekter, bruk Git til å administrere revisjonene dine, slik at du kan gå tilbake til tidligere revisjoner hvis den nye ikke fungerer som den skal.

Husk også å dokumentere hver revisjon nøye. Det kan virke som en nyskapende oppgave, men når du kommer til å skyve, vil du takke deg selv for å henge på og faktisk gjøre dokumentasjonen .

4. Feilen ligger i biblioteket du stoler på

Du vet hva er et enda verre mareritt? Når feilen du fant i koden din, ikke eksisterer i koden din, men i et av bibliotekene du brukte. Vi stoler ofte på flere biblioteker for å bygge nettsteder, og utviklere kan bruke det samme biblioteket for flere prosjekter uten å ha en hitch.

I dette spesielle scenariet oppstår imidlertid en feil, kontrollerer du det, og du finner ut at feilen kommer fra et av bibliotekene du bruker. Hva gjør du? Det er et dilemma, ikke sant? La oss vurdere alternativene.

• Du vil kanskje rette biblioteket alene, i så fall bør du spørre deg selv hvor dyktig du er med kodene i biblioteket for å faktisk gjøre det?
• Kan ikke fikse det? Så skal du sende inn en forespørsel om at utvikleren skal fikse det? Det kommer til å ta litt tid, som de ikke er forpliktet til å haste ut siden du er den som har fristen, ikke dem.
• Hva med å erstatte det biblioteket med en annen ? Det ville få feilen ut av systemet. Men da må du skrive om biter av koden din bare for å få ting til å fungere.

Se, jeg sa at de var alternativer, jeg sa aldri at noen av dem er enkle. Bare be til programmeringsgudene at du aldri må bli utsatt for denne situasjonen, eller til den neste heller.

5. Feilårsaken er "ukjent"

Nei, dette kan ikke være! Du har søkt etter dager for feilen, og oppretter flere Git-grener for testing, men feilen er fortsatt unnvikende . Du går til StackOverflow for en utsagn, bare for å finne et spørsmål med det samme problemet som ble lagt ut for 2 år siden med null svar.

Det kan ikke være en kritisk feil, men det tråkker på deg som en kløe som du ikke kan nå eller bli kvitt. Hodet ditt begynner å snurre, du forteller deg selv at hvis du bruker en ekstra time på å søke, finner du den jævla feilen.

Stoppe. Løsningen på dette problemet er faktisk det direkte motsatte. Du bør holde seg borte fra datamaskinen din i en halv dag, eller lenger (går i 2 dager er best). Du lider av mental tretthet som forhindrer deg i å "se" eller "finne" selve problemet. Å ta en pause vil hjelpe deg med å oppnå 100% igjen.

Og hvis min erfaring kan være en kilde til referanse, noen ganger buggjører seg selv og slutter å være et problem uten din forstyrrelse. Det skjer bare, og når du er utmattet, bryr du deg virkelig ikke om hvorfor .

6. Data tapt, ingen sikkerhetskopiering

Holey moley, dette er et mareritt selv ikke-utviklere kan forholde seg til. Du lider av komplett datatap og du forbanner deg selv for ikke å bruke tid til å sikkerhetskopiere filene dine. Hvis dette skjer med deg, har du absolutt deg selv skylden.

Selv når du arbeider med svært stabile systemer, kan harddisken din plutselig opptre, barna dine kan trykke på Slett-knappen, eller ved et uhell spilder du kaffe på den bærbare datamaskinen. I stedet for å gråte over spildt kaffe, gå tilbake til sikkerhetskopien, og hold høyt blodtrykk nede. Dette er ikke en leksjon du vil lære den harde måten.

Personlig har jeg ikke bare én eller to kilder for sikkerhetskopiering av viktige filer - jeg har tre: Time Machine, Dropbox og OneDrive. OS X-brukere bør aktivere Time Machine. For Windows-brukere, aktiver sikkerhetskopierings- og gjenopprettingsfunksjonen fra Kontrollpanel .

7. Gjør det til å fungere i Internet Explorer 6

Av en eller annen grunn er det fortsatt behov for å lage moderne apper på Internet Explorer 6 fordi noen kunder og deres kunder fortsatt insisterer på å bruke Internet Explorer 6. Hvis du er en av disse personene, la meg gjøre det klart for deg hvordan tid- konsumerende og forstyrrende koding for IE 6 er.

Tidsutviklerne som bruker for å lage en webapp i IE 6, kan være tre eller flere ganger lengre enn å bygge appen for moderne nettlesere som Chrome eller Firefox. Den frustrerende delen er at den ikke løper så jevnt eller så imponerende på IE 6 som det vil på de nye nettleserne. Noen av effektene vil ikke tre i kraft, noen av feilene vil holde deg bugget og ikke få meg i gang med sikkerhetsproblemer .

Du gjør livet vanskelig for utviklere fordi du eller ditt system nekter å bruke en nyere nettleser. Og hvis jeg har råd til å dele med andre utviklere, er det at du skal belaste dobbelt eller mer for de som ber om en moderne webapp for fortsatt å kunne kjøre på IE 6. Og det vil fortsatt ikke være verdt trøbbel .

8. Semikolonnøkkelen fungerer ikke

Flere programmeringsspråk JavaScript og PHP trenger semikolon for å markere slutten av en uttalelse. Det er som perioden eller fullstopp som slutter en setning.

Det oppstår mange feil på grunn av den manglende semikolon, og du kan definitivt ikke ha semikolonnøkkelen på tastaturet ditt, og du slutter å jobbe. Vurder å ha et ekstra tastatur som du kan plugge inn for å bruke i nødstilfeller som dette.

9. Internett og Google er ned

Hvis Google er viktig for deg i arbeidet ditt eller din studie, vet du at det er dobbelt viktig for utviklere. Som webutviklere bruker vi Google til å søke etter kodeprøver, finne løsning for feil, samarbeide med jevnaldrende og mer.

Hvis Internett og Google går ned, må vi gå tilbake til en tidligere, isolert "periode med mørke". Vi vil bli sittende fast, ikke vite hva du skal gjøre hvis vi støter på spesielle feil. For det meste sparer Google oss alltid. Så, hatter av til utviklere eller programmerere som gjorde dette før en alder av Internett - jeg bøyer deg.

10. Du er ekspert (Du kan gjøre alt)

For å konkludere denne listen over mareritt utviklere må møte, forlater jeg deg med denne Youtube-videoen kalt The Expert av Lauris Beinerts. Du vil finne ut hvor vondt det er å bli ekspert.

Videre lesning

For å se på andre typer freelancing eller online jobber, kan du være interessert i:

• Guest Blogging: En redaktør forteller deg hva du gjør feil
• 10 tegn du har gått for langt til frilansdesign
• Frilansskribenter: En kikk inne i verden av frilansskriving
• Confessions Of A Web Editor - En Inside Look

Utfør FAQs Sider: 10 Eksempler du kan følge

Hvis du har et nettsted som omhandler kunder, kunder eller offentligheten generelt, er det nødvendig å ha behov for FAQ-siden . FAQ-siden omhandler spørsmål som blir spurt gjentatte ganger. Disse vanlige spørsmålene er roped sammen og plassert i denne delen der besøkende kan gå til, for å finne svar de trenger.Mange st

(Tekniske og design tips)

Bland dine egne CSS-gradienter med denne gratis webapps

Hver webdesigner bør vite om CSS3-gradienter . De har eksistert i årevis, og de er bredt støttet av alle de store nettleserne.Og nå, gratis webapps som Blend, lar deg lage CSS3-gradienter på fluen med visuelle redigeringsprogrammer i nettleseren . Du kan velge mellom lineære og radiale gradienter mens du tinker med farger for å blande.Den fø

(Tekniske og design tips)