Come affrontare le preoccupazioni dell'architetto del software ma mantenere ancora la proprietà collettiva del codice? [duplicare]

When you change a line of code in one component it usually breaks code in other components. ...if every developer was responsible for his own piece of code then he would tidy it up all the time because he would feel ownership over the component.

Quindi aspetta, se il problema è che l'aggiornamento del tuo componente interrompe il componente di qualcun altro (a causa di un'architettura dubbia che non ha un decoupling decente), com'è che il fatto che un componente sia posseduto da uno sviluppatore improvvisamente ferma qualcuno La componente di else si disfa magicamente in modo che non si rompa all'aggiornamento del primo!?!

L'unica risposta è organizzare correttamente i componenti in modo che non siano più intrecciati come al momento. Quello e documentando le interfacce e i contratti di dati tra di loro.

Sono d'accordo con la proprietà dei componenti in quanto può aiutare con la qualità di molto più del semplice codice, ma un sostituto è la revisione del codice - qualcuno dopo tutto deve sapere molto su ciascun componente al fine di far rispettare l'API e il comportamento corretto di esso. In questo caso, penso che le recensioni di codice siano solo un modo per implementare la proprietà in ogni caso.

Solo tre cose: recensioni di codici, recensioni di codici, revisioni di codice - ti aiuteranno a migliorare la qualità del codice e la sensazione di responsabilità per "il codice condiviso".

When you change a line of code in one component it usually breaks code in other components.

