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

Naviga le tue risposte
12

Prima consentimi di coniare un termine:

code goal-tending: Checking out code in the morning, then silently reviewing all of the changes made by the other developers the previous day file by file, (especially code files you originally developed), and fixing formatting, logic, renaming variables, refactoring long methods, etc., and then committing the changes to the 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 a causa della mancanza di familiarità con il codice originale da parte di un altro sviluppatore.
  • Con : spesso è uno spreco di tempo per lo sviluppatore che tende all'obiettivo.
  • Con : Occasionalmente introduce bug che causano rabbia ai capelli da parte degli sviluppatori che pensavano di aver scritto un codice privo di errori il giorno precedente.
  • Con : altri sviluppatori vengono aggravati dall'eccesso di nitpicking e iniziano a non gradire il contributo al codice dell'obiettivo-gara.

Dichiarazione di non responsabilità: per essere onesti, in realtà non sono un responsabile dello sviluppo, sono lo sviluppatore che sta effettivamente facendo "l'ottimizzazione degli obiettivi".

In mia difesa, penso Lo sto facendo per una buona ragione (per mantenere la nostra base di codice estremamente ampia una macchina ben oliata), ma sono molto preoccupato che stia creando anche un negativo atmosfera. Sono anche seriamente preoccupato che il mio manager dovrà affrontare il problema.

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

AGGIORNAMENTO: non intendo per questo essere troppo localizzato, ma alcuni hanno chiesto, quindi forse qualche sfondo sarà illuminante. Mi è stato assegnato un progetto gigante (200K LoC) tre anni fa, e solo recentemente (1 anno fa) altri sviluppatori sono stati aggiunti al progetto, alcuni dei quali non hanno familiarità con l'architettura, altri che stanno ancora imparando la lingua (C #). Generalmente devo rispondere della stabilità complessiva del prodotto, e sono particolarmente nervoso quando i cambiamenti sono sorprendentemente apportati alle parti architettoniche principali del codice base. Questa abitudine è nata perché inizialmente ero ottimista sui contributi di altri sviluppatori, ma hanno commesso troppi errori che hanno causato seri problemi che non sarebbero stati scoperti fino a qualche settimana più tardi, dove il dito sarebbe stato puntato su di me per scrivere codice instabile. Spesso queste "sorprese" sono commesse da un manager entusiasta o da un collega che è ancora in fase di apprendimento. E probabilmente questo probabilmente porterà alla risposta: non abbiamo nessuna politica di revisione del codice in atto,

    
posta Kevin McCormick 16.03.2012 - 16:01
fonte

4 risposte

52

Sembra che quello che stai facendo sia sostanzialmente equivalente a una revisione del codice tranne che piuttosto che fornire un feedback allo sviluppatore, stai facendo tutte le modifiche che suggeriresti in una revisione del codice. Quasi sicuramente starai meglio facendo una revisione del codice in cui tu (o qualcun altro) fornisci feedback allo sviluppatore originale su problemi di qualità del codice e bug ovvi e chiedi allo sviluppatore originale di risolverli. Ciò mantiene 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 "furia di strappare i capelli" quando un bug viene silenziosamente introdotto o fa sì che altri sviluppatori pensino che si stiano parlando di loro alle spalle.

    
risposta data 16.03.2012 - 16:08
fonte
14

Per essere sincero, IMHO, questa è una pessima idea.

Mi aspetterei che il morale cada nella fogna, se non lo è già.

Per essere onesti con te, lo riconosci.

Le recensioni dei peer code vanno bene, mette l'onere degli sviluppatori a un livello, invece di essere uno scenario "loro contro noi". (dove sono gestione / lead).

Potrebbero esserci alcuni sviluppatori che potresti aver bisogno di tenere d'occhio più di altri, ma la coperta che costringe tutto il codice a venire attraverso di te prima è ridicolo.

E nonostante quanto pensi di essere bravo, ci saranno momenti in cui ti sbagli o "pignoli" e questo renderà le cose ancora peggiori.

    
risposta data 16.03.2012 - 16:17
fonte
5

Se fossi il manager, per risolvere questo problema:

  • Rivedi gli standard e le pratiche del codice con la squadra, consegnagli una copia di gli standard di codifica
  • Codice di peer review 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 lo siano costretto a seguire gli standard
  • Sbarazzarsi di eventuali cattivi compagni di squadra 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à uno scarso morale e un cecchinaggio tra i membri del team.

Se il progetto non ha mai avuto uno standard per iniziare, cerca di semplificare il nuovo standard in fasi invece di girare un interruttore.

    
risposta data 16.03.2012 - 16:28
fonte
3

Bad juju.

Non sono un responsabile dello sviluppo, ma se lo fossi non vorrei che nessuno dei miei sviluppatori tocchi il codice che non fa parte di un difetto o di una funzione assegnata a loro. Periodo. Se vedi un problema con il codice di qualcun altro, quindi portalo all'attenzione dello sviluppatore (i) responsabile, ma non immergiti e risolvilo da solo, soprattutto se non lo hai " t coordinato con gli altri sviluppatori per primo.

Le attività di pulizia dovrebbero essere eseguite solo dopo una revisione formale del codice da parte del team e solo dagli sviluppatori a cui tali compiti sono stati assegnati.

L'iniziativa è buona in generale, ma a volte può morderti nel culo. Se introduci dei bug in quel che è stato funzionante, potresti rapidamente desiderare di aver scelto un percorso di carriera diverso.

    
risposta data 16.03.2012 - 17:13
fonte

Leggi altre domande sui tag

sta generando un'eccezione da una cattiva proprietà? Spostamento da un progetto man a progetto team in futuro. Cosa dovrei fare ora in preparazione e cosa può aspettare?