Entrando in una nuova architettura durante la manutenzione su sistemi legacy

Sono stato in una situazione simile, ed è una decisione difficile. Come hai sottolineato, sarebbe bello iniziare a ripulire il codice e (idealmente) essere in grado di ripulirlo tutto nel tempo. D'altra parte, sarebbe piuttosto fastidioso per i futuri sviluppatori vedere questi pollici penetranti nel codice, indipendentemente da quanto sia buono il codice scritto.

Nella situazione in cui mi trovavo, ho provato molte cose diverse. Il codice era, e ancora lis, orribile . Alcuni dei cambiamenti che ho provato erano drastici, altri meno. Ma ogni volta che ho provato a rifattorizzare il codice, ho scoperto che farlo avrebbe solo reso il codice più complicato e più difficile da capire.

In definitiva ho cercato di trovare modelli che esistevano negli spaghetti. Una volta identificati alcuni, ho iniziato semplicemente a formalizzarlo. Ciò richiedeva pochissime modifiche, perché principalmente aggiungevo interfacce e identificando le aree del codice base che potevano essere rese un po 'più generiche senza cambiamenti drastici. Questo si è rivelato funzionare molto bene. Ora il pasticcio sembrava come se avesse una struttura, e questo da solo ha reso più facile ragionare.

Se puoi farlo in un'area chiave (probabilmente correlata alle richieste di funzionalità) e dirigerli verso aree simili della base di codice, lascerai il codice solo un po 'meglio di come l'hai trovato, ma senza trasformando la foresta in un centro commerciale.

Inoltre, controlla il codice puzza! Che cosa faccio? sul blog della community dei programmatori .

Penso che sia meglio che almeno una parte del sistema sia scritta "correttamente", piuttosto che l'intero sistema sia coerente, ma difficile da usare.

Vorrei prendere nota che il codice invariato dovrebbe essere cambiato ad un certo punto (si spera presto), e procedere al refactoring mentre procedete.

È piuttosto improbabile che tu rifattori l'intero sistema in un colpo solo, quindi va bene se ci sono momenti temporanei di incoerenza, purché tu stia andando verso una base di codice più pulita.

Consiglio di non lasciare che lo status quo dettare il futuro, in generale. Mentre c'è qualcosa da dire per la continuità, c'è davvero molto poco da dire per continuare a succhiare (scusate l'espressione). Qualsiasi piccolo vantaggio in termini di leggibilità / comprensibilità non introducendo nuovi modelli di sviluppo è probabilmente compensato dalla natura del pasticcio stesso.

Se ci sono molte altre persone che lavorano al progetto, e hanno lavorato e contribuito al caos, allora penso che abbiano bisogno di vedere come appare "non-mess". Se non si introduce mai "non-disordine", nessuno avrà un esempio da seguire se non un pasticcio. Un buon design deve iniziare da qualche parte, e se sei chiaro nello scopo e buono nello spiegare la filosofia, altre parti del codice inizieranno ad allinearti con il tuo sforzo.