Complessità punto di non ritorno. Come lo chiami?

13

Come sviluppatore di software, uno dei miei compiti principali è tenere sotto controllo la complessità.

Tuttavia, in alcuni progetti, c'è un momento in cui il livello di complessità cresce così in alto da raggiungere una sorta di punto di "non ritorno". Passato questo momento, non puoi mai riportare il progetto a un livello accettabile di complessità in meno tempo di quanto dovresti riscrivere da zero.

Questo particolare momento ha un nome nel dialetto dei programmatori (qualcosa di simile alla legge di Godwin per i troll)?

--modificare--

Scusa se non sono chiaro. Non credo che questo "momento" abbia un nome ufficiale o sia una metrica seria. Stavo pensando a qualcosa nello spirito del "picco di Ballmer" in xkcd .

terminology

— Thibault J
fonte

1

Vedo una controversia nella tua definizione del punto in questione: ... in meno tempo che avresti bisogno di riscrivere tutto da zero , il che implica che coloro che stanno per riscrivere il progetto sono abbastanza buoni, o almeno migliori di quelli che creato il disordine in primo luogo;)

— mojuba

1

Penso che uno dei motivi per cui non esiste un nome concordato sia che dipende da chi sta guardando il codice. Ciò che appare irrimediabilmente complesso o irraggiungibile per uno sviluppatore può sembrare abbastanza ragionevole per un altro. Nei casi più gravi, ho appena compilato una DLL con un prefisso "ms" e ho detto che veniva da Microsoft.

— Kevin Hsu,

1

Forse questo farebbe: Technical Debt Event Horizon

— PeterAllenWebb,

20

È più un problema di manutenibilità che di complessità.

Il fenomeno si chiama "debito tecnico" e, una volta raggiunto un livello critico, il progetto sta per fallire.

È quello che volevi dire?

Grazie per la tua risposta Sono a conoscenza del concetto di "ufficio tecnico". Ogni progetto ha una sorta di debito tecnico. Quello che voglio dire è: come si chiama il momento in cui questo debito diventa così alto che preferiresti buttare il progetto nella spazzatura e ricominciare?

— Thibault J

3

Mi piace il tuo termine "fallimento tecnico". Suggerisce che, proprio come in un vero fallimento, devi guardare attentamente quali parti sono recuperabili e quali dovrebbero essere lasciate indietro. E forse un po 'di ristrutturazione del debito è tutto ciò che è veramente necessario :)

— Jaap

2

@Thibault J: Non credo che ci sia un termine specifico per quel momento. Si tratta più di rendersi conto se sei ancora felicemente prima di quel momento o purtroppo passato oltre.

1

@ Developer Art: ... rendersi conto se sei ancora felicemente prima di quel momento o purtroppo passato oltre - penso che questa sia la chiave per dare una buona definizione del punto: un progetto che è andato oltre il punto è quello che nessun ingegnere vorrebbe assumere volontariamente.

— Mojuba,

3

Vado per il termine "fallimento tecnico", mi piace. E userò anche la tua definizione.

— Thibault J

16

Il "punto di eccessiva complessità" è indicato in inglese come:

OH MIO DIO CHE COSA È QUESTO FUGATO.

Il problema è che questo può applicarsi a qualcosa che in realtà è semplice, ma è implementato in un modo così orribile da avere la stessa reazione.

Quindi distinguere qualcosa di molto complesso da qualcosa di molto orribile può essere difficile.

TUTTAVIA: Ciò che tende effettivamente a succedere a tutto il software è un processo un po 'come questo:

Step 1: Avere una buona specifica, fare un bel design, implementare cose carine. Tutti contenti.

Alla fine del passaggio 1: gli sviluppatori si congratulano con se stessi per la meravigliosa eleganza del loro design e se ne vanno felici pensando "Ho un'eredità meravigliosa qui per gli altri per aggiungere cose in futuro, sarà meraviglioso e il mondo sarà un un posto migliore."

Passaggio 2: vengono apportate alcune modifiche, le cose vengono aggiunte, sono incluse nuove funzioni. L'architettura e la struttura del passaggio 1 hanno reso questo processo abbastanza indolore. [Ma oops, il "fattore di trapianto" è appena aumentato un po '.]

