Devo cambiare il nome dell'autore nel file di classe se faccio più dell'80% di modifiche?

Dipende davvero ...

Se pensi che ci sia una minima possibilità che qualcun altro possa essere interessato più tardi nel chiedere all'autore originale, lascia il suo nome nel codice. Se pensi che qualcuno potrebbe essere interessato a chiederti di persona, lascia che il tuo nome ci sia dentro. E se pensi che entrambi potrebbero essere possibili, lascia che entrambi i nomi (o un commento come "basato sul lavoro di ...).

Ovviamente, quando l'uso del controllo del codice sorgente è obbligatorio sul posto di lavoro, e questo è l'unico modo per ottenere l'accesso alle fonti, quindi salvare il trucchetto e rimuovere ogni commento dell'autore dalla fonte. Nel mio posto di lavoro, ad esempio, abbiamo molti file sorgente nel controllo del codice sorgente in cui non ci preoccupiamo di scrivere nomi nelle fonti. Se voglio sapere chi è responsabile del file, o era nel passato, o per un cambiamento specifico, TortoiseSVN mi produrrà facilmente un registro per questo.

D'altra parte, abbiamo un sacco di macro VBA, scritte da alcuni ragazzi, passati in giro ad altri ragazzi (alcuni di loro hanno lasciato la compagnia nel corso degli anni) e sono stati modificati molto, il tutto senza usare il controllo del codice sorgente. Fortunatamente, i commenti di questi file contengono spesso nomi di autori e qualche tipo di registro cronologico.

Mi sono appena imbattuto in un altro post in cui OP stava chiedendo se il nome dell'autore dovesse trovarsi nell'intestazione del file e sembra che almeno 2/3 delle persone che hanno risposto dicessero che il nome non dovrebbe nemmeno essere elencato e che dovresti usare controllo della versione per tenere traccia di chi ha modificato il file. Non so cosa sia successo a quel post, ma ora non riesco a trovarlo. < - (quindi "OP" anonimo)

Personalmente, trovo che l'autore elencato nell'intestazione del file sia utile ma per un motivo leggermente diverso (e questo potrebbe non riguardare gli altri nei loro ambienti). Anche se cerchiamo di praticare la proprietà della comunità e spesso lavoriamo su varie parti del progetto, tendiamo ad avere pochi membri del team che conoscono alcune aree del codice molto più intimamente di altri. Quindi, quando qualcuno (specialmente numerosi imprenditori che vanno e vengono) apre un file che non hanno mai visto prima, l'autore diventa la persona giusta. Potrebbe non essere l'unico contributore, o addirittura contributore maggioritario, ma avendo il suo nome in cima, riconosce di avere certe responsabilità nel distribuire informazioni / informazioni sul codice al resto della squadra. Possiamo elencare più di una persona nell'intestazione: più persone hanno effettivamente contribuito e si sentono responsabili.

Lo trovo frustrante quando ho una domanda su un file e devo ricorrere al controllo della versione per identificare la persona principale o più esperta. Poi finiscono per passare da un ragazzo all'altro in quanto tutti negano davvero di sapere cosa fa il codice ... devono solo entrare e correggere un bug o due.

Questa pratica funziona nella nostra squadra perché non abbiamo manutenzioni. A meno che una persona non lasci o si trasferisca in un'altra squadra, quel codice / progetto rimarrà con la persona e con il nostro team. Ovviamente se le persone che mantengono il codice non sono uguali a quelle che lo scrivono, a nessuno interesserebbe chi era elencato nell'intestazione.

Quindi, alla luce del mio punto di vista sulle intestazioni dei file, direi se hai cambiato l'80% del file e ti senti come se tu fossi il tipo giusto per qualsiasi domanda (e probabilmente dovresti sentirti in quel modo), sì, vai avanti e aggiorna l'intestazione del file per avere il tuo nome su di esso. Se ti senti male a rimuovere la persona precedente, potresti lasciare il loro nome anche lì, almeno per il momento. Puoi sempre chiedere all'autore originale e sono sicuro che a loro non dispiacerà un pochino che tu abbia cambiato il nome, dal momento che presumo che non ci sia alcuna sensazione che tu possa cambiare l'80% del file stesso.

