Formazione di vecchi programmatori di Fortran per migliorare la progettazione del codice. suggerimenti? [chiuso]

I programmatori esperti procedurali - se sono bravi - hanno modelli di costruzione del codice interiorizzati che tendono all'orientamento agli oggetti, ma non se ne rendono conto . Allo stesso modo, i buoni progettisti di database tendono a creare tabelle in terza forma normale, anche se non hanno mai sentito la normalizzazione del database.

è probabile che le grosse palle di fango che vedi sono antichi artefatti , carichi di decenni di debiti tecnici e di cambiamenti di emergenza.

insegnando l'OOP ai programmatori procedurali (avvertenza: molti anni fa) ho scoperto che partire da ciò che sanno e ciò che pensano sia buono e da lì costruire in oggetti e classi rende il "click" molto più veloce di una lezione sull'astratto concetti e codifica di animali parlanti.

esempio: una buona funzione utilizza tutti i suoi parametri e solo i suoi parametri. una buona struttura dati contiene solo elementi logicamente correlati alla "chiave". un buon modulo di solito si concentra su una struttura di dati (o un aggregato) e contiene le funzioni che producono, utilizzano e consumano la struttura dei dati.

ricorda che le abitudini che questi programmatori hanno sviluppato li hanno serviti bene (per quanto ne sappiano!) da molto tempo; non dire loro che hanno bisogno di "dimenticare tutto ciò e ricominciare da capo", questo genera solo risentimento. Di 'loro che tutto ciò che già sanno è ancora corretto, è solo riorganizzato . Quindi mostra loro come riorganizzarlo, quindi mostra loro i vantaggi della riorganizzazione.

un esercizio utile potrebbe essere quello di fare in modo che codifichino qualcosa di semplice, ma utile "alla vecchia maniera", quindi passare attraverso il refactoring che lo farebbe funzionare "alla nuova maniera". Il metodo socratico (porre domande invece di mostrarle direttamente) è del tutto appropriato per questo tipo di esercizio.

buona fortuna!

Come ben sai, questo è molto diverso dall'insegnare ai ragazzi del college le basi di OO. Stai parlando con persone che hanno scritto codice funzionante e distribuito con queste strategie per un po 'di tempo.

Invece di concentrarsi su cosa , vorrei concentrarmi sul perché . Penso che il modo migliore per dimostrare il perché è iniziare con un codice OO ben scritto a cui è necessario aggiungere una funzionalità. Mentre estendi la funzionalità del codice, puoi dimostrare dove è facile aggiungere i ganci necessari per la nuova funzionalità.

Leggere il codice OO è il modo migliore per capirlo, nella mia esperienza.

Questa è una risposta da uno sfondo Java, ma sono sicuro che ci siano opzioni equivalenti altrove. Vorrei che i tuoi ragazzi usassero JUnit o un kit simile di test per unità automatizzate.

1) Ho trovato un certo numero di persone "procedurali" che hanno difficoltà con l'intera transizione a OO semplicemente per non capire da dove inizia l'intera cosa. Un framework di test unitario può fornire una curva di apprendimento più semplice piuttosto che doversi preoccupare di come funzionano i server delle applicazioni.

2) Scrivere buoni JUnits ti spinge a scrivere accidentalmente un buon codice OO ... e una volta che hai trovato il bug ti ritrovi a sfornare pezzi utili di codice riciclabile lasciato a destra e al centro ... Questo genere di cose potrebbe andar bene aiuta con la motivazione a passare da oldskool a newskool ...

Inoltre, una volta che hai un po 'di gente nel groove, puoi ottenere dei buoni plug-in automatici di tipo "checkstyle" per il tuo IDE che metteranno in evidenza cose come lunghezza di file eccessiva, lunghezze dei metodi, variabili globali, ecc. ecc. Quindi, se JUnit o simili riescono a farli superare la voragine di voler sviluppare in modo OO, alcuni strumenti automatici possono quindi evidenziare le aree che vogliono rielaborare con la loro nuova comprensione!

Ho trovato utile usare un framework che usava OO. Sono stato costretto a pensare a come usarlo e mi sono chiesto perché le cose fossero fatte in un certo modo. So che non è l'intera soluzione, ma mi ha aiutato in quel momento.

Il framework che ho usato era la libreria Open Class per OS / 2. Un sacco di cose GUI ma anche collezioni, gestione delle stringhe, ecc. Che ne dici di far usare i tuoi ragazzi .Net e Forms. Tratteranno oggetti come Window e Control, chiameranno i metodi e forse noteranno la gerarchia dell'ereditarietà.

Solo un'idea ...

Fai un semplice esempio di animale, gatto, cane che dimostra l'ereditarietà senza prima scrivere una singola riga di codice. Assicurati che capiscano il concetto di programmazione orientata agli oggetti prima ancora di iniziare la sintassi.

È facile provare a mettere in relazione concetti vecchi con nuovi concetti, se cerchi di farli capire da soli, quindi eviterei di farlo finché non pensi di capire perché lo fanno in quel modo particolare. Se glielo spieghi in termini in cui possono vedere i vantaggi di farlo in quel modo, avrebbero un motivo per non usare il loro vecchio modello di Fortran.

Per quanto riguarda la lunghezza dei metodi, prendi un metodo lungo come esempio e poi sostituiscile con metodi di bitesize con le convenzioni di denominazione appropriate in modo da poter dimostrare che i metodi lunghi sono brutti e come possono migliorare la situazione.