Alla fine del passaggio 2: gli sviluppatori si congratulano con se stessi per la meravigliosa eleganza del loro design e se ne vanno felici pensando "Accidenti, sono così intelligente di aver preso tutte quelle indennità nel passaggio 1. Questo è andato così bene. Ho un'eredità meravigliosa qui per gli altri aggiungere cose in futuro, sarà meraviglioso e il mondo sarà un posto migliore ".

Passaggio 3: vengono apportate più modifiche, vengono aggiunte più cose, più nuove funzioni, un sacco di cose vengono cambiate, il feedback degli utenti viene effettivamente ascoltato.

Alla fine del passaggio 3: gli sviluppatori si congratulano con se stessi per la meravigliosa eleganza del loro design e se ne vanno abbastanza felici pensando "Accidenti, questa architettura è abbastanza buona per consentire così tante modifiche di inserirsi facilmente. Ma sono un po 'scontento su X e Y e Z. Ora potrebbero essere ripuliti un po '. Ma !!! Ahhh !!! Sono così intelligente di aver concesso tutte quelle indennità nel passaggio 1. È andato tutto bene. Ho un retaggio meraviglioso qui per altri a cui aggiungere cose in futuro, sarà meraviglioso e il mondo sarà un posto migliore ".

Passaggio 4: proprio come il passaggio 3. Tranne:

Alla fine del passaggio 4: gli sviluppatori pensano: "Questa roba così buona sta diventando brutta da mantenere. Ha davvero bisogno di alcuni cambiamenti seri. Non mi piace molto lavorare su questo. Ha bisogno di refactoring. Mi chiedo quale sia il capo dirò quando gli dirò che ci vorranno 6 settimane e non ci sarà nulla che gli utenti possano vedere alla fine di questo ... ma avrò altri 5 anni di ambito di modifica futuro delizioso facendo questo .... hmmm .. . tempo di andare al pub per un po 'di birra. "

Passaggio 5: è necessario apportare alcune modifiche.

E DURANTE il passaggio 5 gli sviluppatori si dicono l'un l'altro: "Questo codice fa schifo. Chi ha scritto questo? Dovrebbero essere sparati. È orribile. Dobbiamo riscriverlo."

Il passaggio 5 è fatale. È qui che il fattore cruft è diventato così grave che il codice non può avere solo qualche altra modifica, ma deve avere alcune GRANDI modifiche.

Il problema al passaggio 5 è il desiderio di buttarlo via e ricominciare. Il motivo per cui questo è fatale è "The Netscape Factor". Vai su Google. Le aziende muoiono a questo punto, perché ricominciare significa iniziare con circa il 50% di ipotesi invece di fatti, il 150% di entusiasmo invece di conoscenza, il 200% di arroganza invece di umiltà ("Quei ragazzi erano così stolti!"). E introduci un sacco di nuovi bug.

La cosa migliore da fare è refactoring. Cambia un po 'alla volta. Se l'architettura si sta un po 'stancando, correggila. Aggiungi, estendi, migliora. Gradualmente. Ad ogni passo lungo il percorso, prova, testa e prova ancora un po '. Cambiamenti incrementali come questo significano che 10 anni dopo il codice attuale e originale sono come un'ascia da nonno ("aveva 10 nuove teste e 3 nuove maniglie ma è ancora un'ascia da nonno"). In altre parole, non è rimasto molto in comune. Ma sei passato dal vecchio al nuovo gradualmente e con attenzione. Ciò riduce il rischio e, per i clienti, riduce il fattore incazzato.

— quickly_now
fonte

Scommetto che otterrai più voti se accorcia i tuoi passi.

— Codismo,

Devo aggiungere che la maggior parte delle aziende non prevede questo budget, quindi il refactoring è sempre troppo tardi. Gestire la crescente entropia dei sistemi è istituire, che dal primo giorno, viene assegnato un budget (10% -20%) da ogni lavoro per le pulizie. Non è un budget per la correzione di bug. La spesa di bilancio è decisa dall'ingegneria, non dalla direzione, dal marketing o dalle vendite. Viene utilizzato solo per fattorizzare l'entropia creata dallo sviluppo e la spesa si riduce man mano che il prodotto si avvicina alla fine della vita.

— mattnz,

Concordato. La direzione vuole sempre tagliare quel tipo di cose. A volte puoi evitarlo nascondendolo (aggiungi circa il 20% alla stima di sviluppo per fare qualsiasi cosa, e quando è necessario il refactoring - FAI).

— quick_now

1

