Analyse van veelgemaakte fouten van beginnende programmeurs, pt. 1

Hallo Wereld! Als je eenmaal alles hebt geleerd wat je moet weten en eindelijk aan de slag kunt als stagiair of junior ontwikkelaar, kun je waarschijnlijk ontspannen, toch? Nee. Alles begint nog maar net voor jou... Je wordt omringd door veel dat nieuw en onbegrijpelijk is. Hoe verpest je het niet recht uit de poort? Daar gaan we het vandaag over hebben. In dit artikel wil ik veelvoorkomende beginnersfouten analyseren en wat advies geven, gebaseerd op mijn eigen ervaring, over hoe je ze kunt vermijden. Dus laten we beginnen zonder verder oponthoud:

1. Angst om hulp te zoeken bij meer ervaren collega's

We zijn allemaal mensen. We zijn allemaal bang om dom over te komen, vooral in de ogen van onze nieuwe, meer ervaren collega's. Wanneer ontwikkelaars hun eerste baan aannemen, worden ze vaak geleid door deze angst en trekken ze zich met een zwaar gehoor terug in zichzelf en proberen ze alles zelf uit te zoeken. Bovendien kan iemand worden omringd door meer ervaren collega's, die hem of haar op hun beurt in de meest veelbelovende richting kunnen wijzen, waardoor meer fouten en onnodige "stoten op het hoofd" worden voorkomen. Dus onthoud: wees niet bang om vragen te stellen. Je bent een beginner en iedereen begrijpt dit heel goed. Als je het vraagt, zal niemand je met stokken slaan. Misschien gebeurt zelfs het tegenovergestelde: u raakt sneller bevriend met uw collega's en begint actiever met hen te communiceren. I' Ik zeg nog meer: ​​hoe meer je verschillende technische kwesties vraagt ​​en bespreekt, hoe sneller je je groene beginnershuid kunt afwerpen en kunt uitgroeien tot een expert in je vakgebied. En nog een advies. Wees geen vreemde voorStackOverflow . Ik heb het specifiek over het stellen van vragen over deze bron. Aan de ene kant kost het wat tijd om antwoord te krijgen op je vraag. Maar aan de andere kant leer je misschien snel meerdere benaderingen om je probleem op te lossen en bekijk je het vanuit een iets andere hoek. Ik wil ook opmerken dat er praktische voordelen zijn aan het schrijven van commentaar/antwoorden en het schrijven van verhelderende vragen over StackOverflow-vragen van andere ontwikkelaars: je krijgt de kans om te debatteren en dieper in de problemen te duiken, om nog maar te zwijgen van een karma-boost.

2. Niet zelf proberen naar informatie te zoeken

Deze fout kan worden beschouwd als de keerzijde van de vorige.Hier bedoel ik wanneer je je collega's en kennissen begint lastig te vallen met elk probleem of elke hapering die je tegenkomt. Vragen is goed, maar overdrijf niet met vragen. Anders kunnen mensen je gewoon vervelend vinden. Als u ergens over in de war raakt, is het eerste wat u moet doen uw zoekvaardigheden oefenen in de beste zoekmachine - Google. Iemand anders is de overgrote meerderheid van onbegrijpelijke fouten en andere problemen al tegengekomen. En je zult behoorlijk verrast zijn als je je vraag googelt en ziet hoeveel mensen bekend zijn met een soortgelijk probleem, en die al uitputtende antwoorden hebben gekregen die je kunt toepassen in je eigen werk. Daarom hoor je je collega's vaak antwoorden met "Google it". Maffiabaas' Wees niet beledigd door dit antwoord - uw collega is niet uw persoonlijke leraar die alle subtiliteiten van uw werkveld moet overbrengen. De eindeloze uitgestrektheid van internet zal je mentor zijn. Soms worden programmeurs ook wel genoemdmensen met een zwarte band in Google zoeken . Dus als we een "hik" hebben, googelen we eerst het probleem. Als er geen oplossing kan worden gevonden (dit is zeldzaam, maar het gebeurt), pas dan gaan we collega's vragen. Directe vragen zijn bedoeld om advies te krijgen over welke aanpak u moet kiezen om een ​​probleem op te lossen, meer dan wat u zou doen als u een verkeersdrempel of een onbegrijpelijke foutmelding tegenkomt. Ze kunnen immers verder kijken dan uw voorkeursaanpak en onmiddellijk voorspellen waar een bepaalde aanpak op de lange termijn toe zal leiden.

3. Blind kopiëren en plakken

