La proprietà del codice è un codice olfattivo?

27

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ì)?

    
posta Bobby Tables 19.06.2011 - 01:47
fonte

5 risposte

33

Penso che dobbiamo fare la differenza tra la proprietà del codice:

  • dal punto di vista della responsabilità,
  • dal punto di vista del codice stile / hack, ecc.

Il primo deve essere incoraggiato. Se nessuno è responsabile per codice e bug di bassa qualità, accadranno cose brutte . Ciò non significa che il bug relativo al tuo codice deve essere assegnato ogni volta a te: se il codice è scritto correttamente, chiunque può correggere il bug in qualsiasi parte del codice. Ma se non hai alcun feedback sui bug che fai, producerai gli stessi bug ancora e ancora .

La proprietà del codice può aiutare molto sia i manager che gli sviluppatori, specialmente gli sviluppatori. Se so che l'80% dei bug nel prodotto erano nel mio codice mentre eravamo tre sviluppatori che lavoravano al progetto e che il 75% di questi bug erano legati a SQL Injection, sarei più attento a scrivere codice la prossima volta, e fare uno sforzo in più per scrivere correttamente le query del database.

Il secondo (proprietà del codice dallo stile del codice / hack, ecc.) è in gran parte una cosa negativa. Cosa porta al prodotto? Non aumenta la qualità del prodotto, ma riduce l'uniformità del codice sorgente e rende difficile mantenerlo ultimamente .

Per molti progetti di grandi dimensioni, le persone non rimangono per sempre lavorando allo stesso codice. E qui, non parlo nemmeno di cose orribili come lo sviluppatore che viene investito da un autobus: non penso che la proprietà del codice sia la prima preoccupazione in questo caso. Ma molti pensieri minori accadono: le persone migrano dallo sviluppo alla direzione o ad altri lavori, o scelgono altri progetti, o lavorano su altre cose, o iniziano a usare un'altra lingua (se in un progetto sono usate più lingue), ecc.

Un pezzo di codice di un progetto può anche essere riutilizzato in un altro progetto, e lo sviluppatore che lavora su questo altro progetto vorrebbe modificare alcune parti del codice per adattarsi alle nuove esigenze, senza chiedere consiglio all'ex scrittore del codice.

È un odore di codice? Beh, dipende da cosa intendi per odore di codice. Per me, tutto riguarda la coerenza generale del progetto e la corretta gestione . In un buon progetto,

    Le linee guida sullo stile del codice
  • sono applicate per aiutare a comprendere meglio il codice più tardi,
  • gli sviluppatori più esperti non violano il principio KISS, aiutando quindi la comprensione del codice sorgente in seguito dai colleghi meno esperti.

Per concludere, la proprietà del codice deve essere monitorata tramite il controllo della versione, ma non devi essere in grado di dire che un pezzo di codice è stato scritto da te o da qualcun altro in un team .

    
risposta data 19.06.2011 - 02:12
fonte
9

Per prima cosa dobbiamo definire cos'è la "proprietà del codice".

Quando un pezzo (parte) di codice è nel processo iniziale di sviluppo, spesso è necessario designare una o due persone come "proprietari" perché:

  • All'inizio non ci sono specifiche o requisiti chiari e gli sviluppatori dovranno raccogliere informazioni per conto proprio. C'è un intervallo di tempo tra la raccolta e la documentazione di tali risultati.
  • Evita modifiche in conflitto quando la parte di codice viene attivamente modificata.
  • I "proprietari" sono le persone che possono segnalare lo stato di avanzamento dello sviluppo della funzione.

Normalmente c'è un singolo proprietario per ogni attività. I doppi proprietari sono possibili con la programmazione Pair. Non sarebbe pratico farlo senza una "proprietà del codice" strettamente designata.

Nota:
Si prega di consultare la risposta di MainMa per gli altri problemi durante sviluppo. In questi casi, la "proprietà del codice" è un sintomo di problemi più grandi, ovvero: scelta dell'architettura non ottimale, incongruenza dello stile di codifica e generalmente mancanza di qualità del codice.

Una volta che un pezzo è stato scritto e accettato nella base di codice ("done"), viene visualizzata la domanda più generale di "code-ownership".

  • Chi è l'esperto che può rispondere a tutte le domande su questo pezzo di codice / questa parte di funzionalità?
  • Questa conoscenza è stata catturata in artefatti tangibili, come documenti sui requisiti, test unitari, test di accettazione, log delle modifiche, wiki del progetto, ecc.?

Ci sarà sempre una parte della conoscenza del dominio (comprensione tacita dei requisiti dei clienti, problemi di compatibilità con sistemi arcani, ecc.) che sono difficili da formalizzare in specifiche scritte. Pertanto, quando si verifica un evento di calamità, è necessario prevedere una perdita di conoscenza del dominio.

Oltre alla perdita di conoscenza del dominio, perderai anche i rispondenti esperti che possono spiegare i dettagli del sistema. In questo aspetto, la perdita dell'esperto è una cosa universalmente negativa. La conoscenza dovrebbe essere stata acquisita in precedenza.

Questo non significa che l'esistenza di "esperti" sia negativa: considerare gli esperti come "cache" della conoscenza scritta. Gli esperti possono spesso rispondere alle domande più velocemente di dover cercare e digerire la conoscenza scritta.

