Sto notando una strana mentalità, quando si tratta del codice di refactoring, e non sono troppo sicuro di come lo sto percependo.
Panoramica del progetto corrente:
Un'applicazione Web utilizzata come estensione di un'applicazione Web di terze parti esistente. L'applicazione di terze parti mantiene gli orari tra clienti e fornitori. L'estensione consente di modificare giorni / orari che il cliente richiede di riprogrammare, modificare l'attuale serie di programmi in caso di emergenza, modificare un fornitore se non possono più essere contrattati e creare i file di fatturazione appropriati. Per quanto riguarda lo sviluppo, il team è impostato per seguire la maggior parte delle idee di Scrum.
Il sistema è stato costruito in base a numerosi criteri una tantum, principalmente a causa del fatto che i clienti del progetto non hanno pienamente compreso i loro processi interni (a causa di allenamenti interni / fatturati). Abbiamo visto molte aree, dove ci sono controlli basati sul contenere alcune stringhe hard-coded.
Questo ci porta al problema. C'è un controllo per un fornitore specifico (possiamo chiamarlo SomeVendor), e il controllo è impostato per se il nome ne contiene Alcuni. Successivamente, quando guadagniamo e perdiamo fornitori, un altro fornitore viene aggiunto come SomeOtherVendor. Il problema con questo è ovviamente il controllo basato sul contenere alcuni. SomeVendor è un caso specifico che deve essere controllato e sono altri fornitori che devono essere controllati in modo simile e filiali nel proprio insieme di funzionalità. Nel trovare questi controlli, vediamo che è stato sviluppato rispetto a un programma può essere correlato a un fornitore, ma non è sempre assegnato a loro. Gli utenti dovrebbero associarlo durante l'esecuzione.
Il cliente si rende conto che c'è un problema con SomeVendor e ha chiesto che un difetto sia inserito nel backlog e lo abbia assegnato la priorità al proprietario del prodotto. Ho rilevato il difetto e sviluppato una tabella di ricerca per i venditori di SomeVendor validi (nel caso in cui più di uno fosse mai valido in base all'Id).
È in arrivo una distribuzione mid-sprint, quindi sono andato a discutere se sarebbe stato necessario aggiungerlo alla distribuzione con il mio esempio. Ha espresso che gli è piaciuta la soluzione, ma ha chiesto se potevo farlo in un modo che includesse la mappatura di tutti i fornitori che devono essere controllati. Ha anche dichiarato di farlo esclusivamente per il problema attuale.
Il giorno seguente lo sviluppatore senior chiede di collaborare con me alla progettazione e procede discutendo la configurazione di tutti i fornitori e incorporandolo nella base di codici. Come detto sopra, il sistema rappresenta alcuni fornitori come "possono essere" di alcuni tipi, ma non è sempre il caso.
Abbiamo discusso sul punto che il sistema può considerarlo solo come possibile, ma non è determinato fino a quando non risparmiano in fase di esecuzione. Il suggerimento è di portare questo al proprietario del prodotto e ottenere i criteri dai clienti del progetto.
Vedo il punto nel refactoring in un punto in cui il codebase lo userebbe correttamente, ma a questo punto mi sembra che stia entrando nel regno dell'ingegneria. Quel sentimento è dovuto principalmente a una storia / difetto già determinato e priorizzato con il cliente, e abbiamo dato quello che abbiamo detto che avremmo fatto dalla pianificazione Sprint. Questo sembra che ci stiamo intrufolando in un deliverable che non sanno di aver bisogno (che è stato discusso di recente tra noi e il cliente).
Questo tipo di refactoring è qualcosa che dovrebbe accadere, o è un segnale di cattiva spinta tecnica? In realtà, non mi importa se la risposta riguarda specificamente l'agile. Mi sembra strano, nel senso che la squadra abbia qualche lavoro richiesto, quindi consegna qualcosa che non è stato concordato.