Maar het googelen van problemen en hun oplossingen heeft zijn valkuilen. Bijvoorbeeld blindelings kopiëren en plakken .Dit gebeurt meestal wanneer u een soortgelijk probleem vindt (maar misschien niet precies hetzelfde) en een bijbehorende oplossing, bijvoorbeeld op StackOverflow. Je pakt deze oplossing en kopieert en plakt deze zonder verder in de details te duiken. En dan ontdekken u of uw collega's vreemde bugs of onjuist gedrag in uw code. En niemand kan meteen raden waar ze vandaan kwamen. Uiteindelijk zal natuurlijk de plek met de gekopieerde code worden gevonden en zul je zeker niet geprezen worden om je oplossing. Daarom moet u, wanneer u een kant-en-klare oplossing op StackOverflow (of ergens anders) vindt, eerst het wat, hoe en waarom grondig begrijpen. Google misschien de relevante functionaliteit en lees de documentatie ervoor. En pas nadat je dat hebt gedaan, moet je het aan je project toevoegen.

4. Vasthouden aan de verkeerde oplossing

Bij het schrijven van een oplossing zul je soms merken dat het steeds ingewikkelder wordt en uiteindelijk op een dood spoor uitloopt. En dan probeer je de oplossing nog uitgebreider te maken om het op de een of andere manier te laten werken in plaats van op zoek te gaan naar een ander, geschikter alternatief. Misschien heb je het gevoel dat je veel tijd en moeite hebt geïnvesteerd en daarom hebt besloten dat je hoe dan ook niet zult opgeven en het probleem met je bestaande aanpak zult oplossen. Dit is niet helemaal de juiste houding. Althans in de programmering. Hoe eerder je een andere aanpak probeert, hoe meer tijd je uiteindelijk bespaart. Wees dus niet bang om te experimenteren en andere benaderingen uit te proberen, ongeacht de hoeveelheid tijd die je in je huidige hebt geïnvesteerd. Bovendien, door meerdere benaderingen te proberen en dieper in het onderwerp te duiken, kun je'

5. Angst om vragen te stellen over je huidige opdracht

Werken aan een softwareontwikkelingsproject komt meestal neer op het uitvoeren van specifieke taken. Bijvoorbeeld in Jira. Deze taken zijn niet altijd duidelijk en gedetailleerd beschreven. Taakbeschrijvingen worden meestal geschreven door teamleiders, die ook gewone stervelingen zijn. Ze vergeten misschien iets toe te voegen of houden geen rekening met het feit dat u niet bekend bent met deze of gene functionaliteit. Of misschien heeft u geen toegang tot het project (bijvoorbeeld toegang tot de database, de logserver, enzovoort). En nu heb je de opdracht ontvangen, meer dan een paar uur bestudeerd, maar je zit daar nog steeds verbijsterd naar het scherm te staren. In plaats van tevergeefs te blijven proberen dit te begrijpen, zou je moeten beginnen om opheldering of begeleiding te vragen aan degene die de taak heeft gemaakt. In de app die je team gebruikt voor communicatie (bijvoorbeeld Microsoft Teams), kun je bijvoorbeeld vragen stellen of een directe opmerking maken over de taak. Enerzijds, als je je vraag in een persoonlijk bericht schrijft, krijg je waarschijnlijk sneller antwoord, aangezien de persoon je vraag meteen ziet. Aan de andere kant, door een vraag te stellen in Jira, stel je bewijs vast dat je iets doet, namelijk het analyseren van het probleem. Er is een manier om dit proces te versnellen: stel je vraag in een reactie in Jira en vervolgens in een DM, plaats een link naar je opmerking en vraag om een ​​kijkje te nemen.

6. Onrealistisch hoge verwachtingen stellen aan de teamleider

Nogmaals, dit is de keerzijde van het vorige punt. De teamleider is het hoofd van een ontwikkelteam. In de regel besteedt uw teamleider het grootste deel van zijn of haar tijd aan verschillende vormen van communicatie. Maar hij of zij schrijft ook code om niet alles over programmeren te vergeten. Zoals u begrijpt, is het leven van een teamleider erg druk. Elke keer dat je moet niezen aan de mouw van je teamleider trekken, is natuurlijk niet prettig. Stel je voor dat elk lid van het team de leiding bombardeert met een heleboel vragen. Dat kan iedereen gek maken, toch? En als je veel vragen krijgt, zal je teamleider veel tijd moeten besteden om je te beantwoorden. Wat kan er gedaan worden om het aantal vragen aan de teamleider te verminderen:

