Quando una squadra dovrebbe preferire introdurre una modifica in modo incrementale invece di un refactoring completo del codice?

Question

Quando una squadra dovrebbe preferire introdurre una modifica in modo incrementale invece di un refactoring completo del codice?

#1 da (3 voti)

-1

Mi piace provare cose nei progetti in cui mi trovo.

Quando qualcosa non mi sembra giusto, mi piace implementare una nuova cosa, vedere se si adatta o meno per un po 'e poi, lentamente, implementarla nel resto dei casi.

Ad esempio - Diciamo che nell'interfaccia utente, voglio provare un flusso unidirezionale. Quindi prendo una pagina e la renderò unidirezionale.

Una volta che vedo che funziona bene, applico a un'altra pagina, e un'altra, finché non è in tutte le pagine.

Tuttavia, un sacco di volte mi imbatto in squadre che hanno una mentalità di "tutto o niente". Significato: se vuoi un flusso unidirezionale, applicalo a tutte le pagine. A volte ciò richiede un dibattito per convincere che il cambiamento è necessario in primo luogo perché è un grande sforzo.

Questa mentalità mi sembra di creare un ambiente in cui introdurre un cambiamento è impossibile. Le implicazioni oltre il progetto potrebbero anche avere un effetto motivazionale sulla squadra stessa.

Quando una squadra dovrebbe preferire innegabilmente introdurre un cambiamento in maniera crescente invece che un refactoring completo del codice? O è sempre discutibile?

refactoring changes

posta guy mograbi 27.09.2017 - 20:14

fonte

1 risposta

Leggi altre domande sui tag refactoring changes

Autenticazione utente nell'app Come proteggere la comunicazione server-server tra due endpoint?

score 3 · Answer 1

L'interfaccia utente coerente è molto importante. Ecco perché molti, se non tutti, i negozi hanno un modo "standard" di fare le cose dell'interfaccia, anche se quello standard è di fatto. Spesso, questo standard deriva da convenzioni che gli utenti già comprendono perché sono ampiamente utilizzati.

L'introduzione di nuove innovazioni dell'interfaccia utente in un'applicazione in cui non esistevano prima può confondere, sia per l'utente che deve capire come funziona il nuovo gadget, sia per gli sviluppatori che si chiedono perché non si conformano alla gestalt dell'applicazione e chi ora deve mantenere due diversi modi di fare le cose.

Di conseguenza, qualsiasi modifica dell'interfaccia utente che si discosta sostanzialmente dallo standard dovrebbe passare attraverso diverse fasi per determinarne l'efficacia:

Una fase sperimentale, in cui vengono esplorate le nuove innovazioni dell'interfaccia utente,
Una fase dogfooding, in cui le nuove innovazioni dell'interfaccia utente vengono testate internamente, per vedere se reggono,
Una fase di verifica, in cui le innovazioni vengono inviate alla comunità degli utenti su base beta e viene raccolto un feedback,
Una fase di integrazione, in cui l'innovazione viene applicata a tutte le aree dell'applicazione dove è applicabile, utile e promuove l'uniformità,
Una fase di implementazione, in cui la nuova innovazione viene trasferita alla comunità degli utenti in una nuova versione del software.

Operare in questo modo richiede molto lavoro e arriva con un certo grado di inerzia. Dovrebbe. Le modifiche all'interfaccia utente sono diverse dalle modifiche alle funzionalità del programma. Facebook ottiene un po 'di attenzione dalla sua comunità di utenti per ogni modifica apportata alla sua interfaccia utente, indipendentemente dalla sua importanza. Nessuno si lamenta di un cambiamento che non possono vedere.

Se si violano le prime direttive del negozio in relazione all'architettura interna, si influenzano solo gli altri sviluppatori. Ma l'interfaccia utente, in un senso molto reale, è il "volto" della tua azienda. Cambiare quella faccia richiede più di una decisione arbitraria di una sola persona.