Quali sono le cause che portano a un software iperbloccato? [chiuso]

Oggi ho deciso di eseguire un'installazione pulita per i driver Creative Sound Blaster, poiché dopo qualche tempo iniziano sempre a lampeggiare da soli. E questo significava che dovevo passare attraverso l'intera procedura di pulizia. E mi ci sono voluti quasi 2 ore ..

E onestamente, non riesco a vedere un motivo per cui ?! E sebbene Creative, IMHO, sia un vincitore assoluto del 1 ° posto per la produzione di software di scarsa qualità che non funziona mai, il problema gonfio non è esclusivo per loro.

PC con driver per fotocamera digitale Canon avrà circa 10 voci Canon che sono interconnesse con tutti i tipi di connessioni. Visual Studio è anche un ottimo esempio, ci sono circa 50 voci per l'installazione completa e riparare quella cosa è possibile solo con il nuking completo. E una volta è persino riuscito a rovinare l'intera installazione del sistema operativo durante l'aggiornamento da VS2k8 a VS2k8SP1 o qualcosa del genere. A quanto pare, 5 GB di spazio libero non erano sufficienti per la patch da 300 Mb ...

Quindi questo sembra davvero essere un problema diffuso. Quasi ogni applicazione al giorno d'oggi di solito contiene disimballatori, più "amici" spywarish installati, i driver di solito sono circa 600 Mb per tutto, comprese le stampanti e così via.

Ma perché? È colpa dello sviluppatore? Applicazioni come questa sono un incubo da supportare, al giorno d'oggi non funzionano mai al 100% e quasi tutti gli utenti che conosco sono molto negativi su tutto ciò che ottengono come installazione obbligatoria del driver per chiavetta USB / Stampante / Fotocamera / Scheda audio / Browser.

Sembra che NSIS di Nullsoft sia l'unico sistema di installazione pulito che non sia gonfio, da quello che so, ad esempio, l'installazione di Firefox. Installazione pulita e praticamente basata su xcopy senza problemi.

Quindi perché le persone non utilizzano semplici configurazioni e applicazioni che non sono radicate su 30 livelli di interconnessione? È perché gli sviluppatori sono pigri? Uso di strumenti codegen? È perché le aziende impongono app pesanti come qualcosa che gli utenti ameranno? Qual è la causa, e c'è un speranza che il software torni alle origini un giorno? Quali sono i passaggi per evitare di scrivere bloat quando si avvia una nuova applicazione da zero?

La mia ipotesi è che ci sono molte caratteristiche che qualcuno ha pensato fosse una buona idea. Tuttavia, se molte persone hanno idee separate che si uniscono in un'unica applicazione, è così che può diventare così complicato. Non darei la colpa allo sviluppatore nel caso di grandi prodotti aziendali in cui dovrebbero esserci responsabili di prodotto che hanno la responsabilità di ciò che è nel prodotto e di come ottimizzarlo da varie prospettive.

Un altro aspetto di questo sarebbe il debito tecnico che probabilmente non viene gestito bene nella maggior parte dei casi in quanto non è visto come un grande investimento di tempo. Sospetterei che nuove funzionalità e correzioni di bug abbiano più senso dei refactoring o di altre attività di debito che potrebbero sembrare avere un valore commerciale immediato. Con quale frequenza un team di sviluppatori impiegherebbe un paio di settimane a ripulire il codice legacy se la base di codice è piuttosto vecchia? La mia ipotesi non sarebbe frequente.

Per citare Joel in Strategy Letter IV: Bloatware and the 80/20 Myth :

[...] ci sono molte ottime ragioni per bloatware. Per uno, se i programmatori non devono preoccuparsi di quanto sia grande il loro codice, possono spedirlo prima. [...] Se il tuo fornitore di software si ferma, prima della spedizione, e impiega due mesi a ridurre il codice per ridurlo del 50%, il vantaggio netto per te sarà impercettibile. [...] Ma la perdita per te di aspettare altri due mesi per la nuova versione è percepibile, e la perdita per la società di software che deve rinunciare a due mesi di vendite è ancora peggiore.

Molti sviluppatori di software sono sedotti dalla vecchia regola "80/20". E sembra di fare un sacco di senso: l'80% delle persone che usano il 20% delle funzionalità. Quindi ti convinci che devi solo implementare il 20% delle funzionalità e puoi ancora vendere l'80% di quante copie.

Sfortunatamente, non è mai lo stesso 20%. Tutti usano un diverso set di funzionalità. [...]

Quando inizi a commercializzare il tuo prodotto "lite" e dici alle persone "hey, è lite, solo 1 MB", tendono ad essere molto felici, quindi ti chiedono se ha la loro caratteristica cruciale, e non lo è, quindi non acquistano il tuo prodotto.

Gran parte di esso ha a che fare con le dipendenze di un prodotto. Il tuo sistema operativo viene fornito con molte librerie standard per tutti i tipi di cose. Tuttavia, queste librerie standard hanno versioni diverse durante l'evoluzione del sistema operativo e qualsiasi programma di installazione generico non può presumere che la versione specifica per la quale è stata costruita sarà effettivamente presente sul sistema operativo.

