de Caleb Taylor

Calitățile marilor ingineri software

Calitatile care fac un mare inginer software

De-a lungul anilor, am observat câteva trăsături comune ale oamenilor care erau incredibil de valoroase pentru o companie. Acești ingineri erau deștepți, dar nu de aceea erau minunați. Au avut tendința de a face în mod constant anumite lucruri pe care mulți alți ingineri nu le-au făcut. Am captat unele dintre aceste calități și le-am rezumat în concepte pe care orice inginer le-ar putea folosi.

Declinare de responsabilitate: Acestea nu sunt întotdeauna lucruri ușoare de făcut. Personal, nu am reușit să obțin fiecare calitate la un moment dat în carieră. Consider aceste „principii directoare” pentru oricine dorește să fie un mare inginer, dar nu este o listă cuprinzătoare. Definiția dvs. de „mare” inginer poate diferi de a mea.

Antrenează-te să fii pompier

Când eram un tânăr inginer proaspăt, am primit prima mea lecție valoroasă de la managerul meu. El a spus,

„Dacă vrei să fii valoros pentru compania ta, fii persoana care aleargă spre incendii”.

Nu mă încuraja să mă arunc în foc (deși sunt sigur că meritam asta uneori), ci mai degrabă să fiu inginerul care era dispus – și capabil – să abordeze marile probleme.

„Incendiile” pot fi orice, de la o eroare de producție urâtă, până la un refactor descurajant al unui serviciu major. Nu toată lumea poate stinge aceste focuri. Primul pas este disponibilitatea de a aborda probleme dificile, dar nu este suficient. De fapt, trebuie să fii capabil să stingi focul.

Pregătirea pentru aceste momente mari nu este întotdeauna ușoară. Trebuie să vă dedicați înțelegerii arhitecturii și proiectării sistemului dvs. Cu cât un sistem este mai complicat, cu atât va dura mai mult.

Există câteva moduri pe care le-am găsit care mă ajută să mă pregătesc pentru a lupta împotriva incendiilor:

  • Crearea unui HLD (Design la nivel înalt) pentru aplicația / serviciul dvs.
  • Documentarea pieselor complicate din codul dvs.
  • Depanarea fluxurilor comune prin codul dvs. rând cu rând
  • Ați luat timp să vă scufundați în orice cod pe care îl întâlniți și pe care nu îl înțelegeți
  • Cercetează tehnologiile pe care echipa ta le folosește și devine expert

Când lucrați la sarcini individuale, căutați orice nu înțelegeți. Nu accepta lucruri care “doar munca”. De fiecare dată când vă atingeți codul, aveți șansa de a vă construi înțelegerea. De aceea antrenamentul pentru a fi „pompier” este atât de greu. Poate fi un efort obositor, zilnic, să fii pregătit pentru incendii.

Marii ingineri sunt oamenii care fac în mod constant acest gen de lucruri. Sunt dispuși să sară pe probleme pe care nu știu cum să le rezolve. Au tendința de a săpa mai adânc decât inginerul mediu, deoarece vor să înțeleagă cu adevărat lucrurile. Acest lucru nu are nicio legătură cu inteligența. Este o mentalitate.

La pachet: Dedicați-vă să dobândiți o înțelegere profundă a aplicației dvs. Când apar probleme grele, fii dispus să te scufunzi și să stingi focul.

Recunoașteți blocajele

De câte ori ați trăit o astfel de situație?

Dezvoltator A: „Voi implementa cea mai recentă modificare, bine? Odată ce actualizez manual fiecare fișier static și elimin setările de configurare locale, îl pot încărca ”.

Noul dezvoltator: „Așteptați, editați manual aceste fișiere de fiecare dată când implementați?”

Dezvoltatorul A: „Da, este o durere. De asemenea, am întrerupt producția de câteva ori când am greșit. Este destul de enervant. ”

Noul dezvoltator: „Acesta pare a fi un mod prost de a face implementări ..”

Dezvoltatorul A: „Da, ar trebui să remediem asta.

Din păcate, aceasta este o problemă destul de comună pentru echipele de software. Piesele importante sau obișnuite din fluxul de lucru al echipei dvs. sunt manuale, fragile și lente. Ocazional, echipa va recunoaște că este o problemă și o va remedia. Cel puțin, ar putea crea un card în restanțe.

Adevărata problemă este când nimeni nu recunoaște un blocaj

Deci, unde începi să cauți? Un bun punct de plecare este să ne gândim la automatizarea tuturor. Începeți cu cele mai critice sarcini pe care le efectuați manual. Echipa dvs. are teste pe care toată lumea le execută manual pentru fiecare cerere de tragere pentru a vă asigura că trec? De ce să nu conectați asta la un server CI, cum ar fi Jenkins sau Travis CI și afișați rezultatele direct în solicitarea de tragere cu cârlige web?

