Migliorare i sistemi davvero male

Question

Come inizieresti a migliorare su un sistema davvero difettoso?

Lasciami spiegare cosa intendo prima di raccomandare di creare unit test e refactoring. Potrei usare queste tecniche, ma sarebbe inutile in questo caso.

In realtà il sistema è così rotto che non fa ciò che deve fare.

Ad esempio, il sistema dovrebbe contare il numero di messaggi che invia. Funziona principalmente, ma in alcuni casi "dimentica" per aumentare il valore del contatore messaggi. Il problema è che molti altri moduli con le loro soluzioni alternative si basano su questo contatore che se correggessi il contatore il sistema nel suo insieme peggiorerebbe di quanto non sia attualmente. La soluzione potrebbe essere quella di modificare tutti i moduli e rimuovere le loro correzioni, ma con oltre 150 moduli che richiederebbero così tanto coordinamento che non me lo posso permettere.

Ancora peggio, ci sono alcuni problemi che hanno soluzioni alternative non nel sistema stesso, ma nella testa delle persone. Ad esempio, il sistema non può rappresentare più di quattro messaggi correlati in un gruppo di messaggi. Alcuni servizi richiederebbero cinque messaggi raggruppati insieme. Il reparto contabilità è a conoscenza di questa limitazione e ogni volta che contano i messaggi per questi servizi, contano i gruppi di messaggi e li moltiplicano per 5/4 per ottenere il numero corretto dei messaggi. Non c'è assolutamente alcuna documentazione su queste deviazioni e nessuno sa quante cose simili siano presenti nel sistema adesso.

Quindi come inizieresti a migliorare questo sistema? Quale strategia seguiresti?

Alcune cose aggiuntive: sono un esercito di un solo uomo che lavora su questo, quindi non è una risposta accettabile assumere un numero sufficiente di uomini e ridisegnare / riformattare il sistema. E in poche settimane o mesi dovrei davvero mostrare una certa progressione visibile, quindi non è un'opzione nemmeno fare il refactoring da solo in un paio di anni.

Alcuni dettagli tecnici: il sistema è scritto in Java e PHP ma non penso che sia davvero importante. Ci sono due database dietro, un Oracle e uno PostgreSQL. Oltre ai difetti menzionati prima, anche il codice stesso ha un odore, è davvero mal scritto e documentato.

Informazioni aggiuntive:

Il problema del contatore non è un problema di sincronizzazione. Le istruzioni counter ++ vengono aggiunte ad alcuni moduli e non ad altri moduli. Una soluzione rapida e sporca è aggiungerli dove mancano. La lunga soluzione è quella di renderlo un aspetto per i moduli che ne hanno bisogno, rendendo impossibile dimenticarlo in seguito. Non ho problemi a risolvere cose del genere, ma se dovessi apportare questa modifica, romperei altri 10 moduli.

Aggiornamento:

Ho accettato la risposta di Greg D. Anche se mi piace di più Adam Bellaire, non mi aiuterebbe a sapere quale sarebbe l'ideale da sapere. Grazie a tutti per le risposte.

Answer 1

1. Spegni gli incendi . Se ci sono problemi di priorità critica, qualunque essi siano, devi prima affrontarli. Hack in se è necessario, con una base di codice puzzolente va bene. Sai che lo migliorerai in futuro. Questa è la tua tecnica di vendita indirizzata a chiunque stai segnalando.
2. Scegli un po 'di frutta bassa. Presumo che tu sia relativamente nuovo a questo particolare software e che ti sia stato nuovamente assegnato il compito di affrontarlo. Trova alcuni problemi apparentemente facili in un sottosistema correlato del codice che non dovrebbe richiedere più di un giorno o due per risolverli e risolverli. Ciò può comportare il refactoring, oppure no. L'obiettivo è familiarizzare con il sistema e con lo stile dell'autore originale. Potresti non essere davvero fortunato (Uno dei due incompetenti che ha lavorato sul mio sistema prima di me ha sempre post-riparato i suoi commenti con quattro segni di punteggiatura invece di uno, il che ha reso molto facile distinguere chi ha scritto il particolare segmento di codice.), ma svilupperai una comprensione delle debolezze dell'autore in modo da sapere cosa cercare. Ad esempio, un ampio e stretto accoppiamento con lo stato globale e una scarsa comprensione degli strumenti linguistici.
3. Stabilisci un grande obiettivo. Se la tua esperienza è parallela alla mia, ti troverai sempre più spesso in un particolare codice di spaghetti mentre esegui il passaggio precedente. Questo è il primo nodo che devi districare. Con l'esperienza che hai acquisito comprendendo il componente e la conoscenza di ciò che probabilmente l'autore originale ha fatto di sbagliato (e quindi, a cosa devi stare attento), puoi iniziare a immaginare un modello migliore per questo sottoinsieme del sistema. Non preoccuparti se devi ancora mantenere alcune interfacce disordinate per mantenere la funzionalità, fai un passo alla volta.

