Drumul de la senior developer la arhitect

Trecerea de la Senior Developer la Software Architect nu este doar o promovare ierarhică, ci o schimbare fundamentală de mentalitate. În practică, acest pas înseamnă că responsabilitatea ta se mută de la „cum scriu codul” la „ce construiesc și de ce”. Ca arhitect, vei fi evaluat nu doar pe calitatea implementării, ci pe deciziile strategice care afectează scalabilitatea, costurile și mentenabilitatea sistemului pe termen lung. Este crucial să înțelegi că rolul tău este de a reduce incertitudinea tehnică pentru echipă și de a alinia soluțiile tehnice cu obiectivele de business.

Concepte cheie

• Luarea deciziilor tehnice (TAD): Procesul structurat de a evalua opțiuni, documenta raționamentul din spatele alegerilor și de a gestiona riscurile asociate fiecărei direcții.
• Abstracție și modularizare: Capacitatea de a izola complexitatea în module bine definite, permițând dezvoltatorilor să lucreze independent fără a cunoaște detaliile interne ale celorlalte componente.
• Non-Functional Requirements (NFRs): Specificarea cerințelor non-funcționale precum latența, throughput-ul, disponibilitatea și securitatea, care sunt adesea mai critice decât funcționalitățile propriu-zise.
• Trade-offs: Conștientizarea faptului că fiecare decizie tehnică implică sacrificii (de exemplu, consistența vs. disponibilitatea în bazele de date distribuite) și alegerea celei mai bune compromisuri pentru contextul dat.
• Viziune pe termen lung: Anticiparea evoluției sistemului, planificarea refactorizării și asigurarea că arhitectura actuală poate suporta creșterea viitoare fără a necesita o rescriere completă.
• Comunicare cu stakeholderii: Traducerea constrângerilor tehnice în termeni de business accesibili pentru manageri, product owneri și clienți, pentru a gestiona așteptările realistice.

Exemplu practic

Imagină-ți că trebuie să alegi între o bază de date SQL (relațională) și una NoSQL (document-based) pentru un sistem de e-commerce care are nevoie de tranzacții financiare stricte și rapoarte complexe, dar și de flexibilitate în catalogul produselor.

# Decizia arhitecturală: Hybrid Approach
# Se folosește PostgreSQL pentru comenzi și plăci (consistență ACID)
# și MongoDB pentru catalogul de produse (flexibilitate schema)

class OrderService:
    def __init__(self, db):
        self.db = db # Conexiune la PostgreSQL

    def create_order(self, user_id, items):
        # Tranzacție atomică garantată
        with self.db.transaction():
            order_id = self.db.insert("orders", {"user_id": user_id})
            for item in items:
                self.db.insert("order_items", {"order_id": order_id, **item})
        return order_id

În acest scenariu, arhitectul a decis să nu folosească o singură tehnologie. A ales consistența puternică pentru datele critice (bani) și flexibilitatea pentru datele variabile (produse), explicând acest trade-off echipei prin beneficiile de mentenabilitate și performanță.

Greșeli frecvente

1. Over-engineering: Crearea de arhitecturi excesiv de complexe (microservicii, event sourcing) pentru probleme simple care ar putea fi rezolvate cu un monolit bine structurat.
2. Ignorarea costurilor operaționale: Alegerea unor tehnologii care necesită infrastructură scumpă sau personal specializat greu de găsit, fără a justifica ROI-ul.
3. Lipsa documentației deciziilor: Luarea deciziilor critice verbal sau mental, ceea ce duce la pierderea contextului istoric și la refacerea aceleași greșeli de către noi membri ai echipei.
4. Detalierea excesivă: Tinderea de a specifica implementarea la nivel de cod în loc de a defini interfețe și contracte clare, limitând libertatea dezvoltatorilor.

Întrebări de interviu

Întrebare: Cum ai aborda decizia dintre a dezvolta o soluție custom și a integra un serviciu third-party? Răspuns: Evaluez costul de dezvoltare vs. cel de mentenanță pe termen lung. Dacă logica de business este unică și oferă avantaj competitiv, o dezvolt custom. Dacă este o problemă generică (ex: autentificare, plată), integrez un serviciu existent pentru a accelera time-to-market.

Întrebare: Ce faci când echipa de dezvoltare respinge o decizie arhitecturală pe care ai luat-o? Răspuns: Ascult argumentele tehnice ale echipei. Dacă respingerea se bazează pe riscuri reale de performanță sau mentenabilitate, sunt dispus să revizuiesc decizia. Comunicarea deschisă și dovezi concrete (benchmark-uri) sunt esențiale pentru a ajunge la un consens.

Exercițiu

Alocă 45 de minute pentru a proiecta arhitectura unui sistem simplu de rezervare a locurilor la cinema.

1. Identifică entitățile principale (Film, Salar, Loc, Rezervare).
2. Alege o tehnologie de stocare și justifică alegerea prin 2 argumente (ex: consistență vs. viteză).
3. Desenează (sau descrie textual) fluxul unei rezervări, punând accent pe gestionarea concurenței (două persoane cumpără același loc simultan).
4. Scrie un scurt rezumat (maxim 100 de cuvinte) al trade-off-urilor principale ale alegerilor tale.