Utilizzo di un'applicazione legacy Rails

Question

Ho un'app Rails molto vecchia e scritta male. Ci sono circa 9000 linee di codice e zero test. La maggior parte del codice si trova nei controller e, peggio ancora, ci sono tonnellate di chiamate API esterne, chiamate di sistema a script casuali, ecc.

Non c'è nemmeno un ambiente di sviluppo, tutto è impostato per funzionare con i database di produzione. Beh, non solo un database, ci sono circa 10 diversi database, dal momento che l'app è una sorta di backend amministratore per un sito più grande.

La mia prima idea era di ottenere una copertura di test almeno in qualche modo decente sulle parti su cui ho intenzione di lavorare, ma non riesco a far funzionare la cosa in nessun altro posto rispetto ai server di produzione.

Inoltre ci sono tonnellate di vecchie gemme e avvertimenti deprecati, ma non riesco nemmeno a pensare di aggiornare le gemme finché non ci saranno test. Riscrivere il tutto non è un'opzione, e dovrò aggiungere/cambiare cose presto.

Non sono proprio sicuro di come affrontare la verifica di un'applicazione del genere, dal momento che ci sono così tante cose che possono andare storte. Quello che mi piacerebbe davvero fare, è scrivere alcuni test di integrazione e poi avviare il refactoring, ma non posso farlo in un ambiente di produzione.

Test di unità di scrittura con mazzetti e mock non mi sembra utile, dal momento che il codice su cui sto andando a lavorare in pratica deve essere riscritto da zero.

Quali sono alcuni passaggi che è possibile eseguire per duplicare fondamentalmente un ambiente di produzione hugeass complesso sulla mia macchina di sviluppo, quindi posso fare cose in isolamento?

modifica: Un piccolo aspetto divertente dell'app. Quando ho provato ad eseguirlo per la prima volta, continuava a congelarsi senza alcun messaggio di errore ... fino a circa mezz'ora dopo ho scoperto che il timeout per la connessione a un database (che non era disponibile) era impostato su 90 minuti!

Answer 1

Quindi questo è un evento relativamente nuovo/raro, perché le applicazioni "LEGACY" delle rotaie non sono ancora troppo popolari (ancora piuttosto giovani).

Tuttavia, mi sono imbattuto in alcuni scritti diversi su come testare applicazioni di binari legacy (non testate). Alcuni che vi consiglio sono:

1. This slideshare
2. capitolo 18 di "Rails Test Presciptions" dal Pragmatic Programmers.

La cosa fondamentale e più importante è quella di far funzionare una sorta di imbracatura di prova. Ciò significa far funzionare le fabbriche, far funzionare il database di test, far funzionare il rake (anche se ciò significa eliminare test non funzionanti). Da quel momento, si torna indietro e si testano i moduli quando ne avete bisogno, così come si è certi di testare tutti i nuovi pezzi di codice che si aggiungono al progetto.

Questo è un compito estremamente doloroso, e vi applaudo per aver cercato di farlo nel modo giusto.

Cheers!

Answer 2

Benvenuti su questo tipo di barca orribile.

L'ultima volta che è successo a me, ho scritto il numero di prove con Capybara e:

• ho controllato cosa ci si aspettava da creare o non in db ...

• ... poi bit dopo bit, sto refactoring

In questo caso, non vedo altro mezzo che avvicina l'applicazione al più alto livello e controllare il risultato al più basso, senza alcuna stub/finta.

Answer 3

Quale versione di

Rails, 
Ruby, 
Mysql socket, 

sta utilizzando?

Ho dovuto lavorare su un'applicazione come questa. Ecco quello che ho dovuto fare:

Copy DB over, 
do not run the migrations, 
installed gems as production environment, 
do not update gems. 

mia app utilizzata una versione molto particolare gemma (gettext v = 1.10)

Answer 4

ho lavorato in diverse missioni di salvataggio, per lo più progetti di PHP che erano davvero male, ma non solo - i proprietari di prodotti disperati lasciati dai cattivi programmatori dell'80% pagano bene per finire i loro progetti abbandonati :).

• Il mio approccio è usare la forza bruta.
• Avvia lo sviluppo e aggiusta le cose fino a quando non lo fai funzionare, per mezzo della pura potenza - correggi, prova, correggi, prova.
• È farlo funzionare alla fine.
• 9000 righe di codice non sono codice molto, direi che è di dimensioni ragionevoli per codice legacy errato, sarebbe potuto essere molto peggio.
• Iniziare il refactoring lentamente a poco a poco.
• Queste attività avranno bisogno di tempo, quindi non aspettarti che accada in una volta.