Come convincere il team di programmazione ad abbandonare i vecchi metodi?

Question

Questa è più una questione di programmazione orientata al business che non riesco a capire come risolvere.Lavoro con un team di programmatori che lavorano con BASIC da oltre 20 anni.Sono stato chiamato per aiutare a scrivere lo stesso software in .NET, solo con aggiornamenti e pratiche moderne.Il problema è che non riesco a convincere nessuno degli altri 3 membri del team (tutti programmatori BASIC, anche se ora fa anche .NET) per capire come realizzare correttamente un database relazionale.Ecco la cosa che non capiranno:

Fondamentalmente abbiamo una transazione che tiene traccia delle informazioni sui tag di un cliente.Dobbiamo essere in grado di tenere traccia delle transazioni attuali e delle transazioni passate.Nel vecchio sistema veniva utilizzato un database flat-file che aveva una tabella che conteneva i record con la transazione corrente di base del cliente e un'altra transazione che conteneva tutte le transazioni precedenti del cliente insieme a importanti informazioni monetarie.Per evitare ridondanza, sovrascriverebbero la transazione corrente con la cronologia delle transazioni (prima è stato aggiornato il file della cronologia, poi quello corrente). È totalmente inutile poiché è necessaria solo una tabella delle transazioni, ma il mio supervisore o uno qualsiasi degli altri due miei collaboratori -I lavoratori non riescono a capirlo.Come posso convincerli esattamente a vedere la luce in modo da non dover fare quantità ridicole di lavoro e finire per colpire il database troppe volte?Grazie per l'input!

Answer 1

Innanzitutto devo ammettere che dalla tua descrizione non mi è del tutto chiaro quali siano effettivamente le strutture dati e i flussi logici nelle strutture esistenti.Questo per me implica che forse non sei chiaro nemmeno ai tuoi colleghi, quindi una delle tue priorità deve essere quella di saper spiegare, verbalmente o preferibilmente per iscritto e con diagrammi, la situazione attuale e la proposta di sostituzione.Per favore, prendila come un'osservazione piuttosto che come una critica alla tua domanda.

In secondo luogo, trovo piuttosto notevole che programmatori con 20 anni di esperienza non comprendano i database e le transazioni relazionali.La codifica di file flat è uscita dal mainstream molto tempo fa: ho gestito per la prima volta database relazionali in un contesto commerciale nel 1988 ed erano piuttosto comuni a metà degli anni '90.Su quale settore e tipologia di prodotto state lavorando?Mi sembra possibile che tu abbia a che fare con una sorta di sistema incorporato o comunque "insolito", nel qual caso devi assicurarti di non avere qualche tipo di problema di comunicazione e di trascurare un grande elefante questo non ti è stato fatto notare: non saresti il ​​primo "consulente" inserito in un team che è stato creato in qualche modo senza ricevere le informazioni appropriate.Detto questo, questi negozi arcaici esistono ancora: uno dei sistemi dei miei attuali clienti si interfaccia con un sistema basato su file flat codificato in COBOL, e sì, è un inferno da gestire ;-)

Infine, se sei completamente sicuro del tuo terreno e ti trovi di fronte a un team che non accetta i tuoi consigli - e il codice dimostrativo è una buona idea se puoi risparmiare tempo - allora probabilmente dovrai accettare il decisione con garbo e muovine uno.Io stesso in questa posizione cercherei di astrarre il problema: gli aggiornamenti del database possono essere spostati in procedure memorizzate, ad esempio, in modo che il codice per aggiornare entrambe le tabelle sia nell'SP e possa essere modificato in un secondo momento per passare allo schema senza un corrispondente modifica dell'applicazione?Assicurati che le tue argomentazioni siano ben documentate e registrate in modo da poterle rivedere in seguito qualora se ne presentasse l'occasione.

Non sarai il primo programmatore a dover implementare una soluzione non ottimale a causa della politica aziendale: usala come esperienza di apprendimento per il tuo sviluppo personale sulla gestione di tali situazioni e commisera te stesso con il pensiero che verrai pagato per l'ulteriore lavoro.Spesso il fattore decisivo in tali discussioni non è la logica, ma il "peso della reputazione" che tu stesso metti sul tavolo: sembra che dopo essere stato coinvolto non hai molto di quel tipo di influenza con la tua squadra, quindi tu potrebbe dover lavorare per guadagnare una reputazione eccellendo nell'implementazione di ciò che accettano di fare prima di avere una reputazione sufficiente nei casi successivi: devi prima essere modificato!

Answer 2

A volte non puoi.

Se leggi alcuni libri su XP, spesso dicono che uno dei tuoi maggiori ostacoli convincerà la tua squadra ad abbandonare ciò che hanno sempre fatto.

In genere raccomandano di lasciare che le persone che non possono adattarsi ad altri progetti (o semplicemente lasciarli andare).

Le revisioni del codice potrebbero essere utili nel tuo caso. Le revisioni obbligatorie del codice di ogni riga di codice non sono inaudite.

Answer 3

A volte l'argomento migliore è un esempio. Scriverei un prototipo (o un sostituto se non troppo lavoro). Con un esempio da esaminare sarà più semplice vedere i pro ei contro di un database relazionale.

A parte ciò, i database di file flat hanno il loro posto in quanto sono molto più facili da " amministrare " di un vero database relazionale. Mantieni una mente aperta. ; -)

Answer 4

Penso che potresti dover dare l'esempio - quando la gente vede che " new " il modo in cui è meno lavoro lo adotteranno (fintanto che non ci strofini il naso).

Vorrei anche chiederti se il vecchio design sta effettivamente causando un problema o se è solo esteticamente fastidioso. È importante scegliere le tue battaglie: se il vecchio design non sta causando un problema di prestazioni o rendendo difficile la manutenzione del sistema, potresti voler lasciare solo il vecchio design.

Infine, se lasci il vecchio disegno sul posto, prova a astrarre l'interfaccia tra il tuo nuovo codice e il vecchio database, quindi se persuadi i tuoi colleghi a migliorare il design in un secondo momento puoi lasciare cadere il nuovo schema senza dover cambiare qualcos'altro.

Answer 5

È difficile estrarre molto, tranne la frustrazione generale dalla domanda originale.

Sì, ci sono molte tecniche e abitudini che i long-time acquisiscono nel tempo e che possono essere inutili e persino costose alla luce dei cambiamenti tecnologici. Alcune cose che avevano senso quando la potenza di elaborazione, la memoria e persino il disco erano costosi possono essere tentativi folli di ottimizzazione ora. È anche vero che le persone accumulano cattive abitudini e cattivi schemi di programmazione nel tempo.

Devi stare attento però.

A volte ci sono buone ragioni per le cose che fanno quei vecchi timer. Purtroppo, potrebbero anche non essere in grado di verbalizzare il & Quot; perché & Quot; - se sanno ancora perché.

Vedo molto questo tipo di frustrazione quando i neofiti entrano in un negozio di sviluppo software aziendale. Può essere male anche quando l'ambiente è tutto tecnologia e strumenti abbastanza moderni. Se la maggior parte della tua esperienza è nella scrittura di applicazioni Web e desktop per piccole comunità molto di ciò che & Quot; conosci & Quot; potrebbe essere sbagliato.

Spesso ci sono requisiti per l'inserimento nel journal delle transazioni a un livello superiore a quello che può fare il vostro DBMS. Molto spesso può essere necessario andare oltre la semantica delle transazioni DB al fine di garantire la correttezza della sequenza temporale, una volta e una volta soltanto l'aggiornamento, la resilianità e la non ripudio.

E questo non inizia nemmeno ad affrontare i problemi legati alla scalabilità aziendale o interaziendale. Quando inizi ad avvicinarti a mezzo milione di transazioni complesse al giorno, scoprirai che la tecnologia RDBMS fallisce. Poiché i database relazionali non sono progettati per gestire elevati volumi di transazioni, spesso è necessario rompere con i paradigmi standard per la normalizzazione e l'aggiornamento. Le tecniche di blocco RDBMS convenzionali possono distruggere la scalabilità, indipendentemente dalla quantità di hardware che si presenta al problema.

È facile scartare tutto ciò come durezza o malinteso generale, persino incompetenza. Ma fai attenzione perché non è sempre così.

E a proposito: ci sono altri modelli oltre a RDBMS, e l'alternativa a un RDBMS non è necessariamente " flat files " - contrariamente all'esperienza della maggior parte dei programmatori di oggi. Esistono DBMS gerarchici transazionali in grado di gestire un throughput molto più elevato rispetto a un RDBMS. IMS è ancora molto vivo nei grandi negozi IBM, ad esempio. Altri fornitori offrono software simili per piattaforme diverse.

Ovviamente in un negozio di 4 persone forse nulla di tutto ciò vale.

Answer 6

Iscrivili a corsi di formazione decenti e poi spetta a te convincerli che con le nuove tecnologie molto più è possibile (o almeno più facile!).

Ma penso che la cosa più importante qui sia che formatori professionisti e certificati insegnino loro le basi prima. Saranno più colpiti da questo invece che solo da uno dei loro colleghi che dice loro: & Quot; ehi, perché non usare questo? & Quot;

Post correlato qui .

Answer 7

Quanto segue potrebbe non applicarsi nella tua situazione, ma fai ben poca menzione dei dettagli tecnici, quindi ho pensato di menzionarlo ...

A volte, se i modelli di accesso sono molto diversi per i dati correnti rispetto ai dati storici (sto realizzando questo esempio, ma dico che ai dati attuali si accede 1000s di volte al secondo e accede a un piccolo sottoinsieme di colonne e tutti i dati attuali si adattano a meno di 1 GB, mentre, ad esempio, i dati storici utilizzano migliaia di GB, si accede solo 100 volte al giorno e l'accesso è a tutte le colonne),

quindi, ciò che i tuoi colleghi stanno facendo avrebbe perfettamente senso, per l'ottimizzazione delle prestazioni. Separando i dati correnti (albiet in modo ridondante) è possibile ottimizzare gli indici e le strutture di dati in quella tabella, per gli accessi a frequenza più elevata che non è possibile eseguire nella tabella storica.

Non tutto ciò che è " accademicamente " ;, oppure " tecnicamente " corretto da una prospettiva puramente relazionale ha senso se applicato in una situazione pratica reale.