C'è un punto in cui non puoi davvero refactoring. Se hai diverse applicazioni aziendali diverse che dipendono dalla stessa interfaccia o database scadente, non puoi sistemare molto bene le cose sottostanti senza rompere tutte le altre app che dipendono dalla base scadente. A questo punto sei davvero fregato.

— John Cromartie,

2

Sono d'accordo che il momento è difficile da riconoscere e può essere evitato con processi adeguati. Tuttavia, la domanda era su come chiamarla. Nell'economia reale, esiste il concetto di "rendimenti decrescenti": il punto in cui l'aumento dell'input per una risorsa in un processo diminuisce il profitto complessivo per unità. Ciò vale certamente per la codifica e anche le cose buone come l'astrazione, il riutilizzo ecc. Hanno un tale punto di rendimenti decrescenti. Il termine generale specifico per la programmazione è "ingegneria eccessiva". Per qualcuno che è incline a farlo, mi piace il termine di Joel " astronauta dell'architettura ".

— Kilian Foth
fonte

1

Troppo spesso il buon codice viene scartato sotto la falsa impressione che il nuovo team con nuovi strumenti possa farlo più economico, più veloce con più affidabilità, solo per scoprire che

La complessità sta nei requisiti non documentali
I nuovi strumenti sono più difficili da utilizzare rispetto al sito Web flash promesso
La nuova squadra non è così "accesa" come pensavano

Forse il tempo che hai descritto arriva con alcune basi di codice (lo pensavo). Non ho mai sperimentato personalmente un caso di vecchio codice che causava il malfunzionamento di un progetto o la riscrittura del codice salvando un progetto.

Non includo in questi casi in cui le metriche sono state utilizzate per identificare specifici moduli o progetti problematici, che sono stati quindi abbattuti e sostituiti.

— mattnz
fonte

Bene, ho visto il progetto così fottuto che il loro budget di manutenzione era tre o quattro volte il budget iniziale di sviluppo. Ad ogni modo, il termine che sto cercando non è una cosa "ufficiale" e seria, ma qualcosa di più simile al "picco di Ballmer" in xkcd. Scusa se non sono molto chiaro.

— Thibault J

Ma come è diventato così fottuto? Se è a causa di requisiti complessi, cattiva gestione, oltre ingegneri ottimisti, perché una riscrittura potrebbe risolverlo?

— mattnz,

Perché la squadra che lo riscrive non è la stessa di chi la scrive all'inizio?

— Thibault J,

1

Il vero problema con questo "momento" teorico è che viene riconosciuto solo dopo il fatto. A meno che i tuoi colleghi non siano psicopatici, ogni singolo impegno nella base di codice viene fatto con la convinzione che sia un miglioramento su quella base di codice. Sta solo guardando indietro al disordine che ne consegue che puoi vedere che hai passato quel "momento".

Ma mi piace che potremmo dargli un nome. "Signori", potreste dire, attirando i vostri colleghi sviluppatori attorno a voi, "Abbiamo attraversato l'Ellesponto di Manutenibilità. Mandate un messaggio a vostra moglie e fatele sapere che non la vedrete per un po '."

— Dan Ray
fonte

"ogni singolo commit nel codebase è fatto con la convinzione che sia un miglioramento su quel codebase". Sembra che non abbiamo mai lavorato nelle stesse compagnie :)

— Thibault J

@ThibaultJ - Forse i tuoi colleghi sono stati psicopatici?

— Dan Ray,

@Thibault J: credo che ogni singolo commit sia fatto con la convinzione che sia un miglioramento su quella base di codice. La convinzione a volte è scarsamente studiata e infondata, ovviamente.

— David Thornley,

Nel mio ultimo lavoro, non credo che ci sia alcun impegno di manutenzione che qualcuno abbia mai fatto con la convinzione che si trattasse di un miglioramento della base di codice.

— Bobby Tables,

A volte i requisiti di un progetto possono cambiare sufficientemente per forzare la sostituzione con un nuovo design, ma può essere comunque necessario apportare modifiche alla vecchia versione. Se la maggior parte degli ex utenti della vecchia versione utilizzerà il nuovo sistema e non avrà più bisogno di quello vecchio, potrebbe essere perfettamente ragionevole produrre una versione che soddisfi i requisiti di quei pochi per i quali il nuovo sistema non è adatto, anche se sarebbe rendere il sistema meno utilizzabile per le persone che comunque non ne hanno più bisogno.

