Come spiegare al tuo capo non programmatore che hai bisogno di rifattorizzare un intero sito? [duplicare]

La quantità di modifiche che un effetto dovrebbe è controverso. Cosa succede se si decide un approccio 'big bang', si stima che dovrebbero essere necessari due mesi per il refactator e finire per prendere sei? Non sto mettendo in discussione le tue competenze: è solo che progetti come questi possono facilmente sfuggire a un controllo incontrollabile.

Potresti creare un caso per un refactoring delicato e iterativo. Quindi forse prendi un giorno per centralizzare i file di configurazione e poi spostati su altri progetti. Quindi, due settimane dopo, aggiungi l'autoloading. Ottieni piccole modifiche dal vivo ogni volta, quindi attendi un po 'di tempo per farle entrare. In questo modo, rimani produttivo su nuovi progetti, migliorando lentamente la base di codice.

Dovresti fare queste cose su una branca separata, e se ci sono altre persone tecnologiche che le tue modifiche toccheranno (programmatori, dbas, ecc.), farle acquistare nelle tue modifiche prima di eseguirle.

Spiega il vantaggio in termini di costi: ogni volta che vogliono apportare una modifica, trascorri 3 ore a capire il codice e solo allora sarai in grado di apportare la modifica, che richiederà probabilmente meno di 3 ore. In un sito pulito e ben strutturato con una buona documentazione, la maggior parte delle modifiche e delle aggiunte può iniziare immediatamente senza ritardi. Nel tuo caso hai una sessione di preparazione di 3 ore prima che tutto possa accadere (in base a ciò che hai descritto)

Inoltre, prova a trovare un'analogia del mondo reale che il tuo capo possa capire. Spiega come lavorare su codice non documentato è come cercare di trovare qualcosa in una credenza piena di barattoli non di vetro che non hanno etichette.

Generalmente una revisione completa di un sito non è mai (finanziariamente) praticabile. Ho quasi sempre dovuto scendere a compromessi per apportare modifiche a soluzioni inadeguate man mano che si toccava il codice base per evitare di perdere troppo tempo di produttività per il ri-factoring. La pulizia del codice non è quasi mai consentita da un punto di vista dei costi, generalmente si verifica come un effetto collaterale passivo del contatto con qualcos'altro che deve essere migliorato.

Aiuterà il tuo caso quando mostrerai una sorta di percorso di transizione. Evoluzione non rivoluzione.

In questo modo la decisione diventa meno rischiosa.