• Verdiep je in de projectdocumentatie om het aantal blinde vlekken te verminderen.
• Stel je vragen aan je andere teamleden. Ze zijn misschien net zo bekend met deze functionaliteit als de lead, of mogelijk zelfs meer, aangezien de functionaliteit hoogstwaarschijnlijk door een van hen is geschreven.

Als alternatief kunt u de annotaties in de IDE bekijken voor wie en wanneer de code in een specifieke regel voor het laatst is gewijzigd. Precies zo kom je erachter wie de meest geschikte persoon is om je vraag te stellen. Zoals u waarschijnlijk al beseft, moet u bij vragen aan de teamleider, net als bij vragen aan collega's, een gulden middenweg proberen te vinden — wees niet bang om vragen te stellen, maar stel ook niet te veel vragen. van hen.

7. Angst voor codereviews

Een codereviewis zo'n fase die plaatsvindt voordat u uw code indient bij een algemene toepassing (naar een gedeelde branch, bijvoorbeeld master of dev). Deze controle wordt uitgevoerd door een ontwikkelaar die niet betrokken is bij de taak, wiens frisse ogen fouten, onnauwkeurigheden of gebreken in uw codestijl kunnen detecteren die onopgemerkt bleven toen u uw code voor het eerst schreef. Als er kritiek is, worden deze achtergelaten als commentaar op bepaalde delen van de code. In dit geval moet de ontwikkelaar die de code heeft geschreven de fouten corrigeren die in de beoordeling zijn geïdentificeerd (of zijn beslissingen met de recensent bespreken en hem of haar mogelijk ervan overtuigen dat ze correct zijn). Vervolgens wordt de code keer op keer ter beoordeling ingediend totdat de beoordelaar geen opmerkingen meer heeft. De recensent fungeert als een "gateway" voordat de code wordt vastgelegd. De uitdaging is dat veel beginnende programmeurs codereview zien als kritiek en veroordeling. Ze stellen codereviews niet op prijs en zijn er bang voor. Dat zouden ze niet moeten doen. Codebeoordelingen zijn precies wat ons in staat stelt onze code te verbeteren. We krijgen immers belangrijke informatie over wat we fout doen en waar we op moeten letten. U moet elke codebeoordeling beschouwen als onderdeel van de leercurve, iets dat u kan helpen beter te worden. Wanneer iemand commentaar geeft op uw code, deelt hij of zij ervaringen en best practices met u. Persoonlijk geloof ik niet dat je een goede programmeur kunt worden zonder codebeoordelingen te krijgen. Want je bent je niet eens bewust van de kwaliteit van je code en of een ervaren buitenstaander op fouten zou wijzen. Ik waardeer codereviews niet en ben er bang voor. Dat zouden ze niet moeten doen. Codebeoordelingen zijn precies wat ons in staat stelt onze code te verbeteren. We krijgen immers belangrijke informatie over wat we fout doen en waar we op moeten letten. U moet elke codebeoordeling beschouwen als onderdeel van de leercurve, iets dat u kan helpen beter te worden. Wanneer iemand commentaar geeft op uw code, deelt hij of zij ervaringen en best practices met u. Persoonlijk geloof ik niet dat je een goede programmeur kunt worden zonder codebeoordelingen te krijgen. Want je bent je niet eens bewust van de kwaliteit van je code en of een ervaren buitenstaander op fouten zou wijzen. Ik waardeer codereviews niet en ben er bang voor. Dat zouden ze niet moeten doen. Codebeoordelingen zijn precies wat ons in staat stelt onze code te verbeteren. We krijgen immers belangrijke informatie over wat we fout doen en waar we op moeten letten. U moet elke codebeoordeling beschouwen als onderdeel van de leercurve, iets dat u kan helpen beter te worden. Wanneer iemand commentaar geeft op uw code, deelt hij of zij ervaringen en best practices met u. Persoonlijk geloof ik niet dat je een goede programmeur kunt worden zonder codebeoordelingen te krijgen. Want je bent je niet eens bewust van de kwaliteit van je code en of een ervaren buitenstaander op fouten zou wijzen. wat u verkeerd doet en wat de moeite waard is om op te letten. U moet elke codebeoordeling beschouwen als onderdeel van de leercurve, iets dat u kan helpen beter te worden. Wanneer iemand commentaar geeft op uw code, deelt hij of zij ervaringen en best practices met u. Persoonlijk geloof ik niet dat je een goede programmeur kunt worden zonder codebeoordelingen te krijgen. Want je bent je niet eens bewust van de kwaliteit van je code en of een ervaren buitenstaander op fouten zou wijzen. wat u verkeerd doet en wat de moeite waard is om op te letten. U moet elke codebeoordeling beschouwen als onderdeel van de leercurve, iets dat u kan helpen beter te worden. Wanneer iemand commentaar geeft op uw code, deelt hij of zij ervaringen en best practices met u. Persoonlijk geloof ik niet dat je een goede programmeur kunt worden zonder codebeoordelingen te krijgen. Want je bent je niet eens bewust van de kwaliteit van je code en of een ervaren buitenstaander op fouten zou wijzen.