Tuttavia, a volte "la proprietà del codice" si riferisce alle barriere create dagli sviluppatori attivi di un progetto per impedire agli estranei di modificare il codice.

  • Chi può apportare modifiche a questo pezzo di codice?
    • Per correggere bug ovvi?
    • Per fare in modo che il codice soddisfi alcuni altri requisiti?
    • Per riscrivere completamente il codice a proprio gusto?

Ci sono buone barriere e cattive barriere:

  • Buone barriere
    • Conoscenza del dominio - quanto bene comprendi i requisiti e lo stile di architettura / codifica
    • Capacità di programmazione e progettazione: hai le competenze per migliorare la progettazione e la qualità del codice del progetto
  • Cattive barriere
    • Non eri parte del team di sviluppo originale, quindi non ti è consentito apportare modifiche.
    • Sono permessi solo i bugfix. I miglioramenti delle funzionalità non sono i benvenuti.

In questo caso, il privilegio di modificare il codice sorgente di altri progetti non dovrebbe essere basato sulla proprietà del codice, ma dovrebbe essere basato sul merito.

Infine, i risposta punti di @Graham Lee alla frammentazione della conoscenza e dell'architettura causata dalla dipartimentalizzazione.

In questo caso, "proprietà del codice" è uno dei sintomi della dipartimentalizzazione. Un secondo sintomo è la "mancanza di interesse nei progetti di altre squadre". Come organizzazione, i manager dovranno prendere provvedimenti per incoraggiare il trasferimento delle conoscenze e la collaborazione tra team e dipartimenti.

    
risposta data 19.06.2011 - 02:23
fonte
7

Più insidiosamente, alcune aziende (ho lavorato in una) organizzano la loro struttura di gestione attorno a team funzionali: gestisci gli sviluppatori di client Windows, gestisce il team di installazione, gestisce gli sviluppatori di backend e così via. Ciò non solo porta alla strong proprietà del codice che descrivi, ma lo incorpora come il modo in cui funziona l'azienda. Trasforma l'architettura del software in un bunfight politico.

Questo è un problema? È se l'architettura è - o diventa - non ottimale. È impossibile dire (ad esempio) che l'installer funzioni meglio o sia meno costoso da sviluppare se si trattasse solo di un caso d'uso del cliente, perché questo sta prendendo il controllo da una squadra e dal suo manager. Le divisioni tra i moduli funzionali sono diventate fatti sul modo in cui viene gestito il dipartimento di ingegneria e sono necessari molti cambiamenti per alterare questi fatti.

[BTW nel caso in cui la discussione sopra non chiarisca, la mia risposta alla tua domanda è sì. La proprietà del codice è un odore di codice, perché può fermare le persone intelligenti con buone idee, o anche solo le persone che sono disponibili quando ne hai bisogno, lavorando sul codice. Ovviamente avere dei controlli per fermare le modifiche capricciose è una buona cosa, ma se hai un ingegnere che può vedere come risolvere un bug e ha il tempo di farlo, non devi bloccare quell'ingegnere solo perché qualcun altro ha scritto il codice bug. ]

    
risposta data 19.06.2011 - 02:09
fonte
6

Affrontando la tua domanda da un punto di vista leggermente diverso, la proprietà del codice NON è un odore di codice. È invece una gestione e risorse odore .

Pensa a cosa significhi un odore di codice. È una metafora che ti dice quando guardi il tuo codice, che qualcosa non è del tutto corretto con il codice e / o il design del software, ma il problema potrebbe non essere così ovvio da essere in grado di mettere il dito su cosa il problema esatto potrebbe essere ma probabilmente hai una buona idea a prescindere. Nella tua casa, se qualcosa ha un cattivo odore, segui il tuo naso finché non trovi la fonte del problema, e poi fai qualcosa a riguardo. Allo stesso modo, se il codice ha un problema, lo si investiga e lo si cambia finché non diventa un problema minore o, come qualcuno potrebbe dire, bello o ben fatto .

La proprietà del codice d'altra parte può essere un problema serio. Suggerisce una mancanza di supervisione e un rischio che, se il proprietario del codice lascia, la conoscenza del codice e i problemi specifici che risolve non saranno più disponibili per l'azienda. Questo non ha nulla a che fare con il codice stesso. Fondamentalmente si riduce a una situazione di gestione del rischio allo stesso modo che ci porta a conservare i backup dei nostri dati, e si applica allo stesso modo alla proprietà delle attività o alla proprietà dei documenti in altre aree dell'azienda.

Penso che sia corretto descrivere altri problemi di business come odori , ma certamente non implicare quello solo perché c'è un odore , che ha specificamente a che fare con codice.

    
risposta data 06.02.2012 - 02:58
fonte
1

Definisco la proprietà del codice come una responsabilità personale per il codice che scrivi, con la consapevolezza che altri funzioneranno nel tuo codice in futuro . Se pensi alle cose in questo modo, avrai meno probabilità di scrivere un hack perché gli errori a) in quel modulo potrebbero essere ricondotti a te e b) i membri del team probabilmente avranno difficoltà a modificare il codice in futuro.

Ho scritto un post sul blog su questo alcuni mesi fa, dove ho sostenuto che senza la proprietà del codice, come lo definisco, un codebase spesso cade preda del Tragedia dei Comuni .

Secondo la tua definizione di proprietà del codice, sono d'accordo sul fatto che sia brutto avere un codice in cui solo l'autore può lavorare.

    
risposta data 06.03.2013 - 03:38
fonte