In che modo il codice "Tendenza obiettivo" deve essere gestito da un responsabile dello sviluppo?

Per prima cosa mi permetta di coniare un termine:

code-tending: controllo del codice al mattino, quindi revisione silenziosa di tutte le modifiche apportate dagli altri sviluppatori il giorno precedente file per file (in particolare i file di codice sviluppati originariamente) e correzione di formattazione, logica, ridenominazione delle variabili, refactoring metodi lunghi, ecc., quindi eseguendo il commit delle modifiche al VCS.

Questa pratica tende ad avere alcuni pro e contro che ho identificato:

• Pro : la qualità / leggibilità / coerenza del codice viene spesso mantenuta
• Pro : alcuni bug sono stati corretti perché l'altro sviluppatore non conosceva troppo il codice originale.
• Contro : è spesso una perdita di tempo dello sviluppatore tendente agli obiettivi.
• Contro : Occasionalmente introduce bug che causano rabbia strabiliante da parte degli sviluppatori che pensavano di aver scritto un codice privo di bug il giorno prima.
• Contro : altri sviluppatori vengono aggravati da un eccessivo nitpicking e iniziano a non gradire il contributo al codice del tender.

Disclaimer: Ad essere onesti, in realtà non sono un responsabile dello sviluppo, sono lo sviluppatore che sta effettivamente facendo "tendenzialmente l'obiettivo".

A mia difesa, penso di farlo per una buona ragione (per mantenere la nostra base di codice estremamente grande una macchina ben oliata), ma sono molto preoccupato che stia creando anche un'atmosfera negativa. Sono anche decisamente preoccupato che il mio manager dovrà affrontare il problema.

Quindi, se tu fossi il manager, come affronteresti questo problema?

AGGIORNAMENTO: Non intendo che questo sia troppo localizzato, ma alcuni hanno chiesto, quindi forse un po 'di sfondo sarà illuminante. Mi è stato assegnato un progetto gigante (200K LoC) tre anni fa, e solo recentemente (1 anno fa) sono stati aggiunti altri sviluppatori al progetto, alcuni dei quali non hanno familiarità con l'architettura, altri che stanno ancora imparando la lingua (C #). In genere devo rispondere per la stabilità complessiva del prodotto e sono particolarmente nervoso quando vengono apportate sorprendentemente modifiche alle parti architettoniche fondamentali della base di codice. Questa abitudine è nata perché all'inizio ero ottimista riguardo ai contributi di altri sviluppatori, ma hanno commesso troppi errori che hanno causato seri problemi che non sarebbero stati scoperti fino a settimane dopo, in cui il dito sarebbe stato puntato su di me per scrivere codice instabile. Spesso questi "

Sembra che ciò che stai facendo sia sostanzialmente equivalente a una revisione del codice, tranne che piuttosto che fornire feedback allo sviluppatore, stai apportando tutte le modifiche che suggeriresti in una revisione del codice. Quasi sicuramente faresti meglio a fare una vera revisione del codice in cui tu (o qualcun altro) fornisci feedback allo sviluppatore originale su problemi di qualità del codice e ovvi bug e chiedi allo sviluppatore originale di risolverli. Ciò mantiene alta la qualità del codice ma aiuta anche lo sviluppatore a familiarizzare con il codice originale e le sue insidie ​​e aiuta a migliorare le future modifiche al codice. Inoltre, non ha il rovescio della medaglia di causare "rabbia da capello" quando un bug viene introdotto silenziosamente o fa pensare ad altri sviluppatori di cui si sta parlando di cui si parla alle loro spalle.

Ad essere sinceri, IMHO, questa è un'idea terribile.

Mi aspetterei che il morale cada nella grondaia, se non lo ha già fatto.

Per essere onesti con te, lo riconosci.

Le revisioni del codice peer vanno bene, mette l'onere sugli sviluppatori tutti a un livello, invece di essere uno scenario "loro contro noi". (dove sono gestione / lead).

Potrebbero esserci degli sviluppatori di cui potresti aver bisogno di tenere d'occhio più di altri, ma forzare forzatamente tutto il codice a passare prima attraverso di te è ridicolo.

E nonostante quanto tu pensi di essere bravo, ci saranno momenti in cui ti sbagli, o "nit picking" e questo peggiorerà le cose.

Se fossi il manager, per affrontare questo problema:

• Rivedi gli standard e le pratiche del codice con il team, consegnandogli una copia degli standard di codifica
• Codice di revisione tra pari su base regolare per rafforzare gli standard e le pratiche da seguire
• Applicare nitpicking / formattazione con uno strumento di automazione in modo che gli sviluppatori siano costretti a seguire gli standard
• Sbarazzati dei compagni di squadra cattivi che si rifiutano di seguire gli standard
• Smetti di essere il portiere

Le tue intenzioni sono buone, ma l'implementazione è terribile e, come altri hanno sottolineato, causerà cattivo morale e cecchino tra i membri del team.

Se il progetto non ha mai avuto uno standard per cominciare, prova a semplificare il nuovo standard in più fasi invece di premere semplicemente un interruttore.

Bad juju.

Non sono un responsabile dello sviluppo, ma se lo fossi non vorrei che nessuno dei miei sviluppatori toccasse il codice che non fa parte di un difetto o di una funzione loro assegnata. Periodo. Se riscontri un problema con il codice di qualcun altro, portalo sicuramente all'attenzione dello / degli sviluppatore / i responsabile / i, ma non immergerti e risolverlo da solo, specialmente se non ti sei coordinato con l'altro sviluppatore ( prima).

Le attività di pulizia devono essere eseguite solo dopo una revisione formale del codice da parte del team e solo dagli sviluppatori a cui sono state assegnate tali attività.

L'iniziativa è buona in generale, ma a volte può morderti nel culo. Se introduci qualche bug in quello che stava funzionando, potresti desiderare rapidamente di aver scelto un percorso di carriera diverso.