— supercat

-1

Non so se c'è un nome, ma se non ce n'è uno, proporrei di chiamarlo "punto di fusione"

— DPD
fonte

O prendere in prestito un altro termine nucleare: massa critica.

— John Cromartie,

-2

Questa non è una domanda molto interessante.

In effetti è banale.

È così banale che abbiamo sviluppato numerosi modi per far fronte.

Metodologie a cascata. Molte persone passano molto tempo a rivedere i requisiti e i documenti di progettazione per essere sicuri che la complessità sia gestita.
Metodologie Agili. Sempre meno persone trascorrono meno tempo a discutere di ciò che è immediatamente applicabile per risolvere il problema di qualcuno e rilasciare software a loro. La complessità è gestita perché tutti sono concentrati sul rilascio di qualcosa.

L'unica volta che qualcuno lotta con la "complessità" è a causa della mancata osservanza della metodologia e della gestione corretta del proprio tempo.

Nessuna supervisione dettagliata in una metodologia a cascata. Non sono obbligati a rivedere i prodotti di lavoro intermedi in base a requisiti, architettura, progettazione di alto livello o revisioni dettagliate del progetto.
Nessuna scadenza per lo sprint o priorità del caso d'uso corretto in una metodologia Agile. Non si concentrano su come rilasciare qualcosa all'utente il più rapidamente possibile.

La complessità dovrebbe essere limitata fissando obiettivi.

Lottare con la complessità significa che gli obiettivi non sono fissati o non vengono ricompensati correttamente.

Non c'è "punto di svolta". Se la gestione della complessità è in qualche modo un problema, qualcosa è già sbagliato dal punto di vista organizzativo.

— S. Lott
fonte

1

Non vedo il punto. È improbabile che un progetto ben gestito raggiunga il punto di non ritorno, ma non tutti i progetti sono ben gestiti. Alcuni progetti mal gestiti avranno comunque successo, mentre gli altri falliranno per vari motivi, a volte colpendo il punto di complessità del non ritorno e talvolta no.

— David Thornley,

@ David Thornley: questo è il mio punto. Il "punto di complessità del non ritorno" non esiste. È semplicemente una cattiva gestione. Non è necessario un nome sofisticato o una regola. La complessità è solo un sintomo di cattiva gestione. Non molto interessante.

— S.Lott

@ S.Lott: penso che esista, anche se non in progetti ben gestiti. Esiste un'orda di progetti gestiti male, e alcuni di loro entreranno nell'orizzonte degli eventi della complessità e altri no. Non penso davvero che sia utile mettere insieme tutta la cattiva gestione.

— David Thornley,

@ David Thornley: penso che sia molto difficile districare la cattiva gestione (che porta a una terrificante complessità) da una cattiva gestione (che porta a lasciare tutti). Non riesco a vedere un modo per dire se un progetto diventerà troppo complesso o solo in ritardo o semplicemente incompetente.

— S.Lott

@ S.Lott: Tuttavia, esiste una distinzione tra un progetto in cui tutti abbandonano o subiscono un grave guasto alla salute e un progetto in cui la complessità diventa eccessiva. Esistono diversi modi per fallire e può essere interessante o addirittura utile classificarli.

— David Thornley,

-2

Esistono metodi per visualizzare e monitorare il rischio di aumentare la complessità per (grandi) progetti e codice. Quando vengono applicati ragionevolmente, si spera che non sia necessario un nuovo nome per il punto di non ritorno. (Esiste un MOOC correlato su openHPI: https://open.hpi.de/courses/softwareanalytics2015/ )

La complessità strutturale è un problema di progettazione generale, non solo per la progettazione di software in grandi team. La visualizzazione è il primo passo nella gestione della complessità strutturale. A tale scopo possono essere utilizzate anche matrici e grafici diretti.

Alcuni metodi per ridurre la complessità strutturale sono http://www.buch.de/shop/home/suche/?fq=3540878890 :

modularizzazione
evitare loop di feedback
triangolazione

Inoltre esiste il concetto di design assiomatico: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Con questo concetto si possono evitare problemi di affidabilità dovuti a complessità non necessaria.

Quindi ci sono un sacco di metodi disponibili. Alla fine si tratta sempre della decisione di pensarci perché un progetto diventa abbastanza grande.

— Eddi
fonte

Questo non risponde alla domanda.

— Hulk,