Dezvoltatorii de software pentru începători de greșeli comuni realizează și cum să îl evitați

Fotografie de Fancycrave pe Unsplash

Am fost doar o lună în munca mea ca dezvoltator de software, proaspăt ieșit din facultate. Mă încălzeam pentru a contribui la echipa mea. Cumva, m-am prins având gânduri foarte interesante în timp ce parcurg baza de cod existentă. Echipa mea a construit această bază de cod de-a lungul unor luni și ani de efort.

Ca prima sarcină, am avut o mică soluționare a erorilor care ar ajuta la stabilizarea viitoarelor versiuni ale serviciului. Echipa mea mi-a explicat arhitectura serviciului și unde ne încadrăm în marea schemă a proiectului mai mare. Pentru mine am găsit unde trebuia adăugat / șters sau modificat codul pentru a remedia erorile.

Am început să sap prin baza de cod, majoritatea fiind create în ultimii doi ani. Fără standard, era codul moștenitor. Pe măsură ce mergeam din ce în ce mai adânc în ea, m-am trezit cu gânduri destul de profane. A spune că codul nu a fost plăcut din punct de vedere estetic, ar fi un mod ușor de a-l pune. Așa am reacționat la baza de cod a echipei mele:

Asta se naste !!!

Yuck, aici funcționează două sute de linii.

Cine a scris această prostie!

O, Doamne, există un bloc if-else în interiorul unui bloc if-else.

Acest cod este o mare mizerie păroasă! ef it.

Aceasta trebuie rescrisă de la zero.

Eram furioasă. În timp ce aveam aceste gânduri, o parte din mine mă întrebam, ar putea exista o cale de a înțelege toate acestea? Nu am știut unele lucruri pe care acești băieți seniori ai echipei mele care au scris majoritatea acestui cod. Am început să aflu.

L-am prins pe tipul senior din echipa mea pentru o discuție rapidă și am început să-mi arunc întrebările la el.

Din câte am știut după discuție a fost foarte iluminant pentru mine. Echipa era conștientă de faptul că codul avea unele probleme de întreținere. Cu toate acestea, baza de cod existentă a avut forma, din câteva motive. Pe măsură ce continua să-mi explice aceste motive, am putut vedea de ce are sens acest post.

Citiți mai departe pentru a afla răspunsul la motivul pentru care, atunci când solicitați unui dezvoltator de software calitatea codului la care lucrează, răspunsul implicit este: „Este o mizerie”. De asemenea, de ce construirea lucrurilor de la sol nu este o soluție în majoritatea cazurilor.

Codul este scris dintr-un motiv diferit

Majoritatea oamenilor noi în dezvoltarea de software, inclusiv eu, consideră că codul este scris pentru mașini. Gresit. Nada. A fost scris pentru oameni. Aparatul nu vede nici codul JavaScript pe care îl scrieți, tot ceea ce văd este o secvență de 0s și 1s. Și pe măsură ce serviciul pentru echipa mea a fost construit, au existat termene reale cu livrări care trebuiau livrate. Dezvoltatorii de software sunt deja impozitați foarte mental. Undeva în presiunea de a livra, punerea codului la funcție are prioritate decât scrierea unui cod super plăcut estetic.

O bucată mare de cod este mai ușor de scris și de explicat unui coleg dezvoltator în persoană, spre deosebire de a sări dintr-un fișier în altul pentru a înțelege lucrurile. Aceste decizii pot rămâne în jur pentru mult timp.

Codul de producție este testat în luptă

Echipa mea primește o mulțime de rapoarte despre incidente, care duc uneori la remedieri critice ale erorilor din cod. O eroare de gestionare a clauzei if-else aici, o încercare de prindere acolo și, dintr-o dată, întreaga bază de cod a crescut fire de păr. Așa începe ca baza de cod să devină mai dezordonată în ciuda celor mai bune intenții.

Acesta este exact motivul pentru care rescrierea codului de la început este o idee atât de naivă. Aceasta ar duce la eliminarea tuturor corecțiilor și îmbunătățirilor erorilor. Acestea au fost acumulate de-a lungul unor luni și ani, posibil de către un utilizator care are o problemă reală. Este posibil ca un dezvoltator să fi petrecut câteva ore pentru a remedia aceste erori odată ce au fost raportate.

Ceea ce funcționează este modul

În lumea afacerilor, unde pot exista clienți în funcție de produsul sau serviciul dvs. Nimănui nu-i pasă dacă codul dvs. este refactorizat în cea mai bună măsură posibil. Fiecare linie de cod este scrisă pentru a rezolva o problemă de afaceri. Întrebați-vă, ce valoare va crea eforturile dvs. de refactorizare? Probabil că nu, și s-ar putea ajunge să introducă mai multe bug-uri. În plus, este cea mai bună utilizare a timpului tău?

Antidotul

Primul pas este recunoașterea problemei. Problema era că ego-ul meu mă gândea că poate face o treabă mai bună decât acești dezvoltatori seniori, care nu știau clar cum să scrie codul nivelului producției. Acesta este un mod de a gândi foarte naiv și am fost ars de multe ori în trecut ca să-l evit acum.

Doar recunoscând prezența ego-ului tău, obții un avantaj uriaș față de acesta. Deodată, nu are unde să se ascundă. Recunoașterea problemei este un lucru și rezolvarea ei este alta. Mai jos este modul meu de a ocoli această reacție genunchi. Dacă aveți un alt mod, scrieți-l în secțiunea de comentarii.

Fii curioasă

Începeți să vă întrebați de ce!

De ce a fost scrisă această bucată de cod în acest fel? Cine a scris-o? Persoana respectivă este încă în preajmă și pot să-i întreb asta. Ce știu acești tipi că nu? Care este problema pe care o rezolvă această caracteristică?

De cele mai multe ori, veți fi surprinși de răspuns.

Dezvolta Smerenia

Aceasta nu este o sarcină dificilă. După toate probabilitățile, mai aveți sume imense de învățat indiferent de locul în care v-ați putea plasa pe scară.

Adoptarea unei mentalități de creștere este ceea ce mi-a permis să mă pun în starea de spirit corectă. M-a eliberat să pun întrebări fără teama de a părea prost. Când știi că nu ar trebui să cunoști toate răspunsurile, ci înveți toate răspunsurile, a pune întrebări devine doar o banalitate.

Concluzie

Este foarte ușor să crezi că modul tău de scriere a codului este cel mai bun, iar toți ceilalți le dovedesc. Întrebați trei persoane despre cum ar împărți un șir într-o serie de caractere și toți ar da trei moduri diferite de a o face. Probabil, toate sunt la fel de bune și se pot învăța ceva de la toți.

În ceea ce privește tratarea codului de calitate proastă, aruncarea acestuia nu este cu siguranță soluția. Un mod mai favorabil afacerilor ar fi să începi să mănânci elefantul o mușcătură la un moment dat și să-ți refaci drumul prin cod.