Scenario mondiale ideale: dovresti avere le tue API formalizzate e gli invarianti API testati nei test unitari. Se questo è coperto, quando uno sviluppatore apporta una modifica che tocca gli invarianti, i test falliranno. Quando uno sviluppatore apporta una modifica che interrompe i test unitari, dovrebbe prendere in considerazione l'aggiornamento del test dell'unità o l'aggiornamento della documentazione dell'API (e la rimozione del test dell'unità).

Our software architect blames this on collective code ownership.

No. Solo no. A quanto ho capito, è più un problema con tutti che modificano il codice ad-hoc, su più componenti contemporaneamente. Questo non è un problema con la proprietà del codice, ma con la metodologia del tuo team che non formalizza / rispetta i contratti API e le invarianti.

He believes that if every developer was responsible for his own piece of code then he would tidy it up all the time because he would feel ownership over the component.

Non è realistico. Se ho scritto un pezzo di codice e qualche altro sviluppatore lo rompe, non lascerò cadere quello che sto facendo per correggere i bug introdotti da detto sviluppatore (dato che ho i miei compiti e le mie scadenze).

In current situation developers change code in multiple components and they break other components either because they don't understand how the component works (because they work with so many components) or because they don't care about how their changes will affect the other clients of the component (as long as they are not affected).

Gli sviluppatori cambiano componenti multipli (e rompono le cose a caso) per far funzionare il loro codice corrente, significa mancanza di definizioni chiare / formali per le tue API (cioè a questo punto non c'è un'immagine chiara di ciò che il componente dovrebbe fare) e mancanza di una documentazione adeguata per le tue API (ovvero gli sviluppatori che inseriscono le funzioni per vedere cosa fa l'implementazione, invece di leggere la documentazione per questo).

What do you believe we should do to address the concerns of the software architect but still maintain collective code ownership?

• Formalizza le tue interfacce e documentale. Assicurati che la documentazione di un'API sia sempre accurata (se la tua funzione indica che un valore nullo genera una Mia eccezione generata, allora è meglio avere un test unitario che chiami l'API con un null e rilevi l'eccezione).

• Rinuncia a codifica dei cowboy e correzioni di "cinque minuti" a qualsiasi difetto. Non esiste una "soluzione rapida" a nulla. Una correzione dei difetti dovrebbe coprire tutti questi aspetti:

  • Redesign dell'API (questo viene fatto sulla documentazione, quindi sulla dichiarazione dell'API)
  • completamento test unità (aggiungi test unità per nuovo comportamento, rimuovi e modifica test unità per comportamento modificato, solo test unità remote per comportamento che non è più effettivo)
  • Modifiche all'implementazione API
  • tutti i test che passano

• assicurati la pulizia del codice e la pulizia delle diff (nessun codice morto commentato, nessun codice che è stranamente organizzato, ecc.)

La cosa più importante è che NON ACCETTO i commit pubblici con test non validi o che non hanno superato due round di revisione del codice (se una modifica causa test falliti, non è una correzione, è uno o più difetti introdotti). Due round di revisione del codice significano:

• revisioni delle recensioni dei revisori e fornisce un feedback allo sviluppatore
Lo sviluppatore
• esegue le modifiche in base al feedback delle recensioni
• il revisore esamina nuovamente le modifiche e concede l'approvazione / il rifiuto
• lo sviluppatore esegue le modifiche (dopo l'approvazione)

Idealmente, ogni difetto fisso avrà un nuovo test unitario aggiunto al sistema che controlla esattamente il comportamento descritto nel difetto.

Quando fatto in questo modo, una "cancellazione di cinque minuti" di una sola linea diventa una correzione di "30 minuti o più". In definitiva, questo non è tempo sprecato, è il tempo che impiegherete per implementare nuove funzionalità, invece di spendere tempo nel debugger.

La proprietà, collettiva o individuale, non cambierà il fatto che cambiare le cose rompe il codice in altri componenti.

Inizia ad aggiungere test unitari per tutto ciò che viene toccato. Se possibile, aggiungi dei test per alcuni (o tutti) i chiamanti di qualunque cosa tocchi. Questo (alla fine) renderà davvero difficile per le persone rompere gli altri codici senza saperlo, il che probabilmente è ciò che sta succedendo in questo momento (presumo che il tuo team non stia commettendo deliberatamente codice non funzionante).

Probabilmente faranno notare che c'è un sacco di strane interazioni tra il tuo codice, che è probabilmente almeno una parte del problema.

Questo è più di un supplemento / commento alla risposta di Doc Brown.

IMHO - l'architetto del software (SA) sta cercando un modo per individuare la colpa su qualcun altro. Non sto ascoltando se tutti stanno seguendo il piano. Alcune aziende possono affidarsi a un team leader o alla squadra nel suo insieme per essere responsabile della realizzazione del piano, quindi l'architetto è coinvolto solo quando c'è una domanda sul piano stesso. Altri possono fare affidamento sulla SA per decidere se il piano viene seguito.

Alcuni piani sono migliori di altri. Immagina un capo cuoco che ha una ricetta molto povera per il pollo e fa affidamento su un cuoco che è particolarmente bravo a farlo (fondamentalmente, ha la sua ricetta). Alcune notti un altro cuoco deve intervenire e viene incolpato per la scarsa qualità, perché ha tentato di seguire una ricetta sbagliata (senza condimento). Spesso non ci sono abbastanza bravi programmatori per salvare un progetto scadente o seguire un piano se lasciati soli.

Come Doc Brown ha indicato nella sua risposta, una revisione del codice è il modo migliore per assicurarsi che ciò accada insieme al seguito di altri standard. Ci sono quelli che pensano che le persone si assumano la responsabilità del codice se devono risolvere i propri bug. La linea di fondo è che qualcuno deve assicurarsi che il codice sia spedibile e se non ci sono recensioni, stai solo tentando di cogliere le tue possibilità.

How can I address the concerns of the software architect but still maintain collective code ownership?

Probabilmente sono vendita di biciclette , ma non è questo il tuo problema. La società possiede il codice, non uno sviluppatore o un architetto. Tutti lavorano per migliorare il tutto. Hai problemi nel tuo processo di progettazione, e in seguito si tradurrà in un gioco di biasimo.

È necessario determinare la causa dell'errore (autotest fallito e componenti guasti), e mettere in atto politiche e procedure per colmare le lacune. Una volta che le politiche e le procedure sono in atto, non c'è nessuno da incolpare perché "le cose funzionano".

In the current situation, developers change code in multiple components and they break other components either because they don't understand how the component works (because they work with so many components) or because they don't care about how their changes will affect the other clients of the component (as long as they are not affected).

Forse c'è un terzo: gli sviluppatori non sanno di avere codice danneggiato o rotto in altri componenti.

Questo pone la domanda: cosa c'è nel tuo processo di ingegneria per affrontare le lacune? Esistono politiche e procedure per risolvere i problemi in anticipo?

Processo uno

Posso dire con certezza che l'uso liberale di ASSERT s (in opposizione a POSIX è inutile assert ) assicurerà a uno sviluppatore di conoscere quasi ogni condizione inaspettata al momento dello sviluppo . Lo chiamo codice "self-debugging" e trascorro quasi del tempo in un debugger perché il codice mi dice dove sono i problemi.

Quando dico "uso liberale di ASSERT s", intendo tutto. Si asserisce che tutti i parametri sono previsti quando si inserisce una funzione. Asserisci tutto lo stato del programma utilizzato in una funzione. E tu asserisci tutti i valori di ritorno dalle chiamate di sistema. Se c'è un if per convalidare qualcosa, allora deve esserci un ASSERT corrispondente. Se c'è un ASSERT per convalidare qualcosa, allora deve esserci un if corrispondente. Il codice non sarà in grado di scoreggiare o starnutire senza che uno sviluppatore ne sia a conoscenza.

Un altro modo per vederlo: perché dovresti eseguire il debug del mio codice e perché dovrei eseguire il debug del tuo codice? Lascia che il codice esegua il debug e ti dica dove sono i problemi.

Un altro modo per vederlo: perché dovresti dedicare tempo al debugging? Il tuo tempo è meglio speso per aggiungere funzionalità. Lascia che il codice esegua il debug e ti dica dove sono i problemi.

Se non hai studiato come ASSERT, allora sarebbe un piacere leggere John Robbins. Lui è un maestro cacciatore di insetti. Il libro che ho imparato è stato Debug delle applicazioni . Il suo blog è all'indirizzo link .

Processo due

Ci devono essere autotest completi per componenti. Non spreco molto tempo negli autotest positivi. Posso assumere un bambino dall'India o dal Pakistan per $ 10 al giorno per copiare / incollare il codice che funziona come previsto in condizioni benigne. Rent-a-Coder ne è pieno.

Mi concentro sull'autotest negativo. Voglio sapere come fallisce il programma e assicurarsi che si riprenda o fallisca con grazia. E quando dico test, intendo testare tutto - anche interfacce protette e private in una classe C ++.

Non compro negli argomenti che "solo le interfacce pubbliche hanno bisogno di essere testate". Hogwash fino a quando qualcuno non produce un programma senza errori. Ho un codice nel campo che dura anni tra le segnalazioni di bug perché il mio processo di progettazione richiede una copertura del 100% con casi di test negativi.

Processo tre

Integrazione continua in un'area di sosta. Ogni commit avvia una build e autotest. Rifiuta il check-in se interrompe una compilazione.

The Real Gem

Il vero gioiello nei tre processi sopra riportati non ti servono codificatori esperti. Puoi assumere stagisti e sviluppatori junior al codice dello strumento con ASSERT s e scrivere casi di test. Direi anche che hai bisogno di meno programmatori esperti perché il codice sta facendo il grosso sforzo eseguendo il debug di se stesso. Ciò dovrebbe rendere la gestione felice.

E i tuoi sviluppatori esperti si arrabbieranno quando un giovane inizia a decifrare il codice in modi ovvi. Non posso dirti quante volte un ragazzo con 10 o 15 anni di esperienza mi ha lamentato di tutti i dannati asseriti che stanno sparando. È incredibile quello che trovi quando inizi a cercare problemi nel codice che ritenevi solido.

C'è una validità nella sua analisi, in genere un programmatore "carica" un problema nella sua testa e lavora su di esso nel suo insieme.

Tieni i programmi in testa - pg saggio

Don't have multiple people editing the same piece of code. You never understand other people's code as well as your own.

Alcune circostanze della vita reale imporranno ai programmatori di lavorare con il codice dell'altro, ma non dovrebbe essere la procedura operativa standard.

Per inciso, questo è un grande motivo per cui TDD e la qualità del codice sono popolari. Catturano insetti quando sono più economici da sistemare. Costa molto di più risolvere i problemi più tardi di come il codice è scritto e le informazioni iniziano a svanire.

Una parte del ruolo dell'architetto del software dovrebbe essere quella di aiutare a migrare l'architettura in questa direzione.

L'architetto del software dovrebbe assistere attivamente in questo processo. Dato che presumo che abbiano una conoscenza più approfondita dell'architettura, dovrebbero essere in grado di aiutare a determinare le specifiche di questo piano, cosa può essere scomposto in moduli? come sono gestite le dipendenze? Chi dovrebbe iniziare ad assumere la proprietà di quale parte? Se l'architetto del software sta semplicemente dicendo "prendi possesso" e non aiuta a cancellare tutti i dettagli, anch'essi fanno parte di questo problema.

Un approccio consiste nel trovare le parti con il minor numero di dipendenze e nel refactoring. Non effettuare il refactoring solo per il gusto di farlo, ma il più delle volte ogni modulo avrà una richiesta di funzionalità o due che ne farebbero la pena refactoring. Non farne una riscrittura!

Se test e recensioni di codice vengono aggiunti a questo processo, i programmatori saranno effettivamente meglio equipaggiati per lavorare con i moduli creati da altre persone, perché scriveranno codice più simile che dovrebbe essere più facilmente testato e più debugabile, ma codice le recensioni e la proprietà del codice dovrebbero essere parte di un piano per migliorare il software, non la totalità del piano.

Personalmente ritengo che il tuo architetto sia corretto. Non ho mai comprato questo concetto di 'code ownership is bad'. Siamo artigiani. I programmatori devono essere responsabili di ciò che creano. E se creano un disastro, devono essere quelli che lo puliscono. Altrimenti si finisce con i programmatori che creano bug, altri li risolvono e il programmatore originale non apprende mai dal loro errore. O peggio, si finisce con certi codificatori poveri che sono sempre quelli che commettono errori, e altri sono sempre bloccati a fissarli, portando il loro peso.

Sì, le revisioni del codice lo aiuteranno. Ed è sempre bene avere persone che hanno familiarità con altri moduli per il proverbiale occupato da una situazione di autobus . Ma nulla aiuta un codice coder in modo responsabile e difensivo più che apprendendo nel modo più duro in cui, se mordono qualcosa, saranno bloccati a risolverlo.

Detto questo, con una base di codice delicata che si rompe facilmente come quella che descrivi, dubito che la mancanza di proprietà del codice sia il problema solo qui in gioco. Ciò mi indica una mancanza di chiarezza del pensiero che va avanti, e probabilmente un sacco di pensieri a breve termine da parte di tutti i soggetti coinvolti.

Se le modifiche apportate ai componenti influenzano troppo spesso gli altri componenti, significa che l'architettura non è buona. Quindi, ogni errore del genere ha la causa nello stesso architetto.

Dopo averlo riconosciuto, potresti essere d'accordo con le informazioni sulla paternità personale, per trovare più facilmente CHI CONOSCE meglio il componente, non per nessuna incolpazione. Insieme alle revisioni del codice fatte dai proprietari dei componenti vicini, potrebbe funzionare.

In questo modo non viene creata alcuna cattiva atmosfera.

In the current situation, developers change code in multiple components and they break other components either because they don't understand how the component works (because they work with so many components) or because they don't care about how their changes will affect the other clients of the component (as long as they are not affected).

Questo sembra davvero un problema di gestione - che gli sviluppatori non hanno avuto il tempo di imparare le competenze di cui hanno bisogno per possedere il codice. Altre risposte offrono soluzioni pratiche a questo, ma non credo che risolvano il problema di root.

Consiglierei di esaminare il 5 perché e di applicarlo al tuo gruppo per scoprire perché le abilità non sono essere appresi - questo sarebbe un esempio di esso.

• Perché gli sviluppatori non sanno come funzionano i componenti?
  • Forse perché hanno bisogno di allenarsi con loro?
• Perché non si sono allenati con loro?
  • Forse perché non hanno tempo per fare un allenamento?
• Perché non hanno il tempo di fare l'allenamento?
  • Forse perché hanno troppo lavoro da fare?
• Perché hanno troppo lavoro da fare?
  • Forse perché il loro manager ha dato la priorità al lavoro rispetto alla formazione

A questo punto, devi convincere il tuo manager che il vantaggio di investire in questa formazione ora consentirà la vera proprietà del codice e, auspicabilmente, una migliore qualità.

È una responsabilità condivisa.

Ogni programmatore dovrebbe essere responsabile del proprio codice e, allo stesso tempo, l'architetto dovrebbe controllare il codice di ogni programmatore.

Al fine di implementare quella "responsabilità condivisa", la tua azienda dovrebbe anche avere delle politiche sul codice. Dovrebbero essere abbastanza "vicini" da evitare bug e "aperti" abbastanza da permettere ai programmatori di applicare le loro abilità, senza sentirsi troppo ristretti.

Un esempio di politica potrebbe essere l'installazione del software di controllo della versione e ogni sviluppatore dovrebbe memorizzare le ultime modifiche al codice ogni giorno prima di partire.

Un altro esempio di politica potrebbe essere come scrivere una frase "if-else", usando un linguaggio "C". In una società in cui ho lavorato, usiamo sempre le parentesi, anche se usiamo solo una singola istruzione.

Quindi, questo:

if ()
    DoSomething();
else
    DoSomethingElse();

Divenne questo:

if ()
{
    DoSomething();
}
else
{
    DoSomethingElse();
}

Quando un programmatore viene assunto, deve essere informato sulle politiche di codifica. E firmare un contratto. Ma le politiche dovrebbero essere spiegate come qualcosa che aiuti a svolgere il lavoro, con esempi o formazione.

È possibile consentire a uno sviluppatore di ignorare le regole a volte, troppo carico di lavoro o uno scenario imprevisto. A volte la regola interrotta diventa l'unica regola.

Ma, se uno sviluppatore li rompe, frequentemente, con una ragione non significativa, dovresti licenziarlo, perché potrebbe rovinare gli altri colleghi.

Se la tua azienda non ha politiche formali, o se queste politiche richiedono di essere aggiornate, controllali insieme ai programmatori, non solo all'architetto o al project manager.