nl.hideout-lastation.com
10 slechtste nachtmerries voor webontwikkelaars
Veel mensen om me heen denken dat mijn baan als webontwikkelaar gemakkelijk is. Meestal zien ze me het toetsenbord van thuis pummelen, met een lekkere warme kop koffie of thee naast me. Wat ze niet zien, is wat er in de machine voor me gebeurt .
Bijna elke ontwikkelaar krijgt te maken met dezelfde problemen waar ik voor sta: de scenario's met de slechtste scenario's, de nachtmerrie-inducerende verschrikkingen; de soms ongelukkige; soms "moet iemand me een vreselijke streek bezorgen" gevoelens - soms lijkt het springen van een brug het gemakkelijker om te doen. Als u een ervaren webontwikkelaar bent die met veel klanten en projecten heeft gewerkt, bent u mogelijk enkele van deze situaties tegengekomen.
Voor degenen onder u die erover denken om een web- of app-ontwikkelaar te worden, dit zijn enkele van de situaties waarin u zich uiteindelijk misschien zult bevinden. Wees voorbereid op hun confrontatie en zeg niet dat u nooit bent gewaarschuwd. Dit zijn de 10 slechtste nachtmerries die ontwikkelaars tegenkomen .
1. Fixing Other Developers Perplexing Codes (en Bugs)
Als u zojuist bent toegetreden tot een nieuw bedrijf, zult u hoogstwaarschijnlijk in de positie komen dat u een project opruimt dat is achtergelaten door de ontwikkelaar die u zojuist hebt vervangen . De kans is groot dat de code lang is, echt complex, onleesbaar, kritisch bezaaid met bugs ... en nu al online is. Je kunt natuurlijk de gelukkige 5% zijn die de code van een andere ontwikkelaar niet hoeft te corrigeren, maar eerlijk gezegd gebeurt het vaker om code te corrigeren dan niet .
Het probleem ontstaat doordat ontwikkelaars, zoals schrijvers, hun eigen codeerstijl hebben . Dit is waar documentatie een uitkomst wordt - als je er altijd een hekel aan hebt om de documentatie te doen (weet niet iedereen?), Weet dan dat dit essentieel is voor de geestelijke gezondheid van iedereen die je code moet aanraken .
Zonder de juiste documentatie moet de nieuwe ontwikkelaar de coderegels doorlopen om het denkproces van uw (of de oorspronkelijke ontwikkelaar) te achterhalen. Het zijn zulke tijden dat we willen dat telepathie daadwerkelijk bestaat.
2. Bugs verschijnen op het slechtst mogelijke moment
Na maanden van hard werken en tonnen cafeïne, heb je eindelijk je app vrijgegeven aan de massa of gepresenteerd aan je klant. Je bent heel opgewonden en ziet het licht aan het eind van de tunnel, na maandenlang door hetzelfde project te hebben gesleept, nacht na nacht.
Vervolgens raakt het. Een kritieke bug treedt op tijdens de demo of lokt klachten uit van honderden nieuwe gebruikers. Je perfecte beeld van je perfecte project stort in elkaar. Maar druk even op "pauze".
Ten eerste, weet dat dit iedereen kan overkomen - zelfs voor briljante ontwikkelaars van belangrijke producten zoals Facebook en Twitter. Voor degenen die daar zijn geweest, weet je hoe frustrerend deze situatie kan zijn; de slechte recensies blijven maar binnenkomen, of de klanten kijken naar je alsof je de ultieme misdaad hebt gepleegd of de achternaam hebt vervuild .
Weet je wat je kunt doen? Blijf kalm . Los de bugs zo snel mogelijk op en houd gewoon een recht gezicht. Laat dit je niet te lang slepen ... tenzij de oplossing ervoor zorgt dat andere fouten verschijnen!
3. Bug opgelost; veroorzaken nieuwen
Bugfixatie is een noodzakelijk kwaad. Torturous, improductief en slechts een hartprobleem, waardoor je je afvraagt waarom je in de eerste plaats ontwikkelaar wilt worden. Elke ontwikkelaar is daar geweest. Na urenlang tikken op je toetsenbord, repareer je eindelijk de originele bug om te ontdekken dat je extra hebt gemaakt!
Het kan zijn dat u een bibliotheek hebt bijgewerkt omdat deze niet compatibel was met een andere bibliotheek die u gebruikte, alleen om erachter te komen dat de nieuwe bibliotheek in conflict was met uw code . Ondertussen doemt de deadline op, blijven de telefoontjes om te controleren dat je binnenkomt, en het aantal fouten blijft maar toenemen.
Stop met aan je haar trekken en probeer vooruit te plannen. Om te voorkomen dat een soortgelijke situatie zich voordoet met toekomstige projecten, gebruikt u Git om uw revisies te beheren, omdat u hiermee eerdere revisies kunt herstellen als de nieuwe niet correct werkt.
Vergeet ook niet elke herziening zorgvuldig te documenteren. Het lijkt misschien een nevelsplijtende taak, maar als het erop aan komt, dank je je zelf dat je de documentatie hebt bewaard en deze feitelijk hebt gedaan .
4. De fout bevindt zich in de bibliotheek waar u op vertrouwt
Weet je wat een nog ergere nachtmerrie is? Wanneer de bug die u in uw code aantrof niet echt in uw code voorkomt, maar in een van de bibliotheken die u hebt gebruikt. We zijn vaak afhankelijk van meerdere bibliotheken om websites te bouwen en ontwikkelaars kunnen dezelfde bibliotheek gebruiken voor meerdere projecten, zonder problemen.
In dit specifieke scenario treedt er echter een fout op, controleert u deze en ziet u dat de bug afkomstig is van een van de bibliotheken die u gebruikt. Wat doe jij? Het is een dilemma, is het niet? Laten we de opties eens bekijken.
- Misschien wilt u de bibliotheek zelf repareren, in welk geval u zich moet afvragen hoe bekwaam u bent met de codes in de bibliotheek om dat ook echt te doen?
- Kan het niet repareren? Moet u dan een aanvraag indienen voor de ontwikkelaar om het probleem op te lossen? Dat gaat enige tijd duren, en ze zijn niet verplicht om zich te haasten, omdat jij degene bent met de deadline, niet zij.
- Hoe zit het met het vervangen van die bibliotheek door een andere ? Dat zou de bug uit het systeem halen. Maar dan moet je stukken van je code herschrijven om de dingen te laten werken.
Kijk, ik zei dat het opties waren, ik heb nooit gezegd dat een van hen gemakkelijk is. Bidt gewoon tot de programmeergoden dat je nooit aan deze of aan de volgende situatie hoeft te worden onderworpen.
5. De Bugoorzaak is "Onbekend"
Nee, dit kan niet! Je bent al dagen op zoek naar de bug en hebt meerdere Git-vestigingen gemaakt om te testen, maar de bug blijft ongrijpbaar . Je gaat naar StackOverflow voor een uitstel, alleen om een vraag te vinden met hetzelfde probleem 2 jaar geleden gepost met nul antwoorden.
Het is misschien geen kritieke fout, maar het trekt aan je als een jeuk dat je niet kunt bereiken of kwijtraken. Je hoofd begint te draaien, je blijft tegen jezelf zeggen dat als je nog een uur besteedt aan zoeken, je die verdomde bug zult vinden.
Hou op. De oplossing voor dit probleem is eigenlijk het tegenovergestelde. Je moet een halve dag of langer van je computer wegblijven (het is het beste om 2 dagen te gaan). Je lijdt aan mentale vermoeidheid die voorkomt dat je het werkelijke probleem "ziet" of "vindt". Het nemen van een pauze helpt je weer tot 100%.
En als mijn ervaring een referentiebron kan zijn, corrigeert het probleem zichzelf soms en is het geen probleem meer, zonder uw tussenkomst. Het gebeurt gewoon en als je uitgeput bent, wil je echt niet weten waarom .
6. Verloren gegevens, geen back-up
Moley, dit is een nachtmerrie waar zelfs niet-ontwikkelaars zich mee kunnen identificeren. U lijdt aan volledig gegevensverlies en u vervloekt uzelf omdat u geen tijd hebt besteed aan het maken van een back-up van uw bestanden. Als dit je overkomt, moet je jezelf absoluut de schuld geven.
Zelfs wanneer u werkt met zeer stabiele systemen, kan uw harde schijf plotseling in actie komen, uw kinderen kunnen op de knop Verwijderen drukken of u morst per ongeluk koffie op uw laptop. In plaats van over gemorste koffie te huilen, keert u terug naar uw reservekopie en houdt u uw hoge bloeddruk laag. Dit is geen les die je op de harde manier wilt leren.
Persoonlijk heb ik niet slechts één of twee bronnen voor het maken van back-ups van belangrijke bestanden - ik heb er drie: Time Machine, Dropbox en OneDrive. OS X-gebruikers moeten Time Machine inschakelen. Voor Windows-gebruikers schakelt u de functie Back-up maken en herstellen in via het Configuratiescherm .
7. Laat het werken in Internet Explorer 6
Om de een of andere reden is het nog steeds nodig om moderne apps op Internet Explorer 6 te laten werken omdat sommige klanten en hun klanten nog steeds volharden in het gebruik van Internet Explorer 6. Als u een van deze mensen bent, laat me u dan duidelijk maken hoe tijd- consumeren en verontrustende codering voor IE 6 is.
De tijd die ontwikkelaars besteden aan het maken van een webapp in IE 6 kan drie of meer keer langer zijn dan om de app te bouwen voor moderne browsers zoals Chrome of Firefox. Het frustrerende deel is dat het niet zo soepel of zo indrukwekkend zal zijn op IE 6 als in de nieuwe browsers. Sommige effecten zullen niet werken, sommige bugs zullen je blijven lastig vallen en laten me niet beginnen met beveiligingsproblemen .
U maakt het leven moeilijk voor ontwikkelaars omdat u of uw systeem weigert een nieuwere browser te gebruiken. En als ik enig advies heb om met mede-ontwikkelaars te delen, is het dat u dubbel of meer moet vragen voor degenen die vragen om een moderne web-app die nog steeds in IE 6 kan worden uitgevoerd. En het zou de moeite niet waard zijn .
8. De puntkomma-sleutel werkt niet
Verschillende programmeertalen JavaScript en PHP hebben de puntkomma nodig om het einde van een instructie te markeren. Het is als de periode of de volledige stop die een zin beëindigt.
Veel fouten gebeuren vanwege de ontbrekende puntkomma en u kunt zeker niet uw puntkomma-toets op uw toetsenbord laten werken. Overweeg om een reservetoetsenbord te hebben dat u kunt aansluiten om te gebruiken in geval van noodsituaties zoals dit.
9. Internet en Google is down
Als Google belangrijk voor je is in je werk of studie, weet dan dat het voor ontwikkelaars van dubbel belang is. Als webontwikkelaars gebruiken we Google om te zoeken naar codevoorbeelden, oplossingen te vinden voor fouten, samen te werken met collega's en meer.
Als internet en Google ten onder gaan, moeten we teruggaan naar een eerdere, geïsoleerde "periode van duisternis". We zitten vast, niet wetend wat we moeten doen als we bepaalde bugs tegenkomen. Grotendeels bewaart Google ons altijd. Dus, petje af voor de ontwikkelaars of programmeurs die dit deden vóór de leeftijd van het internet - ik buig voor je.
10. Je bent de expert (je kunt alles)
Om deze lijst met nachtmerries waar ontwikkelaars mee te maken hebben af te sluiten, laat ik je achter met deze YouTube-video genaamd The Expert van Lauris Beinerts. Je zult ontdekken hoe pijnlijk het is om de expert te worden.
Verder lezen
Voor een inside-look in andere vormen van freelancing of online banen, bent u misschien geïnteresseerd in:
- Gastbloggen: een redacteur vertelt u wat u verkeerd doet
- 10 Tekenen dat je te ver bent gegaan in freelance ontwerpen
- Freelance schrijvers: een kijkje in de wereld van freelance schrijven
- Bekentenissen van een webeditor - een inside-look
Een kijkje in: cohortanalyse in Google Analytics
Google Reports behoort tot de eenvoudigste, maar ook de meest gebruikte en effectief gebruikte analysetools voor veeleisende webmasters. Een van de recente rapporten die zijn toegevoegd onder Google Analytics, is het Cohort Analysis Report .Dit rapport is uitermate nuttig voor bedrijfseigenaren omdat het helpt om de essentiële feiten bloot te leggen die helpen om het klantgedrag te begrijpen en hoe ze te behouden om de winst te vergroten .
20 coole bioscopen met een geweldige filmervaring
De vroegste bioscopen werden geopend in 1900 en sindsdien doken er filmtheaters op in bijna elke stad ter wereld. Tegenwoordig hoeven we niet meer naar de bioscoop te gaan om een film te kijken, zoals we thuis kunnen doen. Hoe dan ook, hoe futuristisch filmisch plezier ook wordt, de goede oude bioscoopervaring zal nooit zijn charme verliezen.Er