UPDATE: trovato quel post . Non ho idea di come sono riuscito a recuperare qualcosa da agosto. Ho appena finito di leggere The Pragmatic Programmer e nell'ultimo capitolo gli autori parlano della firma del lavoro e della responsabilità (l'altro post lo ha menzionato, ecco perché l'ho cercato). Il libro ha perfettamente senso e ora che ci penso, forse dovremmo introdurre la politica del team che chiunque sia elencato come autore, dovrebbe essere incluso in tutte le revisioni del codice del file in questione. Non importa chi ha cambiato il file scorso o più in SVN, l'autore è il proprietario ed è il custode.

Non trovo il nome dell'autore terribilmente utile. Come mostra questa domanda, spesso non esiste un singolo autore, quindi nominare "l'autore" non è possibile.

Ovviamente potresti includere un elenco di tutte le persone che hanno apportato importanti contributi, ma puoi già ottenerlo dal registro di controllo delle revisioni, quindi qual è il punto?

Nel mio progetto, non ci sono informazioni sull'autore nella maggior parte dei file. Se hai una domanda, dai un'occhiata ai log e di solito è ovvio che una o due persone hanno fatto la maggior parte del lavoro, quindi chiedi loro.

Modifica

La risposta presuppone un progetto utilizzando il controllo della versione. Se non si utilizza (in modo coerente) VC, mettere un autore (elenco) e magari qualche cronologia delle modifiche in un file potrebbe essere una soluzione praticabile. Tuttavia, probabilmente dovresti iniziare a usare VC il più rapidamente possibile, nel qual caso vedi sopra: -).

Se il file è stato modificato in modo significativo, dovrebbe essere accettabile aggiungere il tuo nome nel file come qualcuno che ne sa qualcosa.

Il creatore del file sorgente dovrebbe / deve sempre (IMHO) essere menzionato nel file sorgente. Questo, con un buon commento di intestazione, dovrebbe mostrare il motivo per cui l'autore ha sviluppato la fonte e qual era il suo modo di pensare per scrivere il codice. Per quanto riguarda il manutentore del codice, aggiungere il nome del manutentore è cruciale per il controllo del codice sorgente.

La denominazione dell'autore, nuovamente IMHO, dovrebbe includere la versione sorgente del codice, al di fuori del sistema di controllo della versione, la prima data in cui si è verificata la modifica, oltre al numero della richiesta di modifica. Il motivo è che, se la decisione di cambiare VCS si verifica, c'è una cronologia della versione del codice, chi era l'autore e il numero di richiesta di modifica a cui gli sviluppatori possono fare riferimento (se hanno bisogno di sapere perché il maintainer ha fatto quello che / lei ha fatto). Pertanto, nella nostra organizzazione, il nostro formato è il seguente:

/**
 * $comment
 * <p />
 * $cr_number, $date, $author, $description 
 **/

Mi piace vedere il nome dell'autore originale, se non altro per trovare qualcuno che inizi la mia ricerca di risposte sul codice. (L'autore di solito non ha ricordi, ma è almeno un colpo!)

Ti consiglio di aggiungere semplicemente il tuo nome sotto quello dell'autore originale.

Non è necessario sostituire il nome dell'altra persona, in quanto potrebbe conoscere alcuni aspetti dell'attività aziendale originale che non è necessario e altri che seguono dopo aver bisogno di parlare con quella persona pure.

La mia politica sui commenti di @author è:

1. Se si tratta di un file nuovo di zecca, mi metto come @author.
2. Se si tratta di un file esistente, lascio @author da solo, indipendentemente da ciò che faccio al file.

Se hai domande su qualcosa, non importa chi sia @author del file - importa chi è @author di quale parte del file stai modificando. Questo è ciò che [git/svn/whatever] blame è per.

IMO, @author deve andare via.