Trăim într-o perioadă ciudată, în care companiile de tehnologie schimbă numele tehnologiilor open source (și ale altor tehnologii în general) și își revind serviciile sub un brand sau un produs. Uneori ambele.

Recruitorul de resurse umane, care nu are nicio vină în acest sens, ia acest val și a început să trateze experimentele sau experiențele ca cunoștințe. Ar putea exista o istorie similară, imaginați-vă un inginer alimentar care lucrează pentru Pepsi. Apoi el/ea decide să intervieveze pentru Coca-Cola și întrebarea care i se pune este: „Ai avut vreo experiență în a face Coca-Cola?”. Desigur că nu. Inginerul are experiență în fabricarea băuturii, orice băutură. Indiferent de aromă!

Acum, despre industria tehnologiei, avem o listă de limbi, o listă de cadre, o listă de furnizori de cloud și o listă de instrumente. În general, vei folosi limbajul, pentru cadru, printr-un instrument și îl vei implementa într-un furnizor de cloud.

Un inginer de software senior nu a lucrat deja cu toate limbile existente, cu toate cadrele, folosind toate instrumentele și cunoașterea tuturor numelor de produse pe care le-au inventat furnizorii de cloud. AWS RDS este doar o bază de date, GCP Compute este doar o mașină virtuală și așa mai departe. Dar fișele postului de astăzi au întrebat despre: cunoașteți AWS? Ai programat deja în Rust înainte? Câți ani ai experiență în limba Go? Ai experiență în Flutter? Acestea sunt instrumente!

Un inginer de software senior cunoaște algoritmi, structuri de date și design de sistem. El/ea știe cum să optimizeze o aplicație monolitică pentru a descărca sarcini de lungă durată folosind cozi în funcții fără server, care nu este altceva decât un container cu programele de rulare potrivite pentru a rula acea bucată de cod. Nu contează furnizorul de cloud, nu contează limba sau chiar cadrul. Nu contează numele produsului. Poate, doar poate, ar putea fi AWS Lambda, dar nu este obligatoriu.

Din cauza acestei realități și a dezacordului meu cu privire la ceea ce devin fișele postului și cerințele, de asemenea, o persoană de HR care nu a înțeles aceste cerințe. Complez cunoștințele necesare pentru a fi un bun Senior Software Engineer, în 7 (șapte) categorii, fără mărci sau produse. În opinia mea, asta ar trebui să fie în fișele postului. Nu limbi, cadre, nume de produse sau instrumente specifice de marcă.

Primul - Linux (indiferent de distribuție).

Internetul este condus de Linux. Avem Linux pe aparate, pe servere, pe routere, pe switch-uri, pe senzori, încorporat în mașini conectate, în rezumat, în orice.

Un inginer de software senior ar trebui să știe cum funcționează nucleul, cum gestionează procesele, cum comunică procesele, cum funcționează virtualizarea, ce face un container izolat unul de celălalt, cum funcționează sistemele de fișiere, ce face ca un sistem să pornească și ce a rulat înaintea nucleului. preia. Cum să monitorizezi procesele într-un sistem Linux, cum să-l gestionezi și cum funcționează modelul de securitate încorporat în Linux. Acesta este minimul de bază.

2 - Cum comunică lucrurile?

Lucrurile comunică! Telefonul tău vorbește cu telefonul prietenului tău printr-o aplicație de mesaje. Browserul dvs. accesează Căutarea Google. Tableta dvs. accesează o foaie de calcul care este salvată într-o unitate stocată într-un furnizor de cloud utilizând un serviciu pentru a sincroniza modificările și a actualiza în timp real atât dumneavoastră, cât și colegul dumneavoastră, modificările în același timp.

Subliniind toate acestea, aveți aplicații, servere, protocoale, legături fizice și niște mașini întregi pe care le numim doar Internet ;-).

Un dezvoltator de software senior ar trebui să știe care sunt mașinile care trimit semnalul dintr-un punct al globului în altul. Cum are loc această comunicare pe bază de legătură cu legătură și modul în care mașinile transmit pachetul de la unul la altul până ajunge la destinație. De asemenea, ar trebui să știți care este sarcina utilă din interiorul pachetului și ce protocol transportă. Cum transportă acest protocol informații din aplicații. Și cum diferite aplicații au fugit în aceeași mașină fără a se scurge informații de la o aplicație la o altă aplicație. El/ea ar trebui să știe despre adresele IP și protocoalele de transport, cum ar fi TCP și UDP, și cum se face rutarea folosind acele protocoale.