Metti, sciacqua, ripeti! :)

Dato il tempo, considera l'aggiunta di unit test per il tuo nuovo modello a un livello sotto le tue interfacce con il resto del sistema. Non incidere le cattive interfacce nel codice tramite test che le usano, le modificherai in una iterazione futura.

Affrontare i problemi particolari che menzioni:

Quando ti imbatti in una situazione in cui gli utenti stanno risolvendo manualmente, parla con gli utenti della loro modifica. Verifica che accetteranno la modifica se la fornisci prima di sprecare il tempo. Se non vogliono il cambiamento, il tuo compito è mantenere il comportamento non funzionante.

Quando ti imbatti in un componente difettoso su cui hanno lavorato diversi altri componenti, sposa una tecnica a componenti paralleli. Crea un contatore che funzioni come dovrebbe funzionare quello esistente . Fornire un'interfaccia simile (o, se pratico, identica) e far scorrere il nuovo componente nella base di codice. Quando tocchi i componenti esterni che si aggirano attorno a quello rotto, prova a sostituire il vecchio componente con quello nuovo. Interfacce simili facilitano il porting del codice e il vecchio componente è ancora in giro se il nuovo fallisce. Non rimuovere il vecchio componente finché non puoi.

Answer 2

Cosa ti viene chiesto in questo momento? Ti viene chiesto di implementare funzionalità o correggere bug? Sanno perfino cosa vogliono che tu faccia?

Se non hai la forza lavoro, il tempo o le risorse per "riparare" il sistema nel suo insieme, quindi tutto ciò che puoi fare è l'acqua della cauzione. Stai dicendo che dovresti essere in grado di fare alcuni "progressi visibili" tra qualche mese. Bene, con il sistema che è male come hai descritto, potresti effettivamente peggiorare il sistema. Sotto la pressione di fare qualcosa di evidente, aggiungerai semplicemente codice e renderai il sistema ancora più contorto.

Alla fine devi rifattorizzare. Non c'è modo di aggirarlo. Se riesci a trovare un modo per fare il refactoring visibile ai tuoi utenti finali, sarebbe l'ideale , anche se occorrono 6-9 mesi o un anno invece di " alcuni mesi. & Quot; Ma se non puoi, puoi scegliere:

• Rifattore e rischio di essere visto come "non realizzare nulla" nonostante i tuoi sforzi
• Non effettuare il refactoring, realizzare "visibile" obiettivi e rendere il sistema più complicato e più difficile da refacturing un giorno. (Forse dopo aver trovato un lavoro migliore e spero che il prossimo sviluppatore che arriva, non possa mai scoprire dove vivi.)

Qual è il più utile per te personalmente dipende dalla cultura della tua azienda. Decideranno un giorno di assumere più sviluppatori o di sostituire completamente questo sistema con qualche altro prodotto?

Al contrario, se i tuoi sforzi per " aggiustare le cose " romperanno altre cose, capiranno la mostruosità che ti viene chiesto di affrontare da solo?

Nessuna risposta facile qui, scusa. Devi valutare in base alla tua unica situazione individuale.

Answer 3

Questo è un libro intero che dirà fondamentalmente unit test e refactor, ma con consigli più pratici su come farlo

http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL500_AA240_.jpg

http://www.amazon.com/Working-Effectively-Legacy-Robert -Martin / dp / 0131177052

Answer 4

Si apre la directory che contiene questo sistema con Esplora risorse. Quindi, premi Ctrl-A, quindi Maiusc-Canc. Sembra un miglioramento nel tuo caso.

Scherzi a parte: quel contatore suona come se avesse problemi di sicurezza del thread. Metterei un blocco attorno alle funzioni crescenti.