Pertanto, il programma di installazione completo dovrà includere la versione corretta di ogni dipendenza per assicurarsi che tutto funzioni definitivamente dopo l'installazione, indipendentemente dallo stato iniziale di ciascuna dipendenza sul computer di destinazione. Questo può essere piuttosto significativo per alcuni tipi di applicazioni, ad esempio applicazioni basate su .NET che devono essere distribuite su sistemi Windows XP.

Fino a poco tempo fa, un sistema di installazione con cui avevo lavorato aveva bisogno di installare ogni singola versione precedente di .NET per poter distribuire l'ultima versione, quindi ciò significava che qualsiasi applicazione .NET 3.5 richiedeva binari di installazione per .NET 1, 2, 2.5 e 3 IN ALTO a 3.5. In questo caso, solo l'installer è gonfio.

Una soluzione alternativa è un programma di installazione Web, che scarica solo quei componenti che in realtà non sono presenti sul sistema di destinazione - e questo può essere un enorme vantaggio in termini di dimensioni / dimensioni. Ovviamente limita le tue installazioni a sistemi dotati di connettività Internet.

Penso che molto abbia a che fare con un livello su un codice di libreria. Ovviamente quando si utilizza una libreria non si usa tutto al suo interno, quindi l'eccesso si somma quando si includono sempre più librerie.

Combinalo con il fatto che il costo di un'ora di lavoro di un programmatore sta diventando sempre più costoso mentre la potenza di elaborazione / archiviazione del computer tipico sta diventando più economica di anno in anno, vedi che in realtà è più efficiente in questo modo.

• "Abbiamo bisogno di qualcosa da fare X. Usiamo la libreria $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, perché l'ho usata in un altro progetto"
• "Penso che non abbiamo più bisogno di questa parte di codice, ma per assicurarti che nulla si rompa, tienilo"
• Test unitari insufficienti o insufficienti, che portano a
• Nessun refactoring
• Nessun tracciamento, dove le impostazioni sono state memorizzate nel corso degli anni, quindi ora le impostazioni sono ovunque
• ...

È un circolo vizioso in cui tutti i cicli di disperazione possono essere incolpati . Un ciclo di disperazione consiste nei seguenti passi:

1. Gli uomini d'affari richiedono funzionalità gonfiate.
2. Gli sviluppatori implementano le funzionalità gonfiate anche se sanno che non dovrebbero.
3. I clienti pagano per funzionalità gonfiate anche se vogliono solo il prodotto ma non la funzionalità stupida.
4. Gli uomini d'affari credono che i clienti desiderino funzionalità gonfiate.
5. Andare al passaggio 1 e ripetere.

Come lo fermi? Non esiste una risposta semplice su come, ma è chiaro che per interrompere il ciclo è necessario interrompere uno dei passaggi. Quindi può essere rotto solo da imprese, sviluppatori o consumatori che intraprendono un'azione rivoluzionaria.

1. Un ingegnere ha cercato di ottimizzare un modulo, ma ha introdotto diversi problemi con i clienti. Quindi, il suo manager ha detto di no. Quindi, l'ingegnere ha deciso di non "creare problemi" fino a quando i problemi non lo disturbano.
2. Per un sistema complesso, il fornitore ha già aggiunto molte patch e risolto migliaia di bug per renderlo stabile nell'ambiente del cliente. Non ha una buona qualità dal punto di vista del software ma funziona. Nessuno vuole riscriverlo per correggere nuovamente la stessa quantità di bug.
3. per motivi di compatibilità con le versioni precedenti, anche se una funzionalità non è popolare sul mercato, dobbiamo tenerla lì.

La sua pigrizia invariabilmente, ecco cosa provoca il gonfiore. (o il fango come nell'articolo fondamentale su questo argomento, la Big Ball of Mud )

Ad esempio, dove lavoro, abbiamo un'applicazione C ++ "legacy" che è comunque abbastanza ben progettata. I client parlano con un'API che parla con un server che fa funzionare DB. Tutto fatto in modo ragionevole. Di recente abbiamo avuto bisogno di un modulo aggiuntivo, ma invece di implementarlo correttamente lo sviluppatore ha deciso di implementarlo in .NET e, peggio ancora, ha deciso che l'accesso ai dati tramite l'API era troppo difficile (non è ma ...) avrebbe creato connessioni DB direttamente. Quindi vedi come succede questo tipo di casino. (e tutto con l'accordo dell'AT che ha messo "veloce" su "buono")

Ho già visto questo genere di cose prima - in un vecchio posto, una piccola parte della GUI era html, poiché alcuni sviluppatori hanno pensato che fosse una buona idea scrivere i dati in html e far sì che la GUI lo visualizzasse. Quindi 1 piccola parte fa qualcosa di diverso dal resto.

In breve, la pigrizia è cattiva e la coerenza è buona (indipendentemente dalla tecnologia utilizzata). Preferirei avere un'applicazione all-MFC piuttosto che un'applicazione che è in parte MFC e in parte Winforms e in parte WebGL con molte architetture back-end diverse che la mettono insieme.