È meglio avere la duplicazione del codice e renderlo molto semplice/leggibile, oppure non avere duplicazione (usando i generici) ma essere molto più complicato?
https://stackoverflow.com/questions/1765908
-
21-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
In generale mi imbatto spesso in questo.Alcuni dei miei colleghi preferiscono lezioni molto semplici e facili da leggere, anche se ciò significa che c'è qualche duplicazione del codice, mentre io faccio tutto ciò che è in mio potere per evitare la duplicazione del codice, anche se ciò significa rendere un'architettura più complicata.Qual è la pratica migliore?Lavoro esclusivamente in Java.
Soluzione
Ho sempre preferisco la soluzione senza duplicazione del codice. Anche se l'architettura più complicato è più difficile da capire a prima, i benefici per la manutenzione più che superano la curva di apprendimento.
Altri suggerimenti
Mentre entrambi sono buoni obiettivi, ritengo che la leggibilità è il primo requisito assoluto per avere una base di codice mantenibile. Vorrei sempre preferisco semplice, leggibile, e mantenibile ad una completa eliminazione della duplicazione del codice.
Le migliori pratiche:. Se il codice è breve, duplicare due volte, ma mai più
Quindi, se si dispone di frammenti molto simili del codice di copia / incollato in 3 luoghi diversi, prendere in considerazione il refactoring.
Tenete a mente, refactoring non automaticamente significa rendere il codice più complicato. Si consideri il seguente:
class IntStack
{
public int value;
public IntStack next;
}
class StringStack
{
public String value;
public StringStack next;
}
class PersonStack
{
public Person value;
pubilc PersonStack Next;
}
Ogni volta che si desidera una pila per un nuovo tipo di dati, è necessario scrivere una nuova classe. Codice Duplicazione funziona bene, ma diciamo che si desidera aggiungere un nuovo metodo, forse un metodo "push", che restituisce una nuova pila? Bene, ora si è costretti a aggiungerlo in un bajillion luoghi diversi. Oppure si potrebbe usare una pila oggetto generico, ma poi ci si perde tipo di sicurezza. Generici semplificherà l'architettura:
class Stack<T>
{
public T value;
public Stack<T> next;
}
Cool!
Bene, come su questo esempio:
class Logger
{
int logtype;
public Logger(int logtype) { ... }
public void Log(string text)
{
if (logtype == FILE) { ... }
elseif (logtype == DATABASE) { ... }
elseif (logtype == CONSOLE) { ... }
}
public void Clear()
{
if (logtype == FILE) { ... }
elseif (logtype == DATABASE) { ... }
elseif (logtype == CONSOLE) { ... }
}
public void Truncate(int messagesToTruncate)
{
if (logtype == FILE) { ... }
elseif (logtype == DATABASE) { ... }
elseif (logtype == CONSOLE) { ... }
}
}
Va bene, in modo che ogni volta che si aggiunge un metodo, si controlla che tipo di logger che si sta utilizzando. Doloroso, e incline a bug. Normalmente, si sarebbe fattore fuori un'interfaccia (probabilmente con i metodi in tronchi, chiari, e troncare), quindi creare tre classi (FileLogger, DatabaseLogger, ConsoleLogger).
Altre classi = più architettura. È questo più facile o più difficile da mantenere nel lungo periodo? Per questo esempio, direi che il codice è ora più facile da mantenere, ma YMMV.
Il motivo principale per evitare la duplicazione del codice è la manutenibilità. Se un segmento di codice appare in più punti, quando arriva il momento di aggiornare bisogna ricordarsi di cambiarla in tutto il mondo . Dimenticando di cambiare una sola istanza può causare big problemi, che non si può notare immediatamente.
Ci sono casi estremi in cui si impedisce la duplicazione del codice da metaprogrammazione complicata (non tanto un problema per Java) o l'uso eccessivo di riflessione, e in quei pochi casi mi piacerebbe favorire permettendo la duplicazione. Questo è raro. Fino a quando il codice rimane comprensibile da uno sviluppatore ragionevolmente esperto che non è, mi piacerebbe andare per eliminare la duplicazione.
Ho eseguito in situazioni in cui una squadra comprende uno o due sviluppatori qualificati e un gruppo di neofiti, dove i principianti tentano di impedire l'uso di codifica approcci che non capiscono a colpo d'occhio. Questo deve essere resistito.
Non vedo come "generici" è legato alla tua domanda. E 'banalmente, ovviamente sbagliato avere classi separate per rappresentare un CollectionOfFoo e CollectionOfBar, in modo che non può essere quello che stai chiedendo.
Probabilmente dovrete fornire un esempio per ogni punto di vista, ma ci si può comunque probabilmente ottenere chiuso per essere soggettiva.
Questa è una chiamata in giudizio. La maggior parte dei programmatori di duplicare il codice troppo, e penso che porta alla atteggiamento tra gli sviluppatori appassionati che stamping out duplicazione è un bene assoluto, ma non è. Rendere il codice di facile lettura dovrebbe essere la priorità, e l'eliminazione di codice duplicato è di solito una buona cosa per migliorare la leggibilità, ma non sempre.
Inoltre, non vorrei usare il codice valore commerciale come luogo per utilizzare le funzioni di lingua sconosciuta ai fini della loro apprendimento. Creare progetti di apprendimento separati per tale scopo. Tu non vuoi finire sempre chiamato al lavoro su off-ore per correggere i bug causati da diventando troppo di fantasia con i generici, o qualsiasi altra caratteristica.
Come evitare la duplicazione del codice è sempre una buona cosa. L'unica cosa che dovete evitare è Generalizzazione prematuro .
Non c'è bisogno di correre in un appena si ottiene un paio di pezzi di codice che sembrano simili. Il suo OK per sedersi fino a quando si hanno sviluppato un buon modello.
Anche lasciando alcuni esempi di cosa è necessario generalizzare può essere OK, in particolare, quando le cose sono un po 'più complessa e / o indeterminato. Può essere più facile generalizzare quando hai 3-5 + esempi, piuttosto che solo uno o due.
No. Nessuna di queste situazioni è accettabile. Scrivilo con i generici, ma solo così complesso come ha bisogno di essere.
Non duplicare il codice; si dovrà bug-fix doppio, doppio aggiungere miglioramenti, i commenti, i test a doppia scrittura double-scrivere. Ogni riga di codice si crea è un piccolo fardello si dovrà portare il più a lungo si lavora su quella base di codice; ridurre al minimo il peso.
dipende da una serie di fattori:
- Quanto codice è stato duplicato? Non è un problema se le stesse cinque linee appaiono due volte a condizione che vi sia qualche motivo justfiable per questo. Evitare di architecting codice, si può effettivamente ridurre la manutenibilità nel lungo periodo, perché la prossima persona che lavora sul codice non può apprezzare tutta la sottilmente nella vostra architettura e piegarlo gravemente fuori forma.
- Quante copie dello stesso codice? Due non è male, ma 10 (decimale) non così buono.
- Perché è duplicato il codice? Ho incontrato un certo numero di "duplicazioni" che una volta che sono state costruite tutte le esigenze, si è rivelato non essere duplicazioni a tutti, solo un po 'simile.
Quindi la mia risposta è forse ...
Prima di dare la mia risposta mi piacerebbe vedere qualche esempio di codice per vedere ciò che la domanda è in realtà.
In attesa che, credo che se il codice è costruito nei principi OO più sane (come ogni classe fa solo una cosa e una cosa sola ) non dovrebbe esistere alcun codice la duplicazione intorno. E 'certamente possibile andare dadi con astrazioni, ecc che non finiscono per creare un enorme mucchio di classi inutili, ma non credo che sia il problema qui.
Il motivo principale per cui i generici sono difficili da leggere perché è poco familiare ai programmatori inesperti. Ciò implica che la massima cura deve essere presa nella scelta dei nomi e della documentazione al fine di rendere la chiarezza trasparire.
E 'estremamente importante che tali classi principali sono ben nome-. Il progettista può decidere di discutere di questo fondo con i compagni prima di scegliere i nomi.
Ottima domanda;le risposte generiche potrebbero non essere adatte alla tua situazione.Ci sono molti fattori che determinano la tua scelta
- Qualità del codice attuale
- La fase del tuo prodotto/progetto, iniziale/crescita/matura
- Esperienza e abilità degli sviluppatori
- Il tempo di commercializzazione del tuo progetto/prodotto
Questi sono alcuni dei fattori cruciali che decidono la tua scelta.Nella mia esperienza mi rendo conto che il codice della logica aziendale duplicato (livello intermedio) non è una buona pratica, ma il livello di presentazione può avere codici duplicati.
Mentre scrivo questo, ricordo l'articolo "La crescita lenta equivale alla morte".Scrivere codice di qualità e non duplicato potrebbe richiedere tempo, ma ciò non dovrebbe costituire un collo di bottiglia per la tua azienda.
Di solito gli unici motivi per duplicare il codice sono di superare deboli / macro / sistema di farmaci generici modello di una lingua o per l'ottimizzazione, dove ci sono diversi nomi delle funzioni di basso livello che gestiscono diversi tipi.
In C ++, che si è preso nota non fare lavoro all'interno, il sistema di template permette zero spese generali tipo e funzione di generazione, con specializzazione a disposizione a "personalizzare" la codice generato per alcuni parametri di tipo. Java ha niente del genere, la rimozione della prevenzione sia specifica generale-e-scelta disponibile all'interno di C ++.
In Common Lisp, si possono impiegare le macro e macro del compilatore per la produzione di codice simile al template C ++, dove i casi di base possono essere personalizzati per specifici tipi, ottenendo diverse espansioni di codice.
In Java, l'unica volta che mi sostengono contro il codice generico è per cicli interni che utilizzano tipi numerici. Pagare i costi boxing e unboxing per i tipi numerici in codice generico è inaccettabile in questi casi, a meno che il profiler può convincere che il compilatore o HotSpot era abbastanza intelligente per rinunciare alla boxe.
Per quanto riguarda la leggibilità, così, rendere il codice del modello e la sfida a cui i vostri colleghi hanno a salire. Offerta di educare coloro che hanno difficoltà a leggerlo. Incoraggiare loro di esaminarlo per i difetti. Se trovano qualsiasi, è possibile dimostrare i benefici di avere solo per fissare l'unico e solo la versione.
Confronto a normalizzazione in database relazionali - probabilmente si desidera un luogo in cui un qualche tipo di funzione o di dati vite, non molti luoghi. Si fa una grande differenza in termini di manutenibilità e la capacità di ragionare sul codice.