Lucrul greu pe care ne bazăm cu toții este că: protocolul operator, cum ar fi TCP și protocolul de rutare, cum ar fi IP, funcționează! Și sarcina utilă dintr-un protocol de aplicație precum HTTP ajunge dintr-un punct în altul.

Un inginer software senior ar trebui să știe, de asemenea, cum HTTP transportă datele, găsește informațiile folosind URI și trimite informațiile corecte către clientul potrivit, sub o conexiune predeterminată, numită socket, care conectează clientul și serverul, folosind, de mai multe ori , diferite căi fizice pentru a livra pachete diferite.

Al treilea - Cum au rulat aplicațiile peste aceste procese

Calculatoarele sunt de uz general, astăzi putem programa un computer să facă practic orice, dar rulează un limbaj foarte greu de citit, care este conceput de producătorul procesorului, un cod de asamblare pentru acel model de procesor. Acesta este motivul pentru care avem compilatoare (și interpreți) pentru a traduce codul mai ușor de citit, cum ar fi Python, în codul de mașină. În realitate, nu este atât de simplu, putem avea o întreagă varietate de implementări de limbaj. Unele sunt bune pentru unele lucruri, altele sunt bune pentru alte lucruri. Uneori aveți nevoie de performanță, alteori trebuie să vă finalizați rapid proiectul, de exemplu. De asemenea, în același argument, unele programe rulează în unele sisteme operaționale, iar altele rulează în alt sistem operațional.

Să privim, de exemplu, cazul recent în care Apple folosește o arhitectură diferită pentru mașinile lor, dar puteți rula Python pe Windows cu un procesor CISC și, de asemenea, același cod Python pe o arhitectură ARM într-o mașină macOS. Această „magie” se datorează faptului că unele limbi sunt compilate, iar unele limbi sunt interpretate în timpul execuției. Și nu se oprește aici. Unele limbi sunt concepute pentru a trata datele ca pe un lucru dinamic, aceeași variabilă ar putea fi un număr și mai târziu în program se va schimba într-un cuvânt. Alte limbi au o paradigmă de tip puternic și o variabilă care este mai întâi declarată ca număr va fi întotdeauna un număr în program. Toate acestea pentru a spune că un dezvoltator de software senior înțelege toate acele diferențe și implicații din toate limbile diferite, chiar și atunci când el/ea însuși nu a codificat niciodată în limba respectivă.

Lucrul important de știut este că programul dvs. va rula într-un proces și va fi gestionat de sistemul operațional actual, nu este un program necinstiți care face tot ce vor. Sistemul operațional impune restricții precum memoria protejată și accesul limitat la alte procese și, în unele cazuri, și la sistemul de fișiere, fișierele de intrare-ieșire etc., trebuie să cunoașteți mediul în care vă aflați, ce revine la prima cunoaștere. pe care trebuie să-l aibă un dezvoltator de software senior.

4 - Cum există protocoalele de aplicație

Unii directori executivi, sau chiar ingineri, tind să evanghelizeze o tehnologie. Fiind un furnizor de cloud, sau un cadru, sau un limbaj, sau chiar un instrument. Dar, în realitate, au trecut câteva decenii de când standardizăm protocoalele de aplicație care rulează pe Internet. Avem HTTP, HTTPS, FTP, UDP, RTSP și altele. Poate că Protocol Buffer-urile (protobuf) care folosesc gRPC sunt noi, dar este foarte rar să vă faceți aplicația fără să folosiți unele dintre cele menționate anterior sau chiar să folosiți HTTP(S Maybe).

