Come annoti le modifiche al codice e la paternità del codice

4

Qual è il modo migliore per annotare chi ha creato un file e le successive modifiche apportate?

Sono un appaltatore di un nuovo progetto, uno che sta appena iniziando, che sta usando Subversion. L'altro giorno ho notato che un membro del team aveva aggiornato una sceneggiatura scritta da un consulente esterno, e ha aggiornato l'intestazione da "Scritto da X" a "Scritto da Y e X" (dato che aveva fatto un discreto numero di aggiornamenti).

Non pensavo che fosse una buona idea, perché altri dopo di noi potrebbero aggiornare quello script con piccole o grandi modifiche e non sarebbe chiaro quando aggiornare l'intestazione "Scritto da" (o come ordinare i nomi) . Ho lanciato il modo in cui l'avevo fatto nella mia precedente azienda (con un log di modifica nella parte superiore di ogni file), che veniva applicato da chiunque avesse verificato le modifiche, stavamo usando Clear Case in modo che le modifiche non venissero trasmesse fino a quando non venivano verificate ), ma poi ha menzionato che potremmo semplicemente usare il comando "svn log" per vedere le modifiche e sarebbe difficile applicare un log di modifica.

Quindi ora non sono così sicuro di quale sia il modo migliore per annotare la paternità e le modifiche. I file possono cambiare completamente nel tempo, quindi non mi piace l'idea di un'intestazione "Written by" stantio. E un'intestazione "Scritto da" che include solo una lunga lista di persone senza contesto non sembra utile. Si sta rimuovendo l'intestazione authorship e usando semplicemente il log delle modifiche di subversion, ma cosa si fa a proposito delle intestazioni "Scritto da" dal codice che viene fornito (dai consulenti, alle vecchie basi di codice, scaricate dalla rete, ecc.)? Come gestiscono gli altri team?

    
posta patorjk 25.09.2011 - 06:57
fonte

4 risposte

9

Sono con te, i moderni documenti di controllo del codice sorgente che hanno fatto cosa a cosa nel codice sorgente molto meglio di qualche commento casuale in un file di intestazione.

Il tuo cliente ha torto, sta perdendo tempo e aggiungendo spazzatura ai suoi file. Ma è ancora il cliente.

Se sei un appaltatore devi seguire gli standard di codifica del cliente.

Se questa è solo una questione di ego, dimentica i commenti di intestazione e fai il tuo lavoro.

    
risposta data 25.09.2011 - 07:39
fonte
6

I don't like the idea of a stale "Written by" header.

Una corretta. È inutile.

And a "Written by" header that just includes a long list of people with no context doesn't seem useful.

Una corretta. Sono tutti morti, a proposito. O ha vinto la lotteria. Sono in mare e non possono essere contattati. Perché elencarli?

Il mio preferito sta usando le iniziali. %codice%. Chi è quello? E come lo scoprirai? Se fossero un appaltatore, dovresti ritirare tutte le fatture da quella data, chiamare tutte le ditte appaltatrici che sono ancora in attività in modo da poter estrarre tutti i loro record personali.

what do you do about "Written by" headers from code that's given to you (from consultants, old code bases, downloaded from the net, etc)?

Ignora.

    
risposta data 25.09.2011 - 15:24
fonte
5

Lascia che SCM lo gestisca. È l'unico modo per essere sicuri che le informazioni siano sempre aggiornate, è granulare al livello della linea sorgente, ed è anche il modo più semplice, dal momento che subversion tiene traccia di queste informazioni già. Anche se non imponi messaggi di commit, è banalmente facile estrarre un numero di revisione e le modifiche di accompagnamento da una colpa, il che dovrebbe dirti tutto ciò che devi sapere.

L'unica ragione per cui posso pensare di volere questa informazione nei commenti è che svn blame o svn log sono un po 'più lenti del semplice guardare i commenti, ma il prezzo che paghi per il piccolo aumento di velocità è che hai cruft nel tuo codice. La parte peggiore, tuttavia, è che ti stai affidando a processi manuali per attività ripetitive.

    
risposta data 25.09.2011 - 08:57
fonte
4

Devo essere d'accordo con Jim.

Qualsiasi strumento di controllo della versione farà un lavoro migliore di un grande blob di testo nella parte superiore di un file. Il sistema di controllo della versione sarà accurato, aggiornato e fornirà differenze risalenti alla creazione del file. Il metodo di intestazione dirà:

11/01/98 - Redesigned file - KPR

04/15/05 - Patch to work around small bug - JSC

I commenti dovrebbero descrivere cosa un file / classe / funzione / linea fa ORA . La sua storia è inutile da registrare in linea. È una presa in consegna dai giorni precedenti al controllo della versione economica / straordinaria.

Dovresti spiegare al cliente che aumenterà i costi per farlo in quel modo e lascerà che acceleri lo sviluppo per lasciare che gli strumenti facciano il lavoro correttamente.

    
risposta data 25.09.2011 - 08:45
fonte

Leggi altre domande sui tag