Come diffondere consapevolezza per la programmazione generica tra i membri del team?

Ci sono ancora persone nel mondo che non usano i generici di jave in "ordinaria codifica". Posso crederci con i modelli C ++, ma i generici? Non sono nemmeno difficili da imparare / usare. Seriamente le migliori caratteristiche di Java e C ++ sono rispettivamente generici e modelli.

Il modo migliore per convincere le persone di cose è fare un argomento convincente, non essere minaccioso e avere ragione.

Se non stai facendo qualcosa come usare i template come linguaggio di programmazione, il polimorfismo parametrico (generici / modelli) è quasi certamente buono.

1. Evita la duplicazione del codice.

Questo è ovvio, ma il codice polimorfico è codice generale. Questo è il motivo per cui è chiamato generici.

2. Supporta un controllo statico migliore.

Senza il polimorfismo parametrico finisci per scrivere cose come public Object clone() o public boolean equals(object b) che non sono solo abomini, hanno tipi che non forniscono informazioni su ciò che fanno e invariabilmente finiscono per lanciare eccezioni ovunque. L'alternativa al polimorfismo parametrico è un cast dappertutto

3. Polimorfismo non parametrico Il codice OOP è fondamentalmente incapace di gestire "metodi binari" in modo corretto.

Li usi spesso.

4. È una buona pratica

In Java, l'uso di generici è considerato la migliore pratica (vedi Java efficace di Josh Bloch). I pensatori di C ++ come Sutter e Alexandrescu incoraggiano anche l'uso di modelli per risolvere una serie di problemi.

5. Si adatta al paradigma OO.

Spesso le persone non lo notano, ma la combinazione di sottotipi e generici produce un sistema MOLTO più potente espressivo e orientato agli oggetti di qualsiasi sistema con solo uno di essi.

Considera i mixin di Scala. Queste sono una bella funzionalità che ti consente di estrarre i tuoi oggetti dalle parti dei componenti. Generici e modelli possono simulare alcuni di questi benefici. Ad esempio, supponi che uno dei tuoi oggetti utilizzi un database. Un buon design ti farebbe astrarre l'accesso al database in una classe separata. Se fatto bene, questo non solo ti permette di prendere in giro il tuo data-store (la chiave della testabilità) significa anche che puoi aggiungere implementazioni alternative come il nuovo database no-sql. Qui però potresti avere un problema, a prescindere dall'implementazione che utilizzerai, otterrai diverse funzionalità del tuo oggetto business.

Generici in soccorso!

   public class Business<S extends Datastore>{
      private S store; ...
   }

Ora puoi iniziare a differenziare in modo statico gli oggetti Business in base alla possibilità di utilizzare funzionalità specifiche del database. Hai ancora bisogno di alcuni controlli runtime e casting, ma puoi iniziare a creare un codice MUCH migliore.

e

6. Il codice normale non esiste.

Ci sono solo tre cose nell'universo di programmazione:

1. librerie,
2. configurazioni e
3. codice errato.

Se non pensi al tuo codice come se fosse una biblioteca, sei seriamente in difficoltà quando cambiano i requisiti per il tuo progetto. L'architettura è (discutibilmente) l'arte di progettare buone API.

Trovo che questa attitudine sia sorprendente. Dopo esserti abituato a programmare con i tipi parametrizzati, non usarli rende tutto un po 'doloroso. E, Java e C ++ hanno un sacco di punti difficili che aiutano a rimediare.

Questa è una forma specializzata della domanda più generale "come convincete i vostri superiori a utilizzare una tecnologia e un modo di fare le cose nuovi e migliori?"

Sfortunatamente, non penso che tu possa, e non sono sicuro che dovresti. È per definizione la loro scelta, dal momento che ti stanno pagando per fare le cose in un certo modo che hanno scelto, non nel modo che preferisci. Il meglio che puoi fare è suggerire che questa tecnologia è là fuori, molte persone la stanno usando e sembra essere la via del futuro. Potresti anche voler menzionare il fatto che, ovviamente, dovrebbero già sapere: che è meglio per le persone non lasciare che le loro abilità ristagnino. Ma questo è tutto: se non lo comprano, non c'è nulla che tu possa fare.

Potrebbero avere altre considerazioni che non hai, perché non stai pensando al loro livello. Stai pensando come ingegnere, potrebbero pensare più in termini commerciali o addirittura in termini di risorse umane.

• I generici (o qualsiasi altra cosa) miglioreranno il valore del loro prodotto? Probabilmente no.

• I generici (o qualsiasi altra cosa) renderanno più difficile per le persone che hanno già assunto per fare il loro lavoro? Sì.

• I generici miglioreranno il time-to-market? Se tu fossi l'unico ingegnere, forse. Ma se un intero gruppo di ingegneri ha bisogno di essere educato sui generici prima che un'altra riga di codice sia scritta in casa, No.

Quindi, potresti prendere in considerazione la possibilità di cambiare lavoro. Nel mio ultimo lavoro ero il primo ad usare i generici con Java e fortunatamente non avevano problemi con esso; hanno espresso la preoccupazione che i generici rendano il codice "più difficile da leggere", ma mi lasciano fare a modo mio. Trova un lavoro del genere.

Trasmetterei i meriti dei generici al revisore del codice e ad altri colleghi prima di qualsiasi revisione:

1) Permettendo di specificare i tipi su cui agisce una classe generica o un metodo, la funzione generici sposta il carico di sicurezza del tipo da te al compilatore. Non è necessario scrivere codice per verificare il tipo di dati corretto perché viene applicato in fase di compilazione. La necessità di trasmettere i tipi e la possibilità di errori in fase di esecuzione sono ridotti.

2) I generici forniscono sicurezza di tipo senza il sovraccarico di più implementazioni.

Quindi, [1] e [2] riducono il rischio di errori nel codice. Ciò consente di risparmiare tempo per gli sviluppatori e quindi i soldi della società.

Se la leggibilità è un problema, allora l'imbarazzo dell'uso di tipi generici potrebbe essere compromesso. Questa è una delle ragioni per cui potresti voler estendere le linee guida sulla codifica. Questo può essere fatto in un contesto lavorativo e non solo per estendere le librerie (tuttavia, è un'idea per refactoring mentre si va e contrassegnare possibili metodi candidati per le librerie nel codice per un facile riconoscimento in seguito). Pertanto, non ci sarebbe alcun motivo per non usarli in un contesto di tipo workday.

Vorrei aggiungere alcune affermazioni su come gli altri programmatori non hanno problemi con i generici: i generici sono ampiamente usati in Java e in molti altri linguaggi come C #. Qualsiasi programmatore serio troverà la vita difficile senza tali mattoni di sicurezza.

Tuttavia, potresti voler considerare che alcuni degli sviluppatori potrebbero non essere all'altezza. La direzione avrebbe potuto prendere una decisione consapevole per proteggere i progetti in passato, mantenendo questi scagnozzi fuori dalle zone pericolose. In questo caso, sia gli innocenti che i colpevoli di solito ricevono la colpa poiché un'analisi o una microgestione sufficienti vengono condotte raramente.

Se metti avanti una buona causa e non ricevi una risposta motivata in cambio, inizia segretamente a cercare un'altra società che prenda seriamente la programmazione.

A meno che tu non sia il capo dell'architettura / della tecnologia, sarà difficile stabilire che dovresti usare generici / modelli. Dovresti davvero proporre la soluzione generica / modello molto prima della revisione del codice, preferibilmente prima di iniziare a implementarla.

Quello che puoi fare è dimostrare perché in alcuni casi dovresti usare un generico. Se puoi dimostrare i benefici, i tuoi colleghi potrebbero essere d'accordo. I possibili motivi per cui dovresti usare generics / templates dovrebbero essere i seguenti:

• Dovrebbe consentire di scrivere meno codice per le attività ripetitive
• Semplifica il lavoro dei programmatori
• Applica un pattern impostato dall'architetto della soluzione
• Incapsula le caratteristiche comuni, che costringono i programmatori a non copiare il codice di incolla (ad esempio evitando il doppio problema di manutenzione)
• Ragionevole future prove del tuo codice (sebbene questa via sia difficile da ragionare)

In un recente progetto Java ho aggiunto con successo alcune classi astratte generiche perché ha soddisfatto alcune cose basilari: ha semplificato le cose per gli altri membri del team, ha applicato il modello che l'architetto aveva già proposto e aveva un codice comune che i programmatori non hanno bisogno di copiare e incollare. Era un modello semplice che l'architetto scriveva su persone ragionevolmente competenti che avevano ancora torto (a causa della complessità del sistema attuale in gioco), ma i generici indicano quale classe va dove.

Ovviamente non posso mostrare il vero esempio senza violare l'accordo di non divulgazione. Ma un esempio di ciò che ho fatto sarebbe stato fare il modello di strategia e applicarlo con i generici. Quindi questo è il modello di strategia:

Eperconsentireaiprogrammatoridiapplicarequestomodello,puoiaggiungereiltipogenericosuContextchedovrebbeutilizzarequalcosachehauntipoStrategy.Alivellodicodice,sarebbesimileaquestoinJava:

//declarethegenericContextclassthathasatype"S" 
// that is an upper bound class of Strategy
public class Context <S extends Strategy> {
    S strategy;

    // Constructor with an initial strategy
    public Context(S initialStrategy) {
        this.strategy = initialStrategy;
    }

    public void doSomething() {
      strategy.execute(); // assumes that Strategy has an execute() method.
    }

    public void setStrategy(S strategy) {
        this.strategy = strategy;
    }
}

Puoi farlo praticamente con qualsiasi modello, per quanto ne so. Assicurati di poter testare il design generico / modello con i test unitari per verificare che funzioni, in modo da avere fiducia nella progettazione del codice.

Se ai tuoi colleghi non piace l'idea, allora non prenderla sul personale, potrebbe non essere stata resa facile come soluzione per loro da gestire come pensavi. Ecco perché dovresti proporre una soluzione generica / modello prima di iniziare a implementarla. Devi ancora lavorare insieme ai tuoi colleghi per risolvere il problema in un modo diverso.

Ci sono sempre diversi modi per fare la stessa cosa. Se il tuo uso di modelli è un uso improprio di modelli, allora dovrebbe fallire la revisione del codice.

Tuttavia, se il tuo codice fallisce la revisione, perché non capiscono i modelli, allora il problema è di tipo diverso. In tal caso, consigliali (in un modo carino) per imparare i modelli.

Ciò di cui hai a che fare qui è una raccolta di pregiudizi. Le persone preferiscono lo status quo, un pensiero di gruppo si è sviluppato e l'argomento è stato affrontato alcune volte in modo che le persone si siano trincerate nelle loro convinzioni.

Una delle strategie più efficaci qui è concentrarsi su una piccola vittoria. Ho letto il seguente esempio in un libro : l'autore era un fedele utente non-Apple . Non le piacevano e non voleva avere niente a che fare con loro. Ha avuto molte discussioni con persone con un atteggiamento pro-Apple, e ognuno ha semplicemente spinto i talloni più a fondo nel terreno. Poi qualcuno le ha comprato un iPod shuffle e così, i suoi pregiudizi sono scomparsi. Non le ha fatto desiderare di acquistare solo prodotti Apple, ma la rigida posizione anti-Apple radicata era stata sostituita da un punto di vista più equilibrato. C'era spazio per il compromesso, e lei ha finito per convertirsi lentamente in Apple.

Quindi non cercare di convincere tutti tutti in una volta: avrà l'effetto opposto. Concentrati su una piccola cosa, e il resto accadrà da solo. Basta sbarazzarsi della natura a due facce dell'argomento in modo che le persone possano attraversare a poco a poco, invece che tutte insieme.

Il punto specifico su cui concentrarsi dipende dalla tua situazione, ma ecco una sola idea: la divisione che disegni tra le librerie e il "codice reale" sembra molto innaturale. Dal mio punto di vista, un programmatore che fa un'applicazione dovrebbe spendere l'80% del suo tempo in una libreria per il tipo di applicazione che sta facendo e il 20% che usa quella libreria per creare l'applicazione. Tutto il codice che vale la pena conservare dovrebbe essere considerato una biblioteca. Suggerirei ai tuoi superiori di generalizzare parte del tuo codice in una biblioteca interna (se non l'hai già fatto). Secondo la loro logica, dovrebbero usare i generici per questo, e dalla stima sopra, l'80% del tuo codice può finire all'interno della libreria. Una volta che tutti usano i generici dall'altra parte, dovrebbero abituarsi e i pregiudizi dovrebbero svanire.

Nota "comprensibile". Se il revisore del codice non vede il vantaggio dei generici, allora tutto il <<<>>> -stuff è solo un rumore incomprensibile che non è necessario.

Suggerirei di dare un'occhiata al numero di bug attuali (aperti o riparati di recente) contenuti nel database dei bug che potrebbero essere stati evitati usando i generici. Cerca ClassCastExceptions.

Nota anche che se non hai bug che potrebbero essere evitati usando i generici, i tuoi colleghi hanno un punto in cui non ti servono.

Sarei facile con questo. Mi sono trasferito da Java 1.4 a 1.6 un paio di anni fa, e generici è stata una vera scossa. È semplice e molto utile se stai cercando di destreggiarti tra collezioni, mappe e altre strutture. Tuttavia, scrivere classi che acquisiscono dati generici come parametri, manipolarli e passarli ad altre classi diventa rapidamente monumentalmente confuso. Ricevo grandi soddisfazioni dal far funzionare tutto, ma mi chiedo se valga la pena dedicare tempo e sforzi aggiuntivi. Temo anche che un buon numero di programmatori Java non riescano mai a farcela.

Ancora alcuni pensieri a caso dal mio viaggio generico finora:

• ClassCastExceptions si verifica in fase di esecuzione, ma in genere vengono visualizzati nelle prime esecuzioni e sono facili da risolvere.
• Ogni articolo che ho letto sui generici afferma che a volte semplicemente non funzionano e devi usare @SuppressWarnings(value="unchecked") occasionalmente. Come fai a sapere se sei oltre i limiti dei generici, o se sei semplicemente stupido e hai bisogno di pensare di più?
• Può essere difficile applicare @SuppressWarnings(value="unchecked") a una sola riga.
• Ho aggiunto alcuni fantastici farmaci generici a una delle mie classi. Ho conosciuto diversi programmatori che avrebbero potuto migliorare la classe prima di generarla, che non avrebbe mai potuto toccarla e ottenere una compilazione pulita in seguito.

Generics ha ripulito il mio codice e mi ha avvertito dei problemi troppe volte per poterlo rifiutare, ma vedo anche un aumento del tempo di sviluppo, del tempo extra dedicato all'addestramento e programmatori Java costretti a lavorare in C #, C, e Visual Basic ... o Java 1.4. Mi concentrerei sulla scrittura di codice che i tuoi colleghi possano capire. Se riesci a inserire qualche generico comprensibile, fantastico. Vedo i generici Java come un'opportunità / problema che non è stato ancora capito.