8. Neiging tot geheimzinnige beslissingen

Verschillende taken/problemen kunnen vaak meerdere verschillende oplossingen hebben. En van alle beschikbare oplossingen hebben beginners de neiging om de meest complexe en geheimzinnige te gebruiken. En dat is logisch: beginnende programmeurs hebben gisteren nog veel verschillende algoritmen, patronen en datastructuren geleerd, dus hun handen jeuken om er enkele te implementeren. Geloof me, ik was zo, dus ik weet waar ik het over heb :) Ik had een situatie waarin ik lange tijd een bepaalde functionaliteit implementeerde. Het bleek heel, heel ingewikkeld te zijn. Toen herschreef senior ontwikkelaar mijn code. Natuurlijk was ik erg geïnteresseerd om te zien wat en hoe hij het veranderde. Ik keek naar zijn implementatie en was verbaasd over hoeveel eenvoudiger het was. En er was drie keer minder code. En ook verbazingwekkend genoeg zijn de geautomatiseerde tests voor deze functionaliteit niet verwijderd of gewijzigd! Met andere woorden, de algemene logica bleef hetzelfde. Hieruit kwam ik tot de conclusie datde meest ingenieuze oplossingen zijn altijd eenvoudig . Na dit besef werd coderen veel eenvoudiger en sprong mijn codekwaliteit naar een aanzienlijk hoger niveau. Wanneer is het dan de moeite waard om ontwerppatronen en fraaie algoritmen toe te passen, vraagt ​​u zich af? Wanneer ze worden toegepast, is dit de eenvoudigste en meest compacte oplossing.

9. Het wiel opnieuw uitvinden

Het wiel is een duurzame oplossing die lang geleden is uitgevonden. In dit antipatroon implementeert de ontwikkelaar zijn of haar eigen oplossing voor een probleem dat al is opgelost. Soms zijn deze bestaande oplossingen beter dan wat de programmeur bedenkt. In de regel leidt het opnieuw uitvinden van het wiel tot tijdverlies en verminderde productiviteit, omdat de oplossing die u vindt misschien verre van de beste is, of u vindt er misschien helemaal geen. Dat gezegd hebbende, kunnen we de mogelijkheid niet uitsluiten om onze eigen onafhankelijke oplossing te creëren: als we dat zouden doen, rest ons alleen nog het kopiëren en plakken van de programmering. De programmeur moet zich goed laten leiden door de specifieke programmeertaken die zich voordoen om deze competent en snel op te lossen, hetzij door gebruik te maken van kant-en-klare oplossingen, hetzij door aangepaste oplossingen te creëren. Aan de ene kant, op universiteiten en in online cursussen worden we gebombardeerd met verschillende soorten taken die ontworpen lijken om ons te helpen het wiel opnieuw uit te vinden. Maar alleen op het eerste gezicht: het echte doel hier is het ontwikkelen van algoritmisch denken en een diepere beheersing van de taalsyntaxis. Dergelijke taken helpen je ook om algoritmen en datastructuren beter te begrijpen, en geven je vaardigheden om, indien nodig, meer geavanceerde tegenhangers te implementeren (dit is soms nodig, maar het is buitengewoon zeldzaam). In het echte leven hoeft u in de overgrote meerderheid van de gevallen uw eigen wiel niet uit te vinden, aangezien wielen die aan uw behoeften voldoen al lang bestaan. Misschien verhindert uw onervarenheid dat u op de hoogte bent van het bestaan ​​van implementaties van de functionaliteit die u nodig heeft. Dit is waar u het advies in het eerste punt van dit artikel moet nemen, namelijk: vraag meer ervaren collega's om hulp. Ze kunnen u helpen (bijvoorbeeld in de juiste richting wijzen in uw Google-zoekopdracht) of een specifieke implementatie voorstellen (bijvoorbeeld een bibliotheek).

10. Het niet schrijven van tests