Membrii echipei dvs. petrec timp examinând stilul și formatarea codului? De ce nu vă scăpați automat codul folosind un cârlig Git pe fiecare commit cu un instrument de genul Husky și cu scame?

Acest tip de optimizări pot fi ușor de ratat. Echipele acceptă aceste puncte de durere ca „cum stau lucrurile”, mai degrabă decât ca candidați la optimizare. Marii ingineri tind să se gândească la aceste probleme. Au nevoie de timp pentru a le remedia, iar schimbările rezultate sunt victorii mari pentru întreaga echipă.

Am citit recent Accelerate: Știința software-ului Lean și DevOps: construirea și scalarea organizațiilor cu tehnologie performantă și am găsit că este o resursă excelentă. Oferă informații despre cele mai bune practici de inginerie și despre modul în care acestea afectează performanța și fericirea echipei. De asemenea, poate fi util pentru a justifica lucrul la blocajele echipei dvs. pentru conducerea companiei și pentru echipele de produse, cu date de la multe alte companii.

La pachet: Căutați blocaje în procesul de dezvoltare al echipei dvs. sau implementați o conductă. Faceți un efort pentru a stabili priorități și a remedia cele mai importante probleme pentru a îmbunătăți calitatea vieții echipei dvs.

Nu urmați în mod orb tiparele existente

Inginerilor le plac modelele. Mii de cărți există despre cele mai bune modele de programare și despre modul de utilizare. Din păcate, nu toate modelele de coduri ar trebui reutilizate.

Ocazional, am examinat o cerere de extragere și am găsit o secțiune de cod ciudată sau slab scrisă. Când întreb de ce a fost scris așa, răspunsul este de obicei același: „Așa se făcea înainte. Tocmai l-am copiat de altundeva ”.

Ruperea tiparelor vechi este primul pas în stabilirea altora noi

Tendința dezvoltatorilor de a copia codul existent este unul dintre cele mai mari motive pentru datoria tehnologică. Este ușor să permiteți aceste schimbări, deoarece arată ca un alt cod în producție.

Marii ingineri sunt foarte atenți la refolosirea codului existent. Acest lucru se aplică atât scrierii cât și revizuirii codului. Au tendința de a pune întrebările:

  • Codul copiat este cel mai bun mod de a rezolva problema?
  • Dacă este similar cu o bucată de cod existentă, ne putem combina într-un singur modul pentru a reduce duplicarea?
  • Există vreo eroare logică datorită diferențelor subtile dintre codul nou și cel existent?
  • Acest cod se potrivește cu cele mai noi standarde și discuții de proiect ale echipei mele?

Aceste principii se aplică, de asemenea, pentru actualizarea fragmentelor de cod mai vechi. Este foarte ușor să vă strecurați într-o schimbare de cod într-o secțiune de cod învechită sau slab scrisă, fără a remedia nimic, dar marii ingineri rareori fac asta. Ei tind să îmbrățișeze conceptul de refactorizare continuă.

Acest lucru nu înseamnă că fiecare actualizare a codului are ca rezultat un refactor masiv. Îmbunătățirile pot fi (și sunt de obicei) o varietate de lucruri simple:

  • Îmbunătățirea numelor variabilelor sau funcțiilor
  • Descompunerea unei funcții mari și complexe în funcții mai mici
  • Abstracția logicii copiate în mai multe locuri într-o componentă partajată

Marii ingineri se gândesc constant la modalități de îmbunătățire a codului și aproape întotdeauna lasă codul într-o stare mai bună decât au găsit-o.

Am citit recent cartea Refactoring: Îmbunătățirea proiectării codului existent de Martin Fowler și a considerat că este o resursă excelentă pentru refactorizare.

La pachet: Reevaluați în mod constant structurile, modelele și proiectarea codului. Copierea și lipirea codului este rădăcina tuturor răurilor. Lăsați întotdeauna codul într-o stare mai bună decât atunci când l-ați găsit.

Concluzie

Orice inginer software poate aplica aceste calități muncii lor. Poate fi dificil să faci în mod consecvent. Unele caracteristici necesită disponibilitatea de a merge mai departe în numeroasele fațete ale locului de muncă. Dacă sunteți dispus să lucrați la aceste calități, veți deveni un inginer software mai bun.

Această listă scurtă se bazează pe propriile mele experiențe, dar mi-ar plăcea să aud ce cred alții. Ce calități tind să aibă marii ingineri în experiența ta? Te rog anunta-ma!