Come evitare che i programmatori duplicino il codice [duplicato]

5

Mentre conosco un mondo perfetto in cui una domanda greenfield è stata esaminata fin dal primo giorno con i migliori BRD e uno sviluppo competente conducono costantemente un codice revisionato dai loro sottoposti per evitarlo, ho intenzione di chiedere perché tutti sappiamo e abbiamo sono stati tutti parte di molti scenari in cui questo non è il caso ... e questo succede ...

Il problema che mi imbatto in sempre con i concerti di consulenza è che troverai dieci metodi praticamente tutti che fanno la stessa cosa, e con alcuni refactoring, potrebbe essere molto più efficiente. Tuttavia, non sembra impedire agli sviluppatori di creare nuovi metodi quando ce n'è uno già scritto, o per lo più scritto da usare.

Il problema non riguarda sempre lo / gli sviluppatore / i. Se si tratta di un'applicazione di grandi dimensioni, e anche in uno scenario di architettura orientata ai servizi, potresti avere centinaia di servizi e devi duplicare lì perché l'altro sviluppatore doveva realizzare qualcosa, era un buon programmatore nel creare una classe riutilizzabile / metodo, ma non sapevo che un altro buon piccolo sviluppatore ha già creato quel metodo.

Quindi la mia domanda a voi tutti è, che cosa avete trovato per essere il modo migliore per evitare i metodi duplicati? Documentazione, comunicazione, refactoring automatizzato? Ma ancora più importante, come indurre altri sviluppatori a entrare in un progetto di applicazione esistente con tutti i metodi e i servizi disponibili?

    
posta gnat 01.04.2014 - 22:28
fonte

3 risposte

7

Alcune idee;

  • Struttura del codice chiara, ben compresa. In modo che ci sia un posto "ovvio" per mettere un certo codice, per posizione della cartella o spazi dei nomi; se si tratta di un metodo di estensione condiviso, ad esempio, è possibile trovarli in una posizione Company.Common.Extensions. Oppure imposta i pattern per l'incapsulamento, in modo che i metodi possano essere trovati all'interno di un tipo pertinente, non esternamente nelle classi "BlobManager". Questo li aiuterà a trovare il codice esistente se esiste.
  • Test unitari; spesso gli sviluppatori potrebbero ritenere che un metodo non faccia esattamente ciò di cui hanno bisogno e piuttosto che toccare il codice esistente che faranno rotolare. Test di unità appropriati possono aiutare un refactoring a modificare il codice esistente senza interrompere i comportamenti correnti
  • Recensioni del codice; forse la consapevolezza è il problema, e una revisione del codice aiuta a diffondere la consapevolezza in un team
  • Stabilisci aspettative nel team che la duplicazione non è appropriata e applicala tramite recensioni e refactoring.
risposta data 01.04.2014 - 22:41
fonte
2

La cosa migliore di cui sono a conoscenza è la comunicazione. Contiene alcuni punti:

  • Quasi tutte le classi o le funzioni che ho riutilizzato da altri programmatori all'interno di un progetto, sono venute a conoscenza, perché stavo parlando con loro di qualche problema e quindi sapevo che avevano scritto qualcosa per questo. Le revisioni del codice e la programmazione della coppia possono rinforzarla.
  • Anche il codice deve parlarti, ciò che intendo dire è che hai bisogno di un buon naming per capire se questa classe o funzione è utile per te. Pertanto, dovrebbe svolgere solo un compito, avere una sola responsabilità. Dimentica altra documentazione, se non è facile capire che nessuno osa usarlo e scrive di nuovo la sua.
  • Il team dovrebbe accettare di posizionare il codice riutilizzabile, creato da un buon piccolo sviluppatore, in alcuni luoghi comunemente noti che tutti possono cercarlo. Anche solo un semplice tool / utility-class / file / namespace, è meglio quindi posizionare una funzione helper accanto alla classe che solo tu conserverai mai.
risposta data 01.04.2014 - 23:26
fonte
0

Ci sono molti fattori. Li elencherò all'incirca in ordine:

  1. recensioni di codice. Questi dovrebbero essere per il 100% del codice e dovrebbero includere spesso uno sviluppatore senior.

  2. Accoppia programmazione. Uno dei migliori (anche se difficili) modi per scrivere un buon codice è fare la programmazione della coppia. La sfida è trovare una buona coppia in quanto non tutte le personalità si abbinano bene.

  3. Test. Il codice ha buoni test che fungono da documentazione su come utilizzare le funzioni e incoraggiare l'uso della funzione.

  4. Condizioni di lavoro che incoraggiano la discussione, notevole un ambiente aperto che raggruppa le persone.

  5. Una cultura dell'apprendimento, incluse cose per il pranzo, libri, formazione, ecc.

  6. Una cultura del software artigianale con abilità di refactoring e dimostrazioni di approcci.

  7. Strumenti che analizzano il codice per le metriche di qualità.

risposta data 02.04.2014 - 00:34
fonte

Leggi altre domande sui tag