Alle nieuwkomers houden niet van schrijftoetsen. Maar waarom zouden we hier nieuwkomers uitkiezen? Meer doorgewinterde ontwikkelaars schrijven ook niet graag tests, maar ze begrijpen beter waarom tests nodig zijn. Als je helemaal groen bent, vraag je je af waarom je ze zou moeten schrijven. Alles werkt, dus er kunnen geen fouten in zitten. Maar hoe zorg je ervoor dat je wijzigingen niet ergens anders in het systeem kapot gaan? Je collega's zullen het niet op prijs stellen als je veranderingen doorvoert die meer kwaad dan goed doen. Dit is waar tests ons te hulp schieten. Hoe meer de code van een applicatie wordt gedekt door tests, hoe beter (dit wordt codedekking of testdekking genoemd). Als de applicatie een goede testdekking heeft, kunt u alle tests uitvoeren om plaatsen te vinden die door uw code worden verbroken. En zoals ik al zei in het bovenstaande voorbeeld, toen de senior ontwikkelaar de code herwerkte, faalden de tests niet. Dit kwam doordat de algemene logica niet veranderde. We gebruiken tests om aan te tonen of de logica van bepaalde functionaliteit is veranderd of niet. Dus zelfs als je niet van het schrijven van toetsen houdt, zijn ze zeker nuttig en de moeite waard om eraan te besteden.

11. Overmatige opmerkingen

Veel ontwikkelaars hebben last van perfectionisme, en nieuwkomers vormen daarop geen uitzondering. Soms manifesteren ze slechts één facet van deze neiging wanneer ze commentaar beginnen te geven op alles en iedereen. Zelfs opmerkingen maken die overbodig zijn, omdat de code zo voor de hand ligt:

Cat cat = new Cat(); // Cat object

Niet alle beginnende programmeurs realiseren zich meteen dat commentaarcode niet altijd goed is, omdat de overbodige commentaren de code onoverzichtelijk maken en moeilijk leesbaar maken. En wat als de code verandert, maar de oude commentaren niet worden bijgewerkt? Dan zullen ze ons alleen maar misleiden en verwarren. Waarom maak je dan überhaupt zo'n opmerking? Gewoonlijk hoeft goedgeschreven code niet te worden becommentarieerd , aangezien alles erin al duidelijk en leesbaar is. Als je een opmerking moet schrijven, heb je de leesbaarheid van de code al bedorven en probeer je de situatie op de een of andere manier te verhelpen. De beste benadering is vanaf het begin leesbare code te schrijven, dwz code die geen commentaar nodig heeft. Ik kan ook niet anders dan de noodzaak noemen om de juiste naamgevingsconventies voor methoden, variabelen en klassen te volgen. Hier is mijn regel: De beste opmerking is geen opmerking of een correcte naamgeving die de functionaliteit in uw toepassing duidelijk omschrijft.

12. Slechte naamgeving

Nieuwkomers spelen snel en losjes in het benoemen van klassen, variabelen, methoden, enz. Bijvoorbeeld door een klasse te maken waarvan de naam het doel helemaal niet beschrijft. Of ze declareren een variabele met een korte naam, zoiets als x . Ze hebben nog twee variabelen genaamd n en yworden gemaakt, wordt het erg moeilijk om te onthouden waar x verantwoordelijk voor is. Geconfronteerd met deze situatie, moet je goed nadenken over de code, deze analyseren onder een microscoop (misschien met behulp van een debugger), de functionaliteit bestuderen om eenvoudig te begrijpen wat er gebeurt. Dit is waar de juiste naamgevingsconventies die ik hierboven noemde ons te hulp komen. Correcte namen verbeteren de leesbaarheid van de code, waardoor de tijd die nodig is om vertrouwd te raken met de code wordt verkort, omdat het gebruik van een methode veel gemakkelijker is wanneer de naam de functionaliteit ervan ongeveer beschrijft. Alles in code bestaat uit namen (variabelen, methoden, klassen, objecten, bestanden, enz.), dus dit punt wordt erg belangrijk bij het maken van correcte, schone code. U moet onthouden dat de naam betekenis moet overbrengen, bijvoorbeeld waarom de variabele bestaat, wat deze doet, en hoe het wordt gebruikt. Ik zal meer dan eens opmerken dat de beste opmerking voor een variabele is om hem een ​​goede naam te geven. Voor een diepere studie van commentaren en correcte naamgeving raad ik aan om de tijdloze klassiekers te lezen:"Clean Code: A Handbook of Agile Software Vakmanschap" door Robert Martin . Wat dat betreft is het eerste deel van dit artikel (mijn reflecties) ten einde. Wordt vervolgd...