Termine per le modifiche che non includono le modifiche alla funzionalità del prodotto

Question

Termine per le modifiche che non includono le modifiche alla funzionalità del prodotto

#1 da (3 voti)
#2 da (2 voti)
#3 da (0 voti)

4

Che cosa è un buon termine da usare per quando voglio descrivere le modifiche alla base di codice che non comportano la modifica o l'aggiunta di funzionalità. Ciò include correzioni di bug, patch di sicurezza - inclusi aggiornamenti di libreria e forse anche refactoring.

Il termine sostituisce il suono non corretto "modifiche non funzionali" nella frase seguente:

"Gli sviluppatori dovrebbero testare le regressioni quando si eseguono modifiche non funzionali al code-base"

Qual è il modo migliore per esprimere la frase precedente, ignorando per un istante il significato dell'affermazione stessa e tutte le cose che non lo sono.

Il termine si applicherebbe anche quando si discute di storie che non forniscono un valore commerciale diretto e quindi sono una "vendita" più dura durante la pianificazione dello sprint. Cioè non possono essere incorniciati con il modello della trama "Come utente, vorrei fare X."

Quindi il termine è un termine secchio per il lavoro pianificato che non è legato direttamente o anche indirettamente a nuove funzionalità o miglioramenti. Stavo pensando di usare qualcosa come "extra-funzionale" o qualcosa di simile per evitare le "modifiche alla base del codice che non sono direttamente testabili a parte i test di regressione completi."

terminology

posta user1527469 16.11.2017 - 18:30

fonte

3 risposte

Leggi altre domande sui tag terminology

UML open diamond help Assegnazione del copyright su progetti open source

score 3 · Answer 1

Sembra che tu stia cercando di vendere alla gestione, i concetti di manutenzione e debito tecnico. Sono rimasto sorpreso che la parola "manutenzione" non sia arrivata una volta nella tua domanda. Ed è per questo che penso sia la risposta!

Dalla stessa definizione di manutenzione da Wikipedia ...

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.

Come termine nella tua frase di esempio, penso che questi due sarebbero adatti:

Miglioramenti tecnici / funzionali Direi di non chiamarlo solo "Debito tecnico" in quanto è debito + refactoring + sicurezza + performance. I miglioramenti non significano aggiungere necessariamente qualcosa di nuovo, piuttosto "migliorare" il prodotto esistente.

Patch di manutenzione

Ho sentito parlare molto degli annunci di aggiornamento di grandi prodotti. Non portano mai nuove funzionalità e non c'è quasi nessuna modifica evidente per gli utenti.

score 2 · Answer 2

Potrei essere tentato di chiamare queste cose "manutenzione regolare / preventiva". Ho già spiegato qualcosa di simile ai miei manager e l'ho riferito alla manutenzione dell'auto.

Questo aggiornamento per la sicurezza? È come cambiare l'olio nella tua auto, costa un po 'ora, piuttosto che una quantità enorme in futuro, altrimenti dovresti pagare per un nuovo motore che viene sequestrato o tutti i dati dei tuoi clienti vengono rubati perché non puoi essere disturbato per aggiornare una vulnerabilità nota.

Quel aggiornamento della libreria? È come ricevere nuove gomme. Proprio come la tecnologia degli pneumatici è migliorata nel corso degli anni e non avresti scelto di guidare con le gomme del 1973, quella libreria di 2 anni fa potrebbe non essere più il migliore.

refactoring? È come pulire il tuo baule. Sai che un giorno il tuo cliente ti chiederà una nuova funzionalità e penserai che sarebbe stato molto più semplice da implementare 6 mesi fa se avessi appena buttato via le vecchie borse Cheetos nella parte posteriore piuttosto che accumulare un sacco di sacchetti di lettiere per gatti sopra di loro.

(Ok, penso che avrei potuto prendere quell'ultima troppo là fuori)

Nessuna di queste cose trasforma la tua auto in una nuova Ferrari, ma impedisce che si trasformi in un Form Pinto arrugginito.

score 0 · Answer 3

Chiamerei queste modifiche "pagamenti tecnici del debito". Questo dà loro la gravità che meritano. Sono cambiamenti che devi apportare ora per evitare problemi ancora peggiori in futuro. No, non ti danno niente di nuovo o lucido. Hai già ottenuto la cosa nuova e brillante, e nel corso del processo hai subito un debito tecnico.

Ciò incoraggerà anche i manager a pensare a come evitare di incorrere nel debito tecnico in primo luogo. Adottare pratiche che riducono il numero di bug (un sottoinsieme importante dei quali sono problemi di sicurezza) che lo rendono in produzione sembrerà quindi un'idea molto migliore.

Suppongo quindi che la frase che pronuncerai sarebbe "Quando si effettuano cambiamenti che sono pagamenti di debiti tecnici, gli sviluppatori dovrebbero eseguire test di regressione per evitare di incorrere in ulteriori debiti tecnici nel processo."