Suggerimenti per lavorare con software mal progettato [chiuso]

Innanzitutto, non nuocere.

Sei di fronte a un sistema che funziona, almeno in una certa misura. Potrebbe avere grossi problemi, potrebbe essere non gestibile, ma funziona e mantiene il business in esecuzione. Senza un'attività in corso, il codice non ha alcun significato, quindi non uccidere il business.

Diverse pratiche possono uccidere il business:

• Una grande riscrittura può richiedere così tanto tempo che l'azienda non può adattarsi alle mutevoli condizioni nel mezzo, e l'azienda può piegarsi prima che la riscrittura venga pubblicata. Chiedi a Joel come si può ottenere
• Un'implementazione del big-bang ha enormi rischi in una sola grande implementazione. Se hai sbagliato qualcosa, potrebbe essere difficile o impossibile da recuperare. Come sarà la tua attività commerciale se non puoi evadere alcun ordine durante il periodo dell'anno più trafficato ?
• C'è una logica aziendale nel vecchio codice che esiste per un motivo, anche se nessuno delle persone che capiscono perché è lì sono ancora in compagnia. Una riscrittura potrebbe non notare i pezzi che devono essere mantenuti.

Sii chirurgico e incrementale

La cosa migliore da fare in questo caso è lavorare in pezzi molto piccoli. Quando ti viene chiesto di aggiungere qualcosa al sistema esistente, cerca di trovare il cambiamento più piccolo possibile che svolgerà il lavoro riducendo al minimo l'impatto su altre parti del codice. Utilizza queste attività per apprendere il sistema e capire quali parti del sistema sono soggette a frequenti cambiamenti e che sono abbastanza statiche.

Lascia dormire i cani che dormono. Alcune parti del sistema sono brutte, ma dal momento che funzionano e non vengono mai modificate, dovrebbero essere in fondo alla lista per il miglioramento. Cambiare questi pezzi significa aumentare il rischio per l'azienda, ma nessun vantaggio reale.

Pianifica l'elaborazione parallela o il backout rapido. Quando trovi un'area che cambia frequentemente, è importante per il business e deve essere migliorata, come si fa? Con molta attenzione. Come minimo, dovresti semplificare la rimozione della riscrittura dall'elaborazione principale in caso di problemi. È molto più sicuro per l'azienda apportare grandi cambiamenti se riesci a tornare al codice legacy testato nel tempo in pochi minuti rispetto a quando rischi di rimanere bloccato per ore o giorni. È ancora meglio se puoi eseguire entrambi i percorsi contemporaneamente e provare che il nuovo codice produce gli stessi (o migliori) risultati del codice esistente.

Guardando tutti questi suggerimenti, più si può rompere il sistema in bit discreti, più si avrà successo nel migliorare il sistema.

Nella mia esperienza, tutto ciò che puoi fare è informare il tuo cliente sullo stato dei loro siti ed essere pronto ad aiutare se lo chiedono. Possono dare un giudizio di valore.

Se vuoi davvero aiutare, offri di documentare la struttura del progetto / sito che ha bisogno di più lavoro con una raccomandazione. Forse se vedono l'ambito specifico della situazione, o si impegneranno in un progetto più ampio, o almeno saranno a conoscenza dell'ambito.

Inoltre, non abbellire mai o sovrastimare la tua posizione solo per fare un punto. Se il lavoro precedente fa veramente schifo, parlerà da solo. Considera che a un certo punto anche tu probabilmente hai prodotto qualcosa di discutibile longevità di cui ora qualcuno si lamenta. Chissà, forse i framework e le lingue che consiglieresti oggi risulteranno essere un PITA costoso per qualcun altro.