È tipico per le aziende di software di grandi dimensioni non documentare o codice Refactor? [chiuso]

Ci sono una serie di motivi per cui le aziende non riescono a investire nel rendere i loro programmi "migliori", dal punto di vista del debito tecnico:

1. La riduzione del debito tecnico non aggiunge nuove funzionalità al software. Viene quindi percepito dalla direzione come privo di valore monetario (in una certa misura giustificabile)

2. La natura del business del software premia la prima volta sul mercato, non la migliore.

Potrei andare avanti, ma tutti gli altri motivi sono solo varianti di questi due. Fondamentalmente, tutti si aggiungono al pensiero a breve termine, concentrandosi sui profitti immediati anziché sulla redditività a lungo termine.

Tutte le aziende con progetti software non banali e attivi hanno un certo grado di debito tecnico. Nessuna azienda è completamente esente da debiti.

Every software project I've ever worked on has accrued Technical Debt over time -- Jeff Atwood.

Riguardo alla documentazione specifica, meno c'è, meglio è. Dollaro in dollari, si ottiene un rendimento maggiore rendendo il software più semplice da utilizzare e più facile da gestire rispetto a quanto si scrive più documentazione per questo.

Ci sono alcune indagini informali sul debito tecnico e su come le aziende lo gestiscono; tutto ciò che devi fare è cercarli Ecco uno :

Oppure questo uno :

Sembraabbastanzaevidentechelatuaaziendanonsial'unicaadaverequestoproblema.Potrebbenonesserenemmenoinminoranza.

Ulterioriletture
Terzo workshop internazionale sulla gestione del debito tecnico - Panoramica
Gestione del debito tecnico nei sistemi compatibili con il software

Una prospettiva che non credo sia stata trattata in altre risposte (ancora) è il costo del cambiamento in tre aree:

1. test
2. rifamiliarizzazione
3. costo opportunità

Un'azienda con un prodotto di grandi dimensioni dovrà testare tutte le modifiche. Queste procedure di test devono essere monitorate su più assi: piattaforme diverse, carichi di lavoro diversi, prospettive diverse (prestazioni, funzionalità, usabilità, retrocompatibilità).

Le persone che lavorano nelle aree del codice che stai cambiando dovranno anche familiarizzarsi con il codice, e diventa particolarmente ingombrante con più versioni supportate ("mi dispiace, che versione è quella? Ahh, questo è il nuovo codice ed è necessario parlare con Bob per questo "). Analogamente, la modifica del codice solo per renderla carina tende a rendere molto complicati da leggere cose come registri delle modifiche (diff, patch, ecc.) E problemi di tracciamento in un momento particolare in cui è stato introdotto il bug può essere molto impegnativo se c'è qualcosa nella cronologia del codice che cambia tutto . Inoltre, se un bug è di vecchia data (queste cose accadono) potrebbe essere in più versioni supportate del tuo codice, e ora devi correggere il vecchio e il nuovo codice in modi potenzialmente molto diversi.

Infine, spesso è necessario prendere una decisione dove spendere tempo e denaro. Questo è più che il tuo tempo, ma piuttosto cosa dovresti fare con il tuo tempo (e l'impatto che ha sulle risorse a valle). Sarebbe preferibile passare il tempo del tuo team di sviluppo su funzioni che possono produrre più vendite, conquistare nuove quote di mercato e generare profitti, o se il tempo / denaro da spendere per cose che gli utenti finali non noteranno, non può essere messo su materiale di marketing ("hey, il nostro codice esistente fa schifo, ma lo abbiamo reso migliore") ed è puro costo (nessun profitto).

In conclusione, denaro . Sempre (beh, quasi sempre).

Sì. Basato sulle circa 50 società che ho incontrato personalmente, come dipendente o consulente, e le circa 200 aziende che conosco tramite i colleghi.

Il tipo di prodotto (1,5 milioni di righe) che descrivi ha impiegato anni per essere realizzato e molti degli sviluppatori originali sono passati (o diventano manager).

Il senior management e i principali clienti continuanti desiderano solo piccoli cambiamenti incrementali: vogliono stabilità. Ciò che noi tecnici pensano siano miglioramenti sono nei loro occhi rischi. Anche se siamo in grado di mostrare che la nuova versione si comporta ancora come la vecchia, essi vedono un rischio perché il vecchio sistema ha esattamente la caratteristica che descrivi: non è documentato. Per loro, potrebbe esserci un comportamento non documentato su cui i clienti fanno affidamento.

Dal loro punto di vista: non è rotto, quindi non aggiustarlo. Stai anche vedendo che c'è una cultura aziendale in tal senso. Le persone che resistono ai tuoi "miglioramenti" probabilmente hanno fatto lo stesso come te quando hanno iniziato.

Non aspettarti di "vincere". Questa è una questione culturale e non può essere modificata se non per il cambiamento a livello di CEO.