Un dezvoltator de software senior știe asta și știe că, indiferent de stiva tehnologică, acestea sunt limitate de limitările HTTP, aveți doar câteva VERB-uri și pentru o lungă perioadă de timp sunt folosite doar GET și POST. Indiferent dacă faceți „Aplicația în primul rând”, „În primul rând pe mobil”, „În primul rând pe web” sau „În primul rând pe desktop”, nu contează. Comunicați cu HTTP. Serverul dvs. web de bază se ocupă doar de un număr limitat de clienți conectați simultan. Aplicația dvs. monolitică Full-Stack nu se va scala. Dacă acesta este un MVP, este în regulă. Dar va trebui să te schimbi. Și se schimbă mult. Cu cât se iau mai multe decizii proaste, cu atât vei pierde mai mult timp încercând să creezi ceva imposibil de fezabil. Și un dezvoltator de software senior știe de la început că este imposibil, ascultă-l pe dezvoltatorul de software senior. Dacă el/ea a fost unul.

Nu îmbrățișați cultura corporativă conform căreia CTO este întotdeauna potrivit pentru director, directorul este întotdeauna potrivit pentru manager, managerul este întotdeauna potrivit pentru liderul tehnic, liderul tehnic este întotdeauna potrivit pentru inginer și inginerul nu. nu am nicio voce. El/ea va pleca.

Un inginer software senior bun cunoaște tehnologia de bază care se află în spatele stivei de tehnologie, el/ea nu se referă la hype sau ce folosește toată lumea. El/ea nu se convinge cu o prezentare video sau o prezentare pe pagina de promovare a stivei de tehnologie. El/ea știe ce face. Ce oferă tehnologia și ce nu este. Din nou, ascultați-l pe dezvoltatorul de software senior, dacă ați avut unul.

5 - Algoritmi și structuri de date

Credeți sau nu, există un număr limitat de moduri prin care datele ar putea fi tratate. Datele ar putea fi stocate, căutate, sortate, actualizate și distruse. Și există o singură modalitate de a reprezenta aceste date. Cu 0 și 1.

Modalitățile în care puteți stoca, găsi, organiza, modifica sau șterge date sunt deja definite. De exemplu, pentru a vă organiza, aveți arbori binari, liste legate, liste duble legate, tabele hash și încă câteva. Același lucru pentru stocarea, găsirea, modificarea și ștergerea.

Un inginer de software senior cunoaște acei algoritmi, cei mai complexi, cei mai eficienți, cei care folosesc mai multă memorie, cei care folosesc mai puțină memorie și așa mai departe. El/ea nu trebuie să cunoască deja un limbaj de programare, aceste concepte sunt predate chiar înainte de a codifica. Codarea este o manifestare a acestei cunoștințe. Dacă un dezvoltator de software senior cunoaște Swift și Python, dar nu cunoaște Rust, aceasta înseamnă NIMIC. Înseamnă doar că el/ea îl va învăța în câteva săptămâni. Pentru că codarea este o manifestare a cunoștințelor mai profunde, adică gândirea computațională și o mentalitate de rezolvare a problemelor. Și dacă el/ea este un Senior Software Developer, el/ea a folosit deja mai multe limbi. Orice limbă de care aveți nevoie este mai mult decât capabil să învețe și să o folosească, indiferent cât de ciudată ar fi, sau, aparent, dificilă.

Dacă un dezvoltator de software senior știe deja unele limbi (da, la plural), el/ea este senior și o nouă limbă nu va fi o problemă pentru el/ea.

6 - Cum se păstrează datele

La fel ca și algoritmii, există doar câteva soluții prin care datele ar putea fi stocate. Fiecare pentru un anumit lucru. Există zeci de ani de studiu asupra modului de stocare a datelor care sunt tranzacționale. Cu alte cuvinte, puteți garanta că, dacă returnarea de la comanda INSERT a returnat adevărat, vă puteți asigura că acele date sunt acolo indiferent de câte milisecunde după ce am cerut acele date sau dacă întregul centru de date a fost închis după aceea. Numim asta ATOMIC. Acestea sunt baze de date relaționale. De departe cel mai eficient mod de a stoca date și de a persista care există astăzi.

De asemenea, există alternative și voi vorbi despre încă două, stocarea în bloc și stocarea documentelor. Există un hype despre stocarea documentelor în zilele noastre, toată lumea pare să vrea să folosească o bază de date NoSQL, dar o bază de date NoSQL este exact ceea ce spune numele, o bază de date care nu se bazează pe tranzacții „see-quel” atunci când INSEREȚI lucruri în ea, nu există nicio garanție că datele au fost stocate. În cele din urmă, datele vor persista, dar nu știți cât timp după aceea. Se poate întâmpla ca, dacă aveți nevoie de o bucată de date imediat după inserarea sau actualizarea datelor respective, să primiți răspunsul vechi.

Un dezvoltator de software senior știe acest lucru și profită de acest lucru pentru scenarii în care nu aveți nevoie de tranzacțiile ATOMIC de citire imediată, iar documentele pot fi stocate și afișate numai când este gata, ca un flux de rețea socială. Dar nu într-un scenariu în care efectuați o tranzacție financiară pentru plată electronică și trebuie să vă asigurați că plata a fost efectuată în acel moment. Apoi trebuie să o faci într-o bază de date relațională. Din nou, indiferent de numele produsului pentru acest lucru în Google Cloud, AWS sau Azure. El/ea cunoaște tehnologia, indiferent de numele produsului.

Acum am puțin despre stocarea în bloc, Un inginer de software senior înțelege natura stocării, el/ea știe că în spatele scenei nu stocăm puțin, ci stocăm în blocuri, fișiere, baze de date (care sunt doar fișiere) , persistența sau chiar o „amintire” a limbii tale preferate, este în cele din urmă stocată în blocuri. Este mai ușor să stocați datele în blocuri și să le accesați ulterior folosind o hartă. Imaginați-vă că trebuie să citiți întregul disc de fiecare dată când avem nevoie de un fișier? De a citi o întreagă bază de date pentru a găsi datele de plată? Facem hărți și indexăm lucruri. Ne uităm la acele indici ca un cititor care caută într-o pagină rezumată din cartea sa preferată pentru a ne aminti ce pagină are citatul său preferat. Acest rezumat are blocurile importante în care sunt stocate datele, apoi sărim acolo.

7 - Cum este proiectat software-ul

Nu în ultimul rând, Un Inginer Software Senior știe cum este construit software-ul, bucată cu bucată, el/ea știe care este prioritatea și ce nu. El/ea înțelege care sunt bazele a ceea ce se construiește și va ajuta echipa să înțeleagă că unele părți ale software-ului ar putea fi realizate după. El/ea are nevoie doar de câteva minute cu proprietarul produsului pentru a înțelege care sunt software-ul și cum ar putea fi evoluat. Sigur, a evolua înseamnă a te schimba, dar asta e complet ok. Ceea ce nu este în regulă este că, în mijlocul proiectului, unii CEO răzuiesc tot codul și vor să o ia de la capăt. Acesta este doar cazul unei schimbări uriașe în compania însăși. Dar să construiești același produs, dar cu o stivă tehnologică diferită, doar pentru că este inadmisibil.

RUP este un gunoi, nimeni nu-l mai folosește, este exact ca și cum spui că pornești motorul cu manivela. Nu a lucrat niciodata si nu o va face niciodata. Companiile îl folosesc pentru că dacă spui că îl folosești, arăți cool.

Cazurile de utilizare, cerințele, artefactele, diagramele de clasă și diagramele de secvență sunt încă predate în universități, dar toate sunt degeaba. Pe care nu o vei folosi niciodată pentru nimic. Ați putea argumenta că cazurile de utilizare sunt bune pentru înțelegerea comportamentului clientului sau a actorului în cadrul programului, dar este mai ușor să aduceți clientul și să-l întrebați. Face o listă. Nu aveți nevoie de desene de persoane lipicioase pentru proiectul dvs.

La fel pentru ITIL, aruncați-l.

La fel și pentru modelele de capacitate, aruncați-le.

Un inginer de software senior cunoaște principiile manifestului Extreme Programming și le folosește.

Un inginer de software senior cunoaște principiile Scrum și le folosește.

Nu Jira, Nu Kanban, Nu un instrument... principiile. Un inginer software senior bun știe când nu este necesară o ceremonie Scrum. Și când o face.

Un inginer de software senior bun învață toate aceste concepte și când sunt amestecate într-un mod din care nici măcar el/ea însuși nu știa sau când învață acel concept. Atunci îl puteți considera un inginer de software senior. Și posibil, un Manager.

Inainte de a termina…

Nu sunt proprietarul adevărului, dacă aveți comentarii, sugestii sau corecturi despre acest text, vă rugăm să le distribuiți pe contul meu de Twitter „aici”.