Punto di complessità di non ritorno. Come lo chiami?

13

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

Tuttavia, in alcuni progetti, c'è un momento in cui il livello di complessità aumenta così tanto da raggiungere una sorta di punto "senza ritorno". Passato questo momento, non puoi mai riportare il progetto a un livello accettabile di complessità in meno tempo rispetto a quello che avresti bisogno di riscrivere tutto da zero.

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

- Modifica -

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

    
posta Thibault J 05.05.2011 - 10:55
fonte

8 risposte

20

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

Il fenomeno è chiamato "debito tecnico" e una volta raggiunto un livello critico il progetto è in via di fallimento.

È questo che intendevi?

    
risposta data 05.05.2011 - 11:12
fonte
16

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

OH MIO DIO CHE COSA È QUESTO CORAGGIO.

Il problema è che questo può essere applicato a qualcosa che in realtà è semplice, ma è implementato in 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 in realtà tende a succedere a tutto il software è un processo simile a questo:

Passaggio 1: avere una buona spec, fare un bel design, implementare cose carine. Tutti felici.

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

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

Alla fine del passaggio 2: gli sviluppatori si congratulano con loro per la meravigliosa eleganza del loro design, e se ne vanno via pensando felice "Accidenti, sono così intelligente da aver fatto tutti questi assegni nel passaggio 1. È andata così bene. un meraviglioso lascito per gli altri in futuro, sarà meraviglioso e il mondo sarà un posto migliore. "

Passaggio 3: più modifiche vengono apportate, più cose vengono aggiunte, 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 loro per la meravigliosa eleganza del loro design, e vanno via pensando abbastanza felice "Accidenti, questa architettura è abbastanza buona da permettere a tanti cambiamenti di inserirsi facilmente. un po 'scontento di X e Y e Z. Potrebbero essere ripuliti un po' ora, ma !!! Ahhh !!! Sono così intelligente da aver fatto tutti questi assegni nel passaggio 1. È andata così bene. legacy qui per gli altri per 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 che era così buona è stata mantenuta da UGLY. Ha davvero bisogno di alcuni cambiamenti seri, non mi piace lavorare su questo, ha bisogno di refactoring. quello che dirà il capo quando gli dirò che ha bisogno di 6 settimane e non ci sarà nulla per gli utenti da vedere alla fine di questo ... ma avrò altri 5 anni di buonissimo scopo di modifica futuro 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 fucilati. È orribile. Dobbiamo riscriverlo. "

Il passaggio 5 è fatale. Questo è il punto in cui il fattore cruft è diventato così grave che il codice non può avere solo qualche cambiamento in più, ma deve avere alcune modifiche GRANDI.

Il problema al punto 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 anziché fatti, il 150% di entusiasmo invece di conoscenza, il 200% di arroganza invece di umiltà ("Quei ragazzi erano così stupidi!"). E tu introduci un sacco di nuovi bug.

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

    
risposta data 05.05.2011 - 12:17
fonte
2

Sono d'accordo sul fatto che il momento è difficile da riconoscere e può essere evitato tramite processi adeguati. Tuttavia, la domanda riguardava come chiamarla. Nell'economia reale, c'è il concetto di "rendimenti decrescenti": il punto in cui l'aumento di input per una risorsa in un processo diminuisce il profitto complessivo per unità. Questo certamente si applica alla codifica, e anche cose buone come l'astrazione, il riuso ecc. Hanno un tale punto di rendimenti decrescenti. Il termine specifico per la programmazione generale è "sovrastruttura". Per qualcuno che è incline a fare questo, mi piace il termine di Joel " architettura astronauta ".

    
risposta data 05.05.2011 - 17:32
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 e più affidabile, solo per trovarlo

  • La complessità è nell'informatica requisiti
  • I nuovi strumenti sono più difficili da utilizzare, quindi il sito Web Flash promesso
  • Il nuovo team non è così "caldo" come pensavano che fosse

Forse il tempo che hai descritto arriva con alcune basi di codice (ero solito pensarla così). Non ho mai sperimentato personalmente un caso di codice vecchio che ha causato un errore nel progetto, o riscritto il codice salvando un progetto.

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

    
risposta data 05.05.2011 - 11:34
fonte
1

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

Ma mi piace che potremmo dargli un nome. "Gentili," potresti dire, attirando intorno a te i tuoi colleghi sviluppatori, "Abbiamo attraversato la Manutenibilità di Hellespont. Manda un messaggio a tua moglie e falle sapere che non la vedrai da un po '."

    
risposta data 05.05.2011 - 14:57
fonte
-1

Non so se c'è un nome ma se non ce n'è ne vorrei proporre chiamandolo "punto di fusione"

    
risposta data 05.05.2011 - 12:31
fonte
-2

Questa non è una domanda molto interessante.

In effetti è banale.

È così semplice che ci siamo evoluti in numerosi modi per farcela.

  1. Metodologie a cascata. Molte persone passano molto tempo a esaminare i requisiti e i documenti di progettazione per essere certi che la complessità sia gestita.

  2. Metodologie agili. Meno persone passano meno tempo a discutere su ciò che è immediatamente applicabile per risolvere il problema di qualcuno e rilasciare il software a loro. La complessità è gestita perché tutti sono concentrati sull'ottenere qualcosa rilasciato.

L'unica volta in cui qualcuno lotta con la "complessità" è a causa di un errore nel seguire la metodologia e gestire correttamente il 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 di sprint o priorità del caso d'uso appropriato in una metodologia Agile. Non sono focalizzati sull'ottenere qualcosa rilasciato all'utente il più rapidamente possibile.

La complessità dovrebbe essere limitata impostando gli obiettivi.

Wrestling with complex significa che gli obiettivi non sono impostati o non ricompensati correttamente.

Non esiste un "punto di svolta". Se la gestione della complessità è in qualche modo un problema, qualcosa è già sbagliato in termini organizzativi.

    
risposta data 05.05.2011 - 11:57
fonte
-2

Esistono metodi per visualizzare e monitorare il rischio di aumentare la complessità per i (grandi) progetti e il codice. Quando vengono applicati ragionevolmente si spera che non sia necessario un nuovo nome per il punto di non ritorno. (C'è un MOOC relativo a openHPI: link )

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

I metodi per ridurre la complessità strutturale sono link :

  • modularizzazione
  • evitare i loop di feedback
  • triangolazione

Inoltre c'è il concetto di design assiomatico: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Con questo concetto è possibile evitare problemi di affidabilità dovuti a complessità inutili.

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

    
risposta data 28.06.2016 - 19:03
fonte

Leggi altre domande sui tag