Come trasformare i programmatori COBOL in programmatori moderni [chiuso]

Question

Lavoro in un ambiente aziendale in cui la mentalità è ampiamente dominata da persone che hanno iniziato a programmare con COBOL IMS e CICS.Oggi la maggior parte di loro programma con linguaggi più moderni come Java.Ma se guardi il loro codice e le decisioni di progettazione non è cambiato molto

• metodi lunghi molti schermi
• un'enorme quantità di variabili globali o la loro moderna incarnazione, il modello singleton
• circa 30 definizioni di variabili all'inizio del metodo
• globali anziché parametri
• invece di utilizzare un metodo di fabbrica, un'enorme istruzione switch
• uso improprio delle colonne della tabella del database perché "c'era abbastanza spazio rimasto"
• ...

Queste persone non sono stupide, la maggior parte di loro sono molto intelligenti.Ma spiegare loro le moderne pratiche di codifica è come descrivere i colori a un cieco.Hai qualche esperienza o consiglio per insegnare loro un approccio più moderno senza offenderli?

Answer 1

Il modo migliore per imparare come codice dovrebbe essere è quello di leggere bene il codice. Provate a dare un esempio con il proprio stile di codifica e delicatamente sottolineare i loro errori durante le revisioni del codice. E 'essenzialmente solo una questione di prospettiva; come si suol dire, se l'unico strumento che hai è un martello, ogni problema sembra un chiodo. Questi i programmatori vedono tutto in termini di lingue che hanno esperienza in, e così anche quando la scrittura di Java, il loro processo di pensiero è in COBOL. Il loro stile di codifica è semplicemente un riflesso del loro processo di pensiero.

A parte ciò, sono tutti di leggere codice completo.

Answer 2

Compra loro una copia di "Code Complete" e li hanno scrivere una relazione libro.

Answer 3

Usa un controesempio alla volta con le parole che lo spiegano Perché il tuo percorso è migliore, meno doloroso, li aiuta a tornare a casa dalle loro famiglie in tempo, ecc.È molto importante procedere uno alla volta, però, se stai davvero cercando di far crescere una cultura in modo organico.Qualche esempio:

• Metodi molto lunghi:Vedi, ho esaminato il tuo metodo lungo e ho capito che stai utilizzando la stessa logica in due punti.L'ho risolto e ora non devi digitare lo stesso codice due volte.Inoltre, dobbiamo testare quella parte solo una volta.
• Variabili globali e molte definizioni all'inizio di ogni metodo:Vedi, ho spostato le tue variabili più vicino al loro punto di utilizzo.Ora, questo codice di test che ho scritto che ha effetti collaterali sul tuo codice con un puntatore nullo che uccide il sistema non è in grado di avere effetti collaterali sul mio.
• Interruttore gigante:A volte, un passaggio gigante è molto difficile da evitare (e talvolta non dovresti).Detto questo, se stai cercando di costruire un oggetto, la parola "fabbrica" ​​è significativa.Vedi, il mio metodo factory fa effettivamente la stessa cosa della tua factory, ma lascio che il polimorfismo (ad esempio) sostituisca parte della gestione dei casi di commutazione.Meno codice = meno bug = arriviamo a casa in tempo.

A proposito, non ho mai avuto successo nell'assegnare compiti di lettura agli ingegneri (anche se Kathy menziona Refactoring, che è un'ottima fonte esattamente per questo genere di cose).Ciò che funziona per me è per Me leggere i libri, utilizzare le tecniche suggerite, dimostrare il successo e come mi sta semplificando la vita e Poi, quando subentra la frustrazione di "com'è possibile che tu sappia come sistemare tutte queste cose?!", digli che c'è un libro di istruzioni.Le persone intelligenti te lo strapperanno dalle mani così velocemente che perderai la pelle nel processo.

Answer 4

La mia realizzazione che non ci sarebbe forse mai essere un incontro di menti tra me e programmatori COBOL è venuto molti anni fa, quando ero un istruttore insegnare corsi di formazione commerciali su C e C ++. Avevo appena completato la sezione del corso di malloc () e free (), con soddisfazione generale della maggior parte degli scommettitori, quando il ragazzo si COBOL sul corso si avvicinò e chiese:

"Ma che cos'è questa roba 'memoria'? E perché mai dovrei desiderare di usarlo?"

Per essere un po 'più costruttivo, esperienza NY è che i programmatori COBOL sono stati addestrati a pensare a due cose:

• il record
• cose che fate per il record

Questo è in realtà non troppo lontano da OO, e credo che l'idea di base è necessario far passare è che ci saranno leggermente diversi tipi di record di, con diverse cose che dovete fare per loro, e il modo migliore di trattare con questo è quello di mettere il record e le cose che hanno bisogno di fatto insieme per creare oggetti.

Answer 5

Chiedete loro di scrivere Java; e hanno forti standard di revisione del codice. Quando il loro metodo multi-pagina non passa la revisione del codice, perché non è buon codice, spiegare loro perché non è buon codice. Ad un certo punto, possono diventare infastidito; Non credo che sia davvero possibile cambiare le abitudini che sono stati "fissati in" per un lungo periodo di tempo senza un po 'di fastidio. Ma finché il recensore (s) rimangono ragionevole e coerente, cominceranno a vedere il punto nel corso del tempo. L'esperienza è davvero l'unica soluzione per questo genere di cose, e questo è davvero l'unico modo per ottenere l'esperienza e lo hanno essere diretto (invece di imparare dai propri errori).

Answer 6

Così come codice completo (probabilmente dopo che), invitali a leggere Refactoring: migliorare la progettazione di esistere Codice (almeno l'introduzione). Si discute sia il codice standard di odori e come risolverli.

Non suono, tuttavia, che ciò di cui hanno bisogno è una panoramica di come pensare in modo orientato agli oggetti. Io non sono certo quello che è il miglior libro per questo.

Answer 7

Ho il forte sospetto che la loro mentalità è un "ciò che funziona" uno, non un "qual è il modo migliore per farlo" mentalità. Se quello che stanno facendo sembra funzionare, forse non stanno facendo così male come si pensa.

Io lavoro sia con COBOL e del codice .Net. La mia esperienza personale ha incontrato un sacco di esempi in cui volevo fare qualcosa di un migliore modo che il mio supervisore, che è del tutto nella mentalità COBOL. In molti casi, ha sostenuto l'opzione più semplice, che non può essere stato elegante, ma è stata la decisione giusta. E con decisione giusta Voglio dire, meglio per l'azienda. Ci sono alcune cose che dovete tenere a mente su ciò che è bene per la squadra e l'applicazione:

• Funziona? Se quello che stanno facendo lavori, senza più problemi che il vostro codice, e possono mantenere facilmente come si può, allora può essere solo una preferenza. Se questo non è il caso, allora si può puntare al codice e dire: "Questo è stato più facile da mantenere, vedere come ci sono voluti solo 30 minuti per risolvere il problema e non ha avuto problemi?" Non cercare di strofinare il naso in essa, ma dare l'esempio. E 'molto meglio a dire "vedere come questo ha funzionato per me" che "si dovrebbe fare in questo modo perché realizzare qualcosa per te".
• Tutti possono capirlo? Programmazione con le più recenti metodologie modaiolo può sembrare freddo, ma se la metà della squadra non può eseguire il debug del codice, senza introdurre due volte il bug, è perché semplicemente non sanno come si suppone quel modo di fare le cose al lavoro. Assicurarsi che non si introducono nuove cose più veloce rispetto alla squadra li può assimilare. Ciò può essere aggravante quando non si arriva a usare LINQ o qualunque sia la cosa nuova è, ma è la mossa giusta per l'azienda.
• è necessario? BACIO. O come è stato parafrasato Albert Einstein, "Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice."

Answer 8

Si può farli iniziare a lavorare su buon codice in qualche modo? Facendo piccoli cambiamenti?