Se una nuova classe rifattorizzata da una esistente ha una storia che punta al suo progenitore

Naviga le tue risposte
6

Se divido una classe in due classi, entrambe le classi hanno una cronologia nel controllo del codice sorgente che ricalca la classe originale che le conteneva entrambe; o la nuova classe dovrebbe essere aggiunta come nuovo file senza traccia di cronologia?

Quando si divide una classe grande in due parti di dimensioni simili, questo sembra l'approccio naturale poiché le versioni precedenti della classe combinata avranno grandi quantità di cronologia rilevante per entrambi i discendenti. Quando sto solo tirando fuori uno o due metodi per creare una classe helper, avere la cronologia completa per la nuova classe e > il 90% delle modifiche nel genitore che il codice interessato non è stato diviso sembra una ricetta per la confusione in il futuro.

    
posta Dan Neely 20.03.2013 - 16:12
fonte

3 risposte

4

È molto più semplice ignorare qualche cronologia in un secondo momento piuttosto che provare a ricollegarlo. In generale, si preferisce privilegiare l'opzione meno distruttiva. Le persone esaminano principalmente la cronologia del controllo sorgente per tre motivi:

  1. Per scoprire quale modifica ha introdotto un bug.
  2. Per discernere i motivi per cui una sezione di codice è lì dentro.
  3. Per scoprire cosa è cambiato dall'ultima versione o dall'ultima volta che è stato aggiornato.

La copia della cronologia di un file diviso contribuisce a creare confusione per alcuni di questi casi di utilizzo. Il peggio che succede è che devi setacciare alcuni commit irrilevanti, e generalmente devi farlo comunque. D'altra parte, non avere la storia oltre un certo punto rende i primi due casi d'uso molto più difficili.

    
risposta data 20.03.2013 - 19:14
fonte
1

Non sono sicuro che questo tipo di cosa sia necessario.

Il tuo primo check in della nuova classe potrebbe dire "Split ClassX e creato ClassY e ClassZ basandoci su di esso perché ....."

Se un utente ha davvero bisogno di rintracciare, può comunque trovare la cronologia originale.

    
risposta data 20.03.2013 - 16:34
fonte
0

Ecco a cosa servono i repository di codice (Git, Subversion, et.al.).

Avendo mantenuto un codice molto, molto vecchio, posso dire che una delle cose peggiori che puoi fare è lasciare la "cronologia" nei file di codice.

Frammenti di codice antichi e esoterici e cruft non sono documentazione.

Un codice di produzione funzionante non è un museo.

Ogni linea di codice costa tempo e denaro per mantenere, ogni linea; compresi quelli non funzionanti, irrilevanti, obsoleti.

Ogni successivo cambio di codice rende tutti i precedenti meno rilevanti, meno informativi e più difficili da capire.

Come posso spiegarlo ... Voglio prendere lezioni di volo, ma aspetta! Cos'è questo sui fratelli Wright? Oh, ho bisogno di fermarmi e imparare tutto su come funziona Wright Flyer e dopo aver perso troppo tempo a capire che i dettagli espliciti su come ha funzionato quella cosa sono del tutto irrilevanti nell'usare questo aeroplano. E che cosa nel vasto mondo dello sport è questo vecchio dohickey arrugginito nel cruscotto?

Nell'analisi finale Tutto ciò che devo sapere è incorporato nel progetto corrente.

    
risposta data 21.03.2013 - 18:00
fonte

Leggi altre domande sui tag

modello mvc: modello di suddivisione in livelli di accesso ai dati e di logica aziendale Git: rebasing su un refactoring che interessa il ramo di rebase target