E per quanto riguarda il resto del sistema, non puoi fare l'impossibile, quindi prova a fare il possibile. Devi attaccare il tuo sistema da due fronti. Prenditi cura prima dei problemi più visibilmente problematici, in modo da poter mostrare i progressi. Allo stesso tempo, dovresti affrontare i problemi più infrastrutturali, in modo da avere la possibilità di risolvere il problema un giorno.

Buona fortuna e che la fonte sia con te.

Answer 5

Scegli un'area che sarebbe di media difficoltà per il refactoring. Crea uno scheletro del codice originale con solo le firme del metodo di quelle esistenti; magari usare un'interfaccia anche. Quindi inizia a hackerare. Puoi anche puntare il " nuovo " metodi per i vecchi fino a quando non li raggiungi.

Quindi, test, test, test. Dal momento che non ci sono test unitari, potresti semplicemente usare dei buoni test vocali (persone) vecchio stile? Oppure scrivi i tuoi test mentre vai.

Documenta i tuoi progressi mentre vai in una specie di archivio, tra cui frustrazioni e domande, in modo che quando il prossimo povero schmuck che otterrà questo progetto non sarà dove sei :).

Una volta terminata la prima parte, passa alla successiva. La chiave è costruire sulla base di progressi incrementali, ecco perché non dovresti iniziare prima con la parte più difficile; sarà troppo facile essere demoralizzati.

Joel ha un paio di articoli su riscrittura / refactoring:

http://www.joelonsoftware.com/articles/fog0000000069.html

http://www.joelonsoftware.com/articles/fog0000000348.html

Answer 6

Ho lavorato con un sistema legacy con le stesse caratteristiche per quasi tre anni e non ci sono scorciatoie di cui sono a conoscenza.

Ciò che mi preoccupa di più con il nostro sistema legacy è che non mi è permesso correggere alcuni bug, dal momento che molte altre funzioni potrebbero non funzionare se le riparassi. Ciò richiede brutte soluzioni o la creazione di nuove versioni di vecchie funzioni. Le chiamate alle vecchie funzioni possono quindi essere sostituite con una nuova alla volta (durante il test).

Non sono sicuro dell'obiettivo del tuo compito, ma ti consiglio vivamente di toccare il meno possibile il codice. Fai solo quello che devi fare.

Potresti voler documentare il più possibile intervistando le persone. Questo è un compito enorme, dal momento che non sai quali domande porre e le persone avranno dimenticato molti dettagli.

A parte questo: assicurati di essere pagato e abbastanza supporto morale. Ci saranno pianti e digrignando i denti ...

Answer 7

Beh, devi iniziare da qualche parte, e sembra che ci siano dei bug che devono essere corretti. Lavorerei su quei bug, facendo rapidi refactoring e scrivendo ogni possibile test unitario lungo la strada. Vorrei anche utilizzare uno strumento come SourceMonitor per identificare alcune delle parti più "complesse" del codice nel sistema e vedere se potrei semplificare il loro design in alcun modo. Alla fine, devi solo accettare che sarà un processo lento e fare piccoli passi verso un sistema migliore.

Answer 8

Vorrei provare a scegliere una parte del sistema che potrebbe essere estratta e riscritta isolatamente abbastanza rapidamente. Anche se non fa molto, potresti mostrare progressi abbastanza rapidamente e non hai il problema di interfacciarsi direttamente con il codice legacy.

Eventualmente, se potessi scegliere alcuni di questi compiti, ti vedranno fare progressi visibili e potresti presentare un argomento per assumere più persone per riscrivere i moduli più grandi. Quando parti del sistema si basano su comportamenti non funzionanti, non hai molta scelta se non quella di separarti prima di correggere qualcosa.

Speriamo che tu possa gradualmente costruire una squadra in grado di riscrivere l'intero lotto.

Tutto ciò dovrebbe andare di pari passo con una buona formazione, altrimenti le vecchie abitudini della gente resteranno attaccate e il tuo lavoro avrà la colpa quando le cose non funzioneranno come previsto.

Buona fortuna!

Answer 9

Elimina tutto ciò che esiste attualmente che ha problemi e scrivine di nuovi che funzionino correttamente. Documenta il più possibile ciò che cambierà e metti grandi segni rossi lampeggianti in tutto il luogo che punta a questa documentazione.

In questo modo, puoi mantenere i tuoi bug esistenti (quelli che vengono compensati da qualche altra parte) senza rallentare i tuoi progressi verso l'ottenimento di un vero sistema funzionante.