Combattere il debito tecnico come lo "sviluppatore più basso"?

Diciamo che lavori per un'azienda e quello che fai è sviluppare software per loro. Non hai idea del quadro generale o forse lieve. Quello che hai sono le attività assegnate tramite il sistema di localizzazione dei problemi. Ti vengono assegnati compiti, li fai funzionare nel modo in cui l'attività li descrive, li rimandi. Come aggiungere 2 numeri interi:

function add(a,b){return a + b;}

Ma in seguito, man mano che il progetto procede, noti che, man mano che adddiventa più complesso, ti rendi conto che avrebbe dovuto avere bisogno di una qualche forma di architettura, più di una semplice funzione che aggiunge parametri e restituisce un valore. Tuttavia, non lo sapevi. In primo luogo, tutto ciò di cui avevano bisogno era così semplice add. Non ti aspettavi che aggiungere diventasse così complesso.

Il progetto procede con più funzionalità, che non ti aspettavi di avere in primo luogo. E alla fine, continui ad accumulare hack e strato su strato di funzioni per evitare di rompere / riscrivere il codice esistente.

Come gestisci queste situazioni? Come combattere il debito tecnico come "lo sviluppatore più basso"?

Una precisazione:

• Sei il "implementatore", il più basso nella gerarchia.

• Vedi il problema, ma non hai voce in capitolo.

• Non sto quantificando il debito tecnico né cerco strumenti.

• Per quanto riguarda il terzo "duplicato"

  • Refactoring e riscrittura: sei bloccato per le tue attività. Non sei pagato per fare un extra.
  • Panoramica sull'architettura: conosci il sistema generale, ma non hai idea dell'architettura.
  • Blocco del codice: non la chiamata. Non sei un management.
  • Modularizzazione - Nessuna idea di architettura. I moduli cambiano quando cambiano i requisiti.
  • Test automatici: nessuno esiste.

Ogni volta che noti qualcosa del genere, inserisci un nuovo biglietto nel tuo sistema di localizzazione dei problemi.

Prendi l'abitudine di utilizzare il tracker dei problemi come strumento principale per comunicare cose del genere, perché da lì sarà facile scegliere, valutare e stabilire le priorità per i tuoi colleghi senior / lead / manager / chiunque sia responsabile del monitoraggio dei problemi nel tuo progetto .

Usa lo strumento giusto per il lavoro. Lo faccio sempre e consiglio vivamente di fare lo stesso.

Ad esempio, ecco un biglietto che ho creato circa un mese fa. Al completamento di una particolare funzione ho scoperto che il codice è diventato sostanzialmente più complicato di prima, ma non riesco a risolvere il problema entro la scadenza indicata per l'implementazione della funzione.

(I nomi delle funzioni, i biglietti e il codice utilizzati nel tracker reale sono oscurati, ma il testo viene copiato così com'è).

Riepilogo: semplificare la progettazioneParticularPieceOfCode

Descrizione:
Nel corso dell'implementazione secondo TICKET-12345, il codice relativo all'utilizzo ha ParticularPieceOfCodeaccumulato un po 'di complicazioni ed è diventato piuttosto difficile da leggere, comprendere e mantenere (vedere lo snippet di codice di seguito).

Trova un modo per semplificarlo.

Un esempio di codice che sarebbe desiderabile riprogettare può essere trovato in ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW il mio consiglio si applica indipendentemente dal "livello" che sei.

Lo sto usando al tuo livello attuale ("più basso") e lo sto usando ora che il mio livello è piuttosto lontano dal "più basso" e ho un "dire" soddisfacente come lo chiami, e lo userò sempre non importa cosa.

Basti pensare a questo, a nessun livello, non importa quanta autorità hai, semplicemente non c'è modo migliore.

Se "dici" ehi, abbiamo un problema , è solo un tintinnio aereo. E anche se il tuo capo / capofila è d'accordo e dice che hai ragione, abbiamo un problema , questo non cambia nulla - è solo il tintinnio dell'aria di nuovo, e non può essere nient'altro.

• ^{Potresti pensare che avere la tua voce scritta (ad esempio via e-mail) sarebbe meglio, ma se ci pensi, non lo è. Se il tuo progetto ha un'importante attività di posta, ciò che è stato scritto andrà perso e sarà dimenticato a lungo un mese dopo.}

Usa lo strumento giusto per il lavoro. Per il lavoro che descrivi, il tracker dei problemi è esattamente lo strumento giusto.

Si nota il problema, lo si inserisce nel sistema progettato per il monitoraggio di questi e si occupa di tutto il resto, nel miglior modo possibile, semplicemente perché è stato progettato per quello :

pacchetto software per computer che gestisce e mantiene elenchi di problemi , come richiesto da un'organizzazione ... comunemente usata ... per creare, aggiornare e risolvere i problemi segnalati dai clienti o anche quelli segnalati dagli altri dipendenti dell'organizzazione ... il sistema è simile a un " bugtracker " e spesso una società di software venderà entrambi e alcuni bugtracker possono essere utilizzati come sistema di tracciamento dei problemi e viceversa. L'uso coerente di un sistema di localizzazione di problemi o bug è considerato uno dei "tratti distintivi di un buon team di software" ¹ ...

Qualunque altro mezzo tu voglia scegliere per comunicare, avere un biglietto nel tracker ti renderà più semplice.

Anche se preferisci scuotere l'aria , dire "Vorrei discutere TICKET-54321 ..." rende un punto di partenza più solido di "Ascolta, vorrei parlare di un pezzo di codice che ho trattato qualche tempo fa ... "E puoi tranquillamente passare i riferimenti al ticket via mail: anche se la posta viene persa, il problema sarà ancora presente nel tracker, con tutti i dettagli di cui volevi raccontare.

Ciò che mi fa stare male riguardo al tuo scenario è esattamente quello che hai scritto nel titolo e più volte nel testo della domanda:

Sei lo sviluppatore più basso della catena

Perché questo punto è così importante? Bene, prima di tutto, e da un punto di vista puramente tecnico, hai certamente ragione. Vieni assunto come quello che chiami un "implementatore" di cose, un'ape operaia che agisce in base ai comandi dati.

Ma anche se sei lo sviluppatore più basso per quanto riguarda il rango, questo non è ancora del tutto giusto. La chiave qui è rendersi conto che stai solo percependo te stesso come lo sviluppatore più basso. Hai mai provato a superare quella percezione di sé e ad assumere la responsabilità di qualcosa ?

Prendere! Non aspettare, fino a quando qualcuno ti renderà responsabile.

• Vedi il problema, ma non hai voce in capitolo.
• Non sto quantificando il debito tecnico né cerco strumenti.
• Sei bloccato per i tuoi compiti. Non sei pagato per fare un extra.
• Non è la tua chiamata. Non sei un management.

In genere è esattamente il contrario: sei pagato di più e la tua opinione viene rispettata di più, una volta che dimostri di valere i soldi . È "do before have", non viceversa.

Quello che mi aspetto dalle persone all'interno del mio team è esattamente questo: un senso di responsabilità per il progetto o il prodotto che stiamo cercando di costruire e per tutti i processi relativi a tale sforzo. Ogni volta che qualcuno nel mio team mi colpisce assumendomi la responsabilità, ad esempio proponendo miglioramenti o anche meglio iniziare a migliorare le cose da solo, queste sono le persone che verranno promosse.

Per dirla in altro modo: nessuno promuove le api operaie, le persone che aspettano passivamente i compiti loro assegnati, mancano anche del più piccolo battito di iniziativa " perché non sono pagate per questo ", e infine si lamentano del fatto che non hanno mai avuto una possibilità.

Naturalmente, tutto questo dipende ancora dalla cultura della tua azienda, da ciò a cui Joel si riferisce nelle "Due storie" collegate da Arthur. Se i manager dell'azienda sono davvero così stupidi da impedire ai propri dipendenti di fare progressi, allora il rapporto di fluttuazione è probabilmente già molto elevato e potrebbe essere il momento di trarne delle conclusioni. Ma se così non fosse, il vero problema potrebbe essere dentro di te.

Sei un professionista. Il tuo datore di lavoro ti ha assunto per essere professionale. Quindi, tratta le tue preoccupazioni nello stesso modo in cui vorresti che i professionisti che assumi trattino le loro opinioni professionali . In particolare, ci si aspetta che altri professionisti apportino le ottimizzazioni e le correzioni necessarie lungo il percorso, a condizione che tali ottimizzazioni non aumentino inaspettatamente i costi.

Ad esempio, supponiamo che porti la tua auto da un meccanico per far sostituire una lampada. Il meccanico nota quattro cose:

1. Il filo che porta alla lampada è sfilacciato e pericoloso. Tuttavia, può essere tagliato senza aumentare notevolmente il costo. Ti aspetteresti che impieghi qualche minuto per tagliare il filo, possibilmente senza nemmeno accorgersene.
2. Un bullone è allentato. È totalmente estraneo, gli è capitato di vederlo. Sono 20 secondi del suo tempo per afferrare il guidatore necessario e stringerlo; quindi, ti aspetteresti che lo faccia.
3. Il telaio della lampada è incrinato, causando il tintinnio della lampada. È costoso da sostituire. E non è essenziale. Quindi, ti chiama per chiederlo - se dici "no", mette una raccomandazione scritta sul tuo riepilogo della visita.
4. C'è una buona quantità di liquido dei freni sotto la macchina. Dovrebbe, e potrebbe anche essere richiesto come professionista, per impedirti di usare l'auto finché non permetti a qualcuno di riparare la perdita.

Ognuno di questi scenari, e ne sono certo altri, hanno parallelismi nello sviluppo del software, specialmente se ti consideri un professionista di qualsiasi livello . Come professionista, con pochissime eccezioni, il tuo compito è quello di raggiungere l'obiettivo finale di migliorare il prodotto in un modo particolare in base alla tua comprensione professionale .

1. Se la correzione è banale, non correlata o meno, esegui la correzione.
2. Se la correzione non è banale e non è necessaria, formulare una raccomandazione formale utilizzando qualsiasi meccanismo formale di comunicazione / tracciamento dei problemi concordato.
3. Se è possibile stabilire se la correzione è necessaria per eseguire l'attività primaria, ma aumenterà inaspettatamente i costi, comunicare la modifica dell'ambito.
4. Se il problema identificato rappresenta una seria minaccia per il successo del progetto, chiarirlo. Formalmente. Se vi sono preoccupazioni etiche nel consentire che il problema non venga risolto (come nei sistemi sanitari, di emergenza o di trasporto), insistere sull'affrontare il problema prima della spedizione del prodotto (informare i media o le autorità se eticamente necessario).

Lo fai nello stesso modo in cui un impiegato in uno studio legale combatte comportamenti non etici, un lavoratore di fast food combatte comportamenti non salutari o un ufficiale di parcheggio combatte la corruzione della polizia.

1. Sii un buon esempio. Nella misura del possibile, produce un codice pulito e sensibile. Quando ti viene data una scelta, scegli quella che soddisfa i tuoi requisiti con meno svantaggi. (Essere consapevoli del fatto che il debito tecnico non è diverso dal debito ipotecario - il solo fatto di averlo non è necessariamente una cosa negativa.)
2. Comunica le tue preoccupazioni . Dovresti avere qualcuno, a capo del team o cliente o architetto, che ha la responsabilità effettiva della gestione del debito tecnico e dell'allocazione delle risorse della tua azienda. Quando vedi qualcosa che ritieni sia negativo, comunica loro la tua preoccupazione. Mettilo per iscritto (ad esempio, un'email) se non sei sicuro che capiranno, risponderanno e daranno credito per il tuo contributo.
3. Non stressarti. Il debito tecnico raramente provoca il fallimento del rapporto di lavoro di un'impresa. Finché hai comunicato le tue preoccupazioni e stai facendo il tuo lavoro, i problemi di arcitecture come il debito tecnico non sono letteralmente il tuo problema. Sì, possono interessarti, ma non sono più la tua preoccupazione di quanto la rielezione di uno sceriffo sia la preoccupazione di un ufficiale di polizia junior.

Nell'esempio che hai fornito, con una addfunzione che ha subito un completo creep di funzionalità, prenditi qualche minuto e traccia lo schema di ciò che potrebbe migliorarlo. Invialo a chiunque avresti bisogno dell'approvazione per implementarlo e vai avanti.

Supponendo che la tua azienda sia gestita da persone estremamente competenti e strutturata correttamente, la tua preoccupazione verrebbe indirizzata al progettista del sistema giusto per una decisione o ti verrebbe concesso un margine di manovra per attuare il tuo suggerimento. Come sviluppatore junior, mi preoccuperei più di sapere come funziona la tua impresa che di debito tecnico - e se conosci il primo, come gestire il secondo dovrebbe essere ovvio.

Non ho mai sentito parlare di un'organizzazione che non voleva che i suoi dipendenti partecipassero. Dici di essere pagato solo per svolgere le attività. Dubito sinceramente che tu abbia in mente i compiti giusti. Perché sei pagato per scrivere un buon software.

Assumiti questa responsabilità. Di 'di no ad aggiungere funzionalità se non puoi supportare la base. Consiglia il cliente con la tua esperienza. Premi i freni ora, prima che sia troppo tardi e devi buttare via l'intero progetto, perché non sarà più mantenibile.