Questo è qualcosa a cui sto pensando da quando ho letto questa risposta nel controverso thread delle opinioni sulla programmazione :
Il tuo compito è metterti senza lavoro.
Quando scrivi software per il tuo datore di lavoro, qualsiasi software che crei deve essere scritto in modo tale da poter essere raccolto da qualsiasi sviluppatore e compreso con il minimo sforzo. È ben progettato, scritto in modo chiaro e coerente, formattato in modo pulito, documentato dove deve essere, costruisce quotidianamente come previsto, verificato nel repository e opportunamente aggiornato.
Se vieni investito da un autobus , licenziato, licenziato o lasci il lavoro, il tuo datore di lavoro dovrebbe essere in grado di sostituirti in un attimo e il ragazzo successivo potrebbe entrare nel tuo ruolo, raccogliere il tuo codice ed essere in piedi e in esecuzione in una settimana al massimo. Se lui o lei non può farlo, allora hai fallito miseramente.
È interessante notare che ho scoperto che avere questo obiettivo mi ha reso più prezioso per i miei datori di lavoro. Più mi sforzo di essere usa e getta, più divento prezioso per loro.
Ed è stato discusso un po 'in altre domande, come questa , ma volevo sollevarlo di nuovo per discutere da un punto di vista più vuoto " è un odore di codice !! " - che non è stato davvero trattato in profondità ancora.
Sono uno sviluppatore professionista da dieci anni. Ho avuto un lavoro in cui il codice è stato scritto abbastanza bene per essere raccolto relativamente rapidamente da qualsiasi nuovo sviluppatore decente, ma nella maggior parte dei casi nel settore, sembra che un livello molto elevato di proprietà (sia individuale che di squadra) sia il norma. La maggior parte delle basi di codice sembra mancare della documentazione, del processo e dell '"apertura" che consentirebbero a un nuovo sviluppatore di prenderli e iniziare a lavorare con loro rapidamente. Sembrano sempre esserci molti piccoli trucchi e hack non scritti che solo qualcuno che conosce molto bene la base di codice ("la possiede") potrebbe conoscere.
Ovviamente, l'ovvio problema è: cosa succede se la persona esce o "viene investita da un autobus"? O a livello di squadra: cosa succede se l'intera squadra ottiene intossicazione alimentare quando escono durante il pranzo di squadra e muoiono tutti? Saresti in grado di sostituire il team con una nuova serie di nuovi sviluppatori casuali relativamente indolore? - In molti dei miei precedenti lavori, non riesco a immaginare che ciò accada affatto. I sistemi erano così pieni di trucchi e trucchi che "devi solo sapere ", che qualsiasi nuovo team che assumerai impiegherebbe molto più tempo del redditizio ciclo economico (ad esempio, nuove versioni stabili) per far ripartire le cose. In breve, non sarei sorpreso se il prodotto dovesse essere abbandonato.
Ovviamente, perdere un'intera squadra in una volta sarebbe molto raro. Ma penso che ci sia una cosa più sottile e sinistra in tutto questo - che è il punto che mi ha fatto pensare di iniziare questa discussione, dato che non l'ho mai visto discusso in questi termini prima. Fondamentalmente: penso che un forte bisogno di proprietà del codice sia molto spesso un indicatore del debito tecnico . Se nel sistema mancano processo, comunicazione, buona progettazione, molti piccoli trucchi e hack che "devi solo conoscere", ecc., Di solito significa che il sistema si sta progressivamente indebitando sempre più a fondo.
Ma il fatto è che la proprietà del codice viene spesso presentata come una sorta di "lealtà" verso un progetto e un'azienda, come una forma positiva di "assunzione di responsabilità" per il tuo lavoro - quindi è impopolare condannarlo apertamente. Ma allo stesso tempo, il lato del debito tecnico dell'equazione spesso significa che la base di codice sta diventando progressivamente meno aperta e più difficile da lavorare. E soprattutto quando le persone passano e i nuovi sviluppatori devono prendere il loro posto, il costo del debito tecnico (cioè della manutenzione) inizia a salire.
Quindi, in un certo senso, in realtà penso che sarebbe una buona cosa per la nostra professione se un alto livello di necessità di proprietà del codice fosse apertamente visto come un odore di lavoro (nell'immaginazione del programmatore popolare). Invece di essere visto come "assumersi la responsabilità e l'orgoglio" nel lavoro, dovrebbe essere visto più come "radicarsi e creare la sicurezza del lavoro artificiale attraverso il debito tecnico".
E penso che il test (esperimento mentale) dovrebbe fondamentalmente essere: cosa succederebbe se la persona (o davvero tutta la squadra) dovesse sparire dalla faccia della Terra domani. Sarebbe una gigantesca - forse fatale - lesione al progetto, o saremmo in grado di attirare nuove persone, far loro leggere i doccos e aiutare i file e giocare con il codice per qualche giorno - e poi tornare in affari in poche settimane (e ritorno alla piena produttività in circa un mese)?