Waarom ik 😍 beoordelingen codeer

♬ Luister naar dit verhaal of lees het

Ik ben nu bijna 5 jaar een professionele iOS-ontwikkelaar en ik kan eerlijk zeggen dat ik mijn passie heb gevonden. Een van mijn favoriete aspecten van softwareontwikkelaar zijn, is dat we een open geest moeten hebben en constant moeten leren.

Ik ben begonnen met iOS-ontwikkeling tijdens mijn masteropleiding in Oostenrijk. Wat ik toen deed, waren vooral een aantal kleine studentenprojecten, niet echt gericht op kwaliteit. Daarna ben ik gaan werken in een startup, als junior developer. Het was een geweldige kans. Ik was de enige die aan het project werkte, dus voor een junior, niet zo’n grote uitdaging als het op kwaliteit aankwam.

Nadat ik mijn studie had afgerond, ben ik naar Duitsland verhuisd en ben ik fulltime gaan werken als iOS-ontwikkelaar. Hier was het team groter en had het processen, standaarden en een sterke focus op het bouwen van kwaliteitssoftware. Ik vond het fascinerend.

Hier kwam ik voor het eerst codebeoordelingen tegen. Ik geloof dat dit een van de belangrijkste bronnen was voor mijn professionele groei en een van de belangrijkste drijfveren voor het koesteren van mijn passie en toewijding. Ik werk nu als Senior iOS-ontwikkelaar en ik schrijf een groot deel van mijn vooruitgang toe aan deze praktijk.

Waarom ik denk dat coderecensies geweldig zijn:

Je leert de waarde van opbouwende kritiek

Bij mijn eerste contact met codebeoordelingen en pull-verzoeken was dit het moeilijkste om te accepteren.

Om iemand te hebben die je niet eens persoonlijk kent (sommige van mijn collega’s werkten op afstand), zeg dan dat allerlei dingen over je code moeilijk waren :). We leren dat kritiek betekent dat je iets slechts hebt gedaan, een fout hebt gemaakt. En we hebben de neiging het persoonlijk op te vatten, ons beledigd te voelen, ons niet goed genoeg te voelen.

Dit is een houding die elke teamgenoot nodig heeft om over te komen. Om kritiek niet persoonlijk op te vatten, maar als een suggestie om beter te worden en constant te verbeteren.

Het kostte me veel tijd om aan de opmerkingen te wennen. Soms kwam ik helemaal aan het einde van een functie en zei de opmerking: “Waarom heb je dit gedaan?” “Hoe flexibel is dit?” “Kunt u een diagram van uw oplossing tekenen?”

Stel je voor dat je helemaal opnieuw moet beginnen 😫. Gooi dagen of weken werk weg.

Eindelijk, na een paar maanden, raakte ik eraan gewend en kon ik zelfs de oplossingen van mijn collega’s uitdagen en mogelijke verbeteringen in hun pull-verzoeken beginnen te vinden. Ik was veranderd Ik begon goed te worden in dit recensie-materiaal 🙂

Na nog een paar maanden verliet mijn collega op afstand het bedrijf. Het team is wat kleiner geworden sinds er nieuwe projecten binnenkwamen en we moesten splitsen. Ik had niemand meer om mijn oplossingen in twijfel te trekken. Op dat moment besefte ik hoe belangrijk het is om iemand te hebben die je code constant uitdaagt. Hij was mijn mentor en ik heb het me niet eens gerealiseerd.

Na een tijdje ga je ook jezelf uitdagen. Maar dit werkt niet altijd .. Soms ben je moe of gewoon lui en zou je kunnen besluiten om een ​​kortere weg te nemen .. Misschien besluit je het uitdagende deel helemaal over te slaan.

Daarom is het zo belangrijk om in een team te werken dat erop gericht is het beste uit alles, elke functie en elke regel code te halen.

Omarm de kritiek en waardeer de mensen die je uitdagen om te groeien. Het zal het grootste verschil maken. Ik geloof dat dit advies van toepassing is op alles in het leven en zolang we feedback en kritiek kunnen ontvangen, zullen we niet stoppen met groeien.

Ontwikkel een opbouwende kritiekcultuur in uw team en waardeer deze het meest. Het zal de grootste voordelen opleveren

Het helpt bij het verspreiden van kennis binnen het team

Door alle leden van het team de code te laten beoordelen voordat deze wordt samengevoegd, raakt iedereen vertrouwd met alle delen van het project.

Vooral voor grotere functies of modules maken teamrecensies veel verschil. Iedereen is in staat het nieuwe deel van de applicatie te begrijpen, hun zorgen te delen, misschien verbeteringen voor te stellen en het er uiteindelijk over eens te zijn dat dit de beste manier was om het te implementeren.

Het is ook een van de beste manieren om iemand die nieuw is in het team te helpen begrijpen hoe u werkt.

Je mag terugkijken op je code en gaan “What the f ** k ???”

Dit is misschien mijn favoriete onderdeel. Wanneer je een ouder project opent dat je hebt geschreven en je jezelf niet herkent. Dat is het grootste bewijs van groei! Het is een heel fijn gevoel om te beseffen dat je zoveel vooruitgang hebt geboekt dat je jezelf niet eens herkent in de dingen die je vroeger schreef.

Ik denk dat dit alleen kan worden bereikt als het team een ​​sterke beoordelingscultuur heeft. We zijn niet in staat om onszelf uit te dagen en te twijfelen zoals iemand anders zou doen. Dit brengt echte verandering, tastbare vooruitgang.

Het is een springplank naar teambrede standaarden

Codebeoordelingen zijn ook een plek waar discussies over normen beginnen te plaatsvinden. Iedereen heeft een mening en iedereen in het team is zijn eigen persoon. Maar als team is er een gemeenschappelijke basis die u kunt bereiken via normen. Iedereen is het erover eens en iedereen houdt zich eraan.

Het is niet eenvoudig om de normen te definiëren. In het begin weet je niet eens wat je moet standaardiseren. Codebeoordelingen kunnen daarvoor de basis vormen, omdat het een manier is om de verschillende meningen binnen het team te communiceren.

Naamgevingsconventies, opmaak, foutafhandeling, logboekregistratie, speciale gevallen, opmerkingen, documentatie. Ze kunnen allemaal worden geëxtraheerd, stap voor stap met behulp van de beoordelingen.

De uitvoer zal een uniforme codebasis van hoge kwaliteit zijn

Als je eenmaal een basisset van standaarden hebt, zal de code er hetzelfde uitzien, ongeacht wie deze heeft geschreven. Dit betekent dat het hele project gemakkelijker te lezen, te begrijpen en te debuggen is.

Omdat iedereen code schrijft volgens dezelfde regels, zul je zien dat alle code door jou geschreven is. Dit zal de manier waarop en het bedrag waarmee het team het project begrijpt, verbeteren.

Doordat het team elke regel code in twijfel trekt (min of meer: ​​D), kunt u er zeker van zijn dat de statische analyse de kwaliteit van uw applicatie aanzienlijk verbetert.

Je leert van je teamgenoten

Jullie zitten allemaal in één team omdat jullie allemaal geweldig zijn. Wat nog beter is, is dat je elkaar kunt aanvullen.

Er is misschien iets waar je niet aan hebt gedacht of iets dat je toevallig over het hoofd hebt gezien. Iemand in uw team kan u eraan herinneren of het weer onder uw aandacht brengen. We hebben allemaal onze blinde vlekken

Wat geven we terug?

Meestal bestaat er niet zoiets als een perfecte oplossing.

Dus wat moeten we opofferen voor al deze voordelen?

Het voor de hand liggende antwoord is tijd. Het is een inspanning om code te herzien, vooral als je het goed doet, dus het kost tijd.

Ziet u de voordelen?

Als je alles in balans brengt, goed gedaan, zal deze praktijk je echt helpen tijd en geld te besparen op bugs en technische schulden.

Ik geloof echt dat codebeoordelingen een enorm verschil kunnen maken in het kwaliteitsniveau van een applicatie, wat betekent dat er minder bugs zijn, wat op zijn beurt betekent dat er minder tijd moet worden besteed aan het oplossen ervan, wat uiteindelijk tot geldbesparing leidt.

Codebeoordelingen ontwikkelen daadwerkelijk een bewustzijn van de geldigheid en kwaliteit van onze oplossingen als team. Zelfs als het uw eigen recensie is voordat u klaar bent of als het de externe recensie is, maakt het u bewust en waakzaam bij het zoeken naar betere, snellere en stabielere oplossingen.

Het is gemakkelijker om door het project te navigeren en misschien zelfs gemakkelijker om de onderdelen te herkennen die kunnen worden verbeterd.

Bedankt dat u de tijd heeft genomen om dit te lezen. Ik hoop dat je er net zo van genoten hebt als ik codebeoordelingen :). Laat me weten wat je ervan vond en aarzel niet om contact met ons op te nemen

Als je persoonlijke coaching wilt krijgen om je iOS-ontwikkelingsvaardigheden te krijgen en input van mij wilt krijgen over je meest urgente iOS-gerelateerde problemen, sta ik momenteel open voor het coachen van andere ontwikkelaars. Neem gerust contact op als u interesse heeft. Meer details hier: https://mobiledev.consulting/1×1-expert-coaching/

Mijn doel is om constant te leren en ik geloof dat er geen betere manier is om diepere inzichten te krijgen dan lesgeven en met anderen delen wat je weet. Daarom wil ik mijn expertise delen met elke mobiele ontwikkelaar die meer wil leren en zijn vaardigheden wil versterken.