În acest articol, vă voi împărtăși zece lecții pe care le-am învățat din primul meu proiect ca dezvoltator de software autodidact. La acel moment lucram pentru o companie de consultanță, iar titlul meu oficial era inginer software. Proiectul la care am lucrat a fost o aplicație web pentru sectorul public.

Lecția # 1: învățați arhitectura cât mai curând posibil

La început, cea mai provocatoare parte a fost obisnuirea cu cantitatea de cod care a fost scris. Trebuie să fi existat cel puțin un milion de linii de cod până când am început! Acest lucru a devenit mult mai ușor după ce am aflat despre arhitectura pe care o foloseam. Îmi amintesc că eram confuz în legătură cu acest lucru la acea vreme.

Abia am făcut un curs accidentat arhitectură stratificată, oferit de companie, că am înțeles cu adevărat cum să navighez prin baza de coduri. Am avut o scurtă prezentare generală când am început, dar mi-aș dori să am o înțelegere mai bună mai devreme decât am făcut-o.

Lecția # 2: nu luați comenzi rapide cu arhitectura

La jumătatea timpului petrecut în proiect, am adăugat o mulțime de funcționalități noi. Am reușit să facem unele dintre acestea cu o tehnologie mai nouă. Deoarece încă nu înțelegeam cu adevărat valoarea arhitecturii pe care o foloseam, am decis să iau comenzi rapide. Acest lucru a ajuns să coste timp și resurse atunci când a trebuit să ne întoarcem și să le remediem.

Lecția nr. 3: nu subestimați valoarea contextului de afaceri

O parte importantă a proiectului este învățarea cerințelor afacerii. Am subestimat complet importanța acestui lucru pe toată durata proiectului. A fost o greșeală scumpă. Dacă nu înțelegeți contextul de afaceri al activității dvs., este foarte ușor să mergeți pe o cale greșită.

Lecția # 4: nu subestimați valoarea de a fi autodidact

Acest proiect mi-a permis să câștig multă încredere în abilitățile mele de dezvoltator. Cred cu tărie că, dacă aveți instrumentele potrivite, puteți deveni expert în orice.

Deși nu pretind că sunt expert, am material de învățare autodidactă a fost mai mult decât suficient pentru a mă pregăti pentru acest proiect. Rețineți – lista a fost mult mai scurtă când am început! Această revelație m-a inspirat să scriu Merita studiul?

Lecția # 5: scrieți teste rapide și ștergeți-le pe cele care devin învechite

Proiectul nostru a constat în multe teste. Am avut o suită de teste autonome care a efectuat teste unitare, teste de persistență și teste de integrare. Testele unitare au durat câteva minute, dar toate împreună au durat o oră întreagă! Mi-am dat seama că testele rapide sunt cele mai bune și nu are rost să te agățe de testele vechi care sunt învechite.

Lecția nr. 6: fii atent la consecințele comiterii mai puțin frecvente

Foloseam Subversiune pentru controlul versiunii noastre. Din păcate, codul pe care îl comiteam a fost automat înregistrat în depozit. Foarte rar am lucrat cu sucursale, deoarece costul oportunității părea să fie prea mare. Acest lucru a dus la comiterea codului mai rar. Încă am încercat să mă angajez frecvent, dar uneori aș rupe construcția – nu credeam că trebuie să investesc ora desfășurării testelor la nivel local.

Lecțiile # 7: scrieți teste fiabile – și nu uitați să le întrețineți

În plus, unele teste nu au fost întotdeauna verzi. Lucrau uneori, dar eșuau la fel de des. Acest lucru ar face ca construcția să fie roșie. Drept urmare, nu prea am apreciat valoarea unei construcții roșii. Uneori, construcția ar fi fost roșie zile întregi, deoarece cineva nu a observat că a fost rupt un alt test.

Lecția # 8: revizuiți codul cât mai curând posibil

În mod obișnuit, am avea un dezvoltator care scrie codul și un alt dezvoltator revizuiește codul. Am avut ocazii să le fac pe amândouă. Adesea, aș obține o caracteristică de dezvoltat. Înainte de a-l termina, mi s-ar da ceva de examinat. S-ar putea să treacă câteva zile până să ajung la recenzii.

Acest lucru a cauzat adesea dureri de cap, deoarece codul pe care îl examinam nu era același cu codul care fusese dezvoltat. Programare pereche ar fi evitat această problemă, dar nu așa am lucrat.

Lecția # 9: refactorizarea trebuie să fie însoțită de teste

Testele au fost introduse doar cinci ani în durata de viață a proiectului. Înainte de aceasta, toate testările se făceau manual. Acest lucru a însemnat că o mare parte din baza de coduri nu a avut nicio acoperire de test, ceea ce este periculos.

Personal, îmi place foarte mult ideea aplicării regula cercetașilor băieți a coda. În mod firesc, am avut tendința să refactorizez foarte mult. Dar, deoarece nu am avut acoperire de testare pentru tot ceea ce am refactorizat, am introdus uneori defecte în software-ul nostru.

Lecția # 10: dezvoltarea de software este un compromis între valoarea afacerii și excelența software-ului

Am folosit un Model V pentru procesul de dezvoltare software. Aceasta a inclus termene limită pentru dezvoltarea, testarea manuală și lansarea software-ului. Nu am avut timp nelimitat să dezvoltăm sau să examinăm codul pe care îl scrieam. În unele cazuri, aș petrece prea mult timp perfecționând codul, ceea ce nu ar oferi întotdeauna valoare afacerii.

Gânduri finale

Acest proiect a fost o experiență de învățare foarte valoroasă pentru mine. Sper că ai reușit să înveți și tu ceva din asta. Spuneți-mi în comentariile de mai jos dacă ați avut experiențe similare sau contrastante!


Inainte sa pleci… Vă mulțumim că ați citit articolul! Scriu despre experiențele mele profesionale și educaționale ca dezvoltator de software autodidact, așa că verificați blogul meu sau abonați-vă la buletinul meu informativ pentru mai mult conținut.

S-ar putea sa-ti placa si: