Questo è qualcosa a cui ho pensato fin da quando ho letto questa risposta nel thread di opinioni controverse sulla programmazione :
Your job is to put yourself out of work.
When you're writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned.
If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment's notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can't do that, then you've failed miserably.
Interestingly, I've found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.
Ed è stato discusso un po 'in altre domande, come questo , ma volevo farlo di nuovo per discutere da un punto in più " è un codice di odore !! " punto di vista - che non è stato ancora trattato in profondità.
Sono uno sviluppatore professionista da dieci anni. Ho avuto un lavoro in cui il codice è stato scritto bene abbastanza da essere raccolto in tempi relativamente brevi da qualsiasi nuovo sviluppatore decente, ma nella maggior parte dei casi nel settore, sembra che un livello molto alto di proprietà (sia di proprietà individuale che di squadra) sia norma. La maggior parte delle basi di codice sembra mancare di documentazione, processo e "apertura" che consentirebbe a un nuovo sviluppatore di raccoglierle e di lavorare rapidamente con loro. Sembrano esserci sempre un sacco di piccoli trucchi e hack non scritti che solo chi conosce il codice base molto bene ("lo possiede") sarebbe a conoscenza.
Ovviamente, il problema ovvio con questo è: cosa succede se la persona esce o "viene investita da un autobus"? O a livello di squadra: cosa succederebbe se tutta la squadra si avvelenasse dal cibo quando usciva nel loro pranzo a squadre e muoiono tutti? Sareste in grado di sostituire la squadra con un nuovo gruppo di nuovi sviluppatori casuali relativamente senza dolore? - In molti dei miei precedenti lavori, non riesco a immaginare che possa succedere. I sistemi erano così pieni di trucchi e hack che " devi solo sapere ", che qualsiasi nuova squadra che assumi richiederebbe molto più tempo del ciclo economico redditizio (ad esempio, nuove versioni stabili) per ottenere cose andando di nuovo. 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 questo thread, perché non l'ho mai visto in questi termini prima. In sostanza: ritengo che un elevato bisogno di proprietà del codice sia molto spesso un indicatore del debito tecnico . Se c'è una mancanza di processo, comunicazione, buon design, un sacco di piccoli trucchi e hack nel sistema che devi "sapere", ecc. - di solito significa che il sistema sta progressivamente assumendo un debito tecnico sempre più profondo.
Ma il fatto è che la proprietà del codice viene spesso presentata come una sorta di "lealtà" nei confronti di un progetto e dell'azienda, come una forma positiva di "assunzione di responsabilità" per il proprio lavoro, quindi è assolutamente impopolare condannarlo. Ma allo stesso tempo, il lato del debito tecnico dell'equazione spesso significa che il codice base sta diventando progressivamente meno aperto e più difficile da gestire. E soprattutto quando le persone passano e i nuovi sviluppatori devono prendere il loro posto, il costo del debito tecnico (cioè la 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 bisogno per la proprietà del codice fosse visto apertamente come un odore di lavoro (nell'immaginazione popolare del programmatore). Invece di essere visto come "assunzione di responsabilità e orgoglio" nel lavoro, dovrebbe essere visto più come "trincerarsi e creare sicurezza artificiale del lavoro attraverso il debito tecnico".
E penso che il test (esperimento mentale) dovrebbe essere essenzialmente: cosa succederebbe se la persona (o addirittura tutta la squadra) dovesse svanire dalla faccia della Terra domani. Sarebbe un danno gigantesco - forse fatale - per il progetto, o saremmo in grado di portare nuove persone, convincerle a leggere i doccos e ad 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 un mese o giù di lì)?