È meglio usare le cattive pratiche preesistenti o le buone pratiche che non si adattano bene al vecchio codice?

Dovresti scegliere un design migliore se:

1. Prendi parte a gran parte della codifica futura

2. A lungo termine, il design migliore non è più costoso per il cliente. Ad esempio, ho assistito a "refactoring" pluriennali per progetti che sono stati interrotti entro la fine dell'anno.

Devi scegliere "lo stesso cattivo stile" se:

1. Stai solo aiutando. Non è realistico pensare di poter prendere un gruppo esistente e portarlo a standard di progettazione più elevati se si è solo una parte di una compilazione part-time sul progetto. Il design migliore è soggettivo e ha quasi sempre una curva di apprendimento. Se il nuovo progetto non viene appreso dal resto del team, il progetto finirà con un miscuglio di stili e il tuo codice migliore potrebbe finire nella pila di cose che nessuno cambia perché non riescono a capire esso. Nel tuo esempio precedente, cosa succede se ci sono aggiornamenti al software di terze parti?

2. Sacrificare il design "migliore" ti porterà un vantaggio commerciale tangibile. Come aggiungere male la funzione X, otterrai un grosso contratto, ma mancare la scadenza ti farà finire senza nulla. È qui che entra in gioco il conflitto storico tra mgmt e il team tecnico. Come ristrutturare una casa, qualcuno deve decidere quando pagare. È possibile pagare il debito inizialmente vivendo senza elettricità o impianti idraulici per un anno. Oppure puoi pagare 3 volte tanto con il vantaggio di avere quelle utility.

A lungo termine, è meglio usare le buone pratiche. Risparmierà tempo e impegno poiché le modifiche impiegheranno meno tempo per l'implementazione.

Se possibile, fai piccoli passi per rifattorarti su una buona pratica (per esempio: in SQL che spezzerebbe le tabelle denoramlizzate a quelle normalizzate e usando le viste con i vecchi nomi delle tabelle).

Noterai che ho detto a lungo termine che il triangolo "qualità, tempo, denaro" si applica anche qui (ad esempio, scegli due). Se non hai il tempo necessario per andare con le vecchie pratiche, ma questo significa che stai aggiungendo al problema e che il tuo progetto dovrà anche essere corretto.

Se continui a lavorare e aggiungi il codice di una cattiva progettazione, non avrai mai una base di codice che usi un buon design. Cerca il più possibile di utilizzare un buon design e un refactoring di buon design.

Beh, penso che dipenda molto da ogni caso. Se le prestazioni e il design lo consentono, è meglio utilizzare le buone pratiche. Ma se per esempio, se quella tabella è una tabella ad accesso elevato, la creazione di un trigger per la sincronizzazione potrebbe avere un impatto negativo sulle prestazioni.

Ora, il tuo cliente non vedrà che hai usato un design migliore, vedrà solo che la tua soluzione ha rallentato il suo sistema. Questo tipo di decisione dovrebbe essere presa caso per caso, e dovresti usare la tua esperienza e i tuoi criteri per decidere.

Penso che tu abbia fatto la scelta giusta.

Per quanto possibile, dovresti isolare il tuo codice applicativo dal cattivo design dei dati.

Stai aggiornando le loro tabelle? In caso contrario, quindi creare viste SQL per presentare tali tabelle in un modo conveniente per l'applicazione. Le viste SQL sono relativamente facili da scrivere e molto più facili da test rispetto al codice dell'applicazione.

Se è necessario aggiornare le tabelle legacy, considerare la possibilità di scrivere stored procedure per gestire gli aggiornamenti. Sono un po 'più complessi da scrivere, ma possono essere testati istantaneamente.

Per mantenere il vecchio codice in sincrono quando normalizzi un database con trigger è una buona soluzione se è temporanea. L'obiettivo dovrebbe essere quello di cambiare il vecchio codice, ma quando si tratta di una terza parte, potrebbe non funzionare. Dovrai rimanere aggiornato sulle loro modifiche allo schema.

Accumulare sempre più funzionalità sul codice errato creerà problemi continui. I work-arounds diventano la norma. Gli utenti saranno frustrati perché i cambiamenti richiederanno troppo tempo e probabilmente introdurranno altri bug o limitazioni. Chi vuole essere il programmatore per dire che non possiamo farlo invece di non dovremmo farlo?

Alcuni codici possono essere lasciati da soli; non abbiamo sempre questo lusso.

Hai a che fare con il debito tecnico qui. In breve, il debito tecnico implica interesse, che devi pagare nel tempo e, a un certo punto, devi rimborsarlo.

Il tempo di Develloper costa denaro, quindi il debito tecnico può essere visto come il vero debito e costa denaro reale.

Hai fondamentalmente due soluzioni principali e molte soluzioni intermedie. Puoi decidere di non voler rimborsare quel debito ora e continuare a pagare gli interessi. Ovviamente, questo costerà più a lungo termine, ma ti permetterà di avere dei risultati in questo momento. Puoi anche scegliere di rimborsare quel debito, in modo da non andare più avanti finché non lo rimborserai, ma, alla fine, sei libero da interessi.

Di solito hai scadenze per la consegna, e mancare una scadenza causerà diffidenza nei confronti del cliente, e alla fine lo perderai. Questo potrebbe essere un valido motivo per scavare il debito tecnico: consideri che ciò che guadagni con il cliente valga l'enfasi extra del debito tecnologico.

Sai che alla fine devi adottare la nuova metodologia, otherwize, riceverai sempre più debiti e alla fine fallirai (ora, quando le persone decidono di ricominciare da zero o quando il progetto fallisce male).

Devi pianificare come cambierai la base di codice esistente e passerai a una nuova pratica nel tempo, e divulghererai la modifica un po 'alla volta su base giornaliera. Ad un certo punto, quando il refactoring porterà ad altre perdite, considera quale sia la peggiore e scegli quella migliore.

Il costo del non refactoring aumenterà nel tempo (sono gli interessi del debito tecnico). Quindi questa diventerà alla fine la scelta più costosa.

Assicurati che il tuo capo comprenda il concetto di debito tecnico. Anche con precauzione, creerai un debito tecnico. Ad un certo punto, denaro da utilizzare per rimborsarlo. Quando crei il debito tecnico di proposito, DEVI avere una ragione valida per farlo e vedere il debito come un investimento (proprio come il debito reale). In tutti gli altri casi, basta NON FARE il debito tecnico di proposito.

Potresti essere interessato a metodologie per evolvere DB e implementare le seguenti evoluzioni: link

A proposito, è un compito difficile, quindi buona fortuna. Ne vale la pena!

Questo è un tipico problema di: "Devo raccogliere i benefici del mio lavoro ora o più tardi?" e non penso che ci possa mai essere una soluzione generica a quella risposta. Solo tu conosci tutti i fattori (tecnici e umani) coinvolti in tale decisione.

Tuttavia il tuo problema solleva una domanda interessante:

Il refactoring automatico del codice fa progressi sufficienti in modo che l'uniformità del codice debba essere valutata di più?

In definitiva, il cattivo design dovrebbe cambiare o morire. Oppure, non è un cattivo design. La vera domanda qui riguarda il costo del refactoring. Dalla tua domanda sembra chiaro che tu (o il tuo datore di lavoro) non sei disposto a pagare il prezzo adesso, e nello stato attuale della tecnologia, è improbabile che lo voglia mai.

Tuttavia, l'automazione del refactoring del codice sta facendo alcuni progressi. Se i compilatori possono ottimizzare i binari oggi, chi potrebbe dire che non ottimizzeranno il codice domani? A un certo punto, alcuni strumenti saranno disponibili, consentendo agli sviluppatori e ai progettisti di rifattorizzare il loro codice molto facilmente, al fine di adattarsi ai nuovi requisiti. Dopotutto, occuparsi di codice legacy è una delle maggiori sfide di oggi.

Se un tale strumento dovesse mai esistere (non mi sorprenderebbe che lo faccia già), sarebbe bene prenderlo in considerazione quando si prende una tale decisione.

Le buone pratiche sempre vincono quelle povere. Se il tuo codebase è disseminato di codice nel modo sbagliato, non dovresti semplicemente caricare le tue cose nello stesso modo, dovresti scrivere codice correttamente e poi cercare di educare tutti gli altri sul modo corretto.