Was sind die Ursachen, die zu einer überfüllten Software führen? [geschlossen]

Heute habe ich beschlossen, eine Neuinstallation für Creative Sound Blaster-Treiber durchzuführen, da diese nach einiger Zeit immer wieder von selbst fehlerhaft sind. Und das bedeutete, dass ich den gesamten Aufräumvorgang durchlaufen musste. Und das hat mich fast 2 Stunden gekostet ..

Und ehrlich gesagt, ich kann keinen Grund dafür sehen?! Und obwohl Creative, IMHO, ein absoluter Gewinner des 1. Platzes für die Herstellung von Software von schlechter Qualität ist, die niemals funktioniert, ist das Problem des Aufblähens nicht nur für sie.

Ein PC mit Canon Digitalkameratreiber verfügt über ca. 10 Canon-Einträge, die mit allen Arten von Verbindungen verbunden sind. Visual Studio ist auch ein Paradebeispiel. Es gibt ungefähr 50 Einträge für die vollständige Installation, und die Reparatur dieses Dings ist nur mit vollständigem Nuking möglich. Und einmal gelang es mir sogar, die gesamte Betriebssysteminstallation zu ruinieren, als ich ein Upgrade von VS2k8 auf VS2k8SP1 oder so machte. Wie sich herausstellte, reichten 5 GB freier Speicherplatz nicht für 300 MB Patch ...

Das scheint also wirklich ein weit verbreitetes Problem zu sein. Fast jede Anwendung enthält heutzutage normalerweise Entpacker, mehrere spywarische "Freunde", die installiert sind, Treiber sind normalerweise ungefähr 600 MB für alles, einschließlich Drucker und so weiter.

Aber warum? Ist es Entwicklerfehler? Solche Anwendungen sind ein Albtraum, sie funktionieren heutzutage nie mehr zu 100%, und fast alle Benutzer, die ich kenne, stehen dem Aufblähen, das sie als obligatorische Treiberinstallation für USB-Stick / Drucker / Kamera / Soundkarte / Browser erhalten, sehr negativ gegenüber.

Es scheint, dass NSIS von Nullsoft das einzige saubere Setup-System ist, das nicht aufgebläht ist, wie ich zum Beispiel die Firefox-Installation kenne. Saubere, ziemlich xcopy-basierte Installation ohne Probleme.

Warum verwenden Benutzer keine einfachen Setups und Anwendungen, die nicht über 30 Verbindungsebenen verwurzelt sind? Liegt es daran, dass Entwickler faul sind? Verwendung von Codegen-Tools? Liegt es daran, dass Unternehmen Schwergewichts-Apps als etwas erzwingen, das Benutzer lieben werden? Was ist die Ursache und gibt es eine Hoffnung, dass die Software eines Tages wieder zu den Grundlagen zurückkehren wird? Was sind die Schritte, um ein Aufblähen zu vermeiden, wenn Sie eine neue Anwendung von Grund auf neu starten?

Ich vermute, dass es viele Funktionen gibt, die jemand für eine gute Idee hielt. Wenn jedoch viele Menschen unterschiedliche Ideen haben, die in einer Anwendung zusammengefasst werden, kann dies so kompliziert werden. Ich würde dem Entwickler nicht die Schuld bei großen Unternehmensprodukten geben, bei denen es Produktmanager geben sollte, die dafür verantwortlich sind, was in dem Produkt enthalten ist und wie es aus verschiedenen Perspektiven optimiert werden kann.

Eine andere Seite davon wäre die technische Verschuldung, die in den meisten Fällen wahrscheinlich nicht gut verwaltet wird, da sie nicht als große Zeitinvestition angesehen wird. Ich würde vermuten, dass neue Funktionen und Fehlerkorrekturen sinnvoller sind als Refactorings oder andere Schuldenaufgaben, die möglicherweise nur einen geringen unmittelbaren geschäftlichen Wert haben. Wie oft würde ein Entwicklerteam ein paar Wochen Zeit haben, um alten Code zu bereinigen, wenn die Codebasis ziemlich alt ist? Meine Vermutung wäre nicht oft.

Um Joel in Strategy Letter IV zu zitieren : Bloatware und der 80/20-Mythos :

[...] es gibt viele gute Gründe für Bloatware. Zum einen können Programmierer, die sich keine Gedanken darüber machen müssen, wie groß ihr Code ist, ihn früher versenden. [...] Wenn Ihr Softwareanbieter vor dem Versand stoppt und zwei Monate damit verbringt, den Code zu drücken, um ihn um 50% zu verkleinern, ist der Nettovorteil für Sie nicht wahrnehmbar. [...] Aber der Verlust für Sie, zwei Monate länger auf die neue Version zu warten, ist spürbar, und der Verlust für das Softwareunternehmen, das zwei Monate Umsatz aufgeben muss, ist noch schlimmer.

Viele Softwareentwickler lassen sich von der alten "80/20" -Regel verführen. Es scheint sehr sinnvoll zu sein: 80% der Menschen nutzen 20% der Funktionen. Sie überzeugen sich also davon, dass Sie nur 20% der Funktionen implementieren müssen und trotzdem 80% so viele Exemplare verkaufen können.

Leider sind es nie die gleichen 20%. Jeder nutzt andere Funktionen. [...]

Wenn Sie mit der Vermarktung Ihres "Lite" -Produkts beginnen und den Leuten sagen: "Hey, es ist Lite, nur 1 MB", sind sie in der Regel sehr glücklich. Dann fragen sie Sie, ob es ihre entscheidende Funktion hat, und das tut es nicht Sie kaufen Ihr Produkt nicht.

Ein großer Teil davon hat mit Abhängigkeiten eines Produkts zu tun. Ihr Betriebssystem wird mit vielen Standardbibliotheken für alle möglichen Dinge geliefert. Diese Standardbibliotheken haben jedoch im Laufe der Entwicklung des Betriebssystems unterschiedliche Versionen, und ein generisches Installationsprogramm kann nicht davon ausgehen, dass die spezifische Version, für die es erstellt wurde, tatsächlich auf dem Betriebssystem vorhanden ist.

Daher muss das vollständige Installationsprogramm die richtige Version jeder Abhängigkeit enthalten, um sicherzustellen, dass nach der Installation definitiv alles funktioniert, unabhängig vom Ausgangszustand jeder Abhängigkeit auf dem Zielcomputer. Dies kann für bestimmte Arten von Anwendungen, z. B. .NET-basierte Anwendungen, die auf Windows XP-Systemen bereitgestellt werden müssen, eine erhebliche Aufblähung sein.

Bis vor kurzem musste für ein Installationssystem, mit dem ich gearbeitet habe, jede einzelne frühere .NET-Version installiert werden, um die neueste Version bereitstellen zu können. Daher bedeutete jede .NET 3.5-Anwendung Installationsbinärdateien für .NET 1, 2, 2.5 und 3 Oben auf 3.5. In diesem Fall ist nur das Installationsprogramm aufgebläht.

Eine Problemumgehung ist ein Webinstallationsprogramm, das nur die Komponenten herunterlädt, die tatsächlich nicht auf dem Zielsystem vorhanden sind - und dies kann ein gigantischer Größen- / Aufblähungsvorteil sein. Natürlich beschränkt es Ihre Installationen auf Systeme mit Internetverbindung.

Ich denke, viel davon hat mit Schicht für Schicht Bibliothekscode zu tun. Wenn Sie eine Bibliothek verwenden, verwenden Sie natürlich nicht alles darin, sodass sich der Überschuss summiert, wenn Sie immer mehr Bibliotheken einschließen.

Kombinieren Sie dies mit der Tatsache, dass die Kosten für eine Arbeitsstunde eines Programmierers immer teurer werden, während die Verarbeitungsleistung / der Speicher des typischen Computers von Jahr zu Jahr billiger wird. Sie sehen, dass dies auf diese Weise tatsächlich kostengünstiger ist.

• "Wir brauchen etwas zu tun X. Verwenden wir die Bibliothek $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, weil ich sie in einem anderen Projekt verwendet habe."
• "Ich denke, wir brauchen diesen Codeteil nicht mehr, aber um sicherzustellen, dass nichts kaputt geht, behalten Sie ihn einfach."
• Keine oder nicht genügend Unit-Tests, die dazu führen
• Kein Refactoring
• Kein Tracking, wo Einstellungen im Laufe der Jahre gespeichert wurden, daher sind die Einstellungen jetzt überall
• ...

Es ist ein Teufelskreis, in dem jeder in den Zyklen der Verzweiflung beschuldigt werden kann . Ein Zyklus der Verzweiflung besteht aus den folgenden Schritten:

1. Geschäftsleute fragen nach aufgeblähten Funktionen.
2. Entwickler implementieren die aufgeblähten Funktionen, obwohl sie wissen, dass sie dies nicht sollten.
3. Kunden zahlen für aufgeblähte Funktionen, obwohl sie nur das Produkt, aber nicht die dumme Funktion wollen.
4. Geschäftsleute glauben, dass Kunden die aufgeblähten Funktionen wollen.
5. Fahren Sie mit Schritt 1 fort und wiederholen Sie den Vorgang.

Wie hörst du damit auf? Es gibt keine einfache Antwort darauf, wie, aber es ist klar, dass einer der Schritte unterbrochen werden muss, um den Zyklus zu stoppen. Daher kann es nur von Unternehmen, Entwicklern oder Verbrauchern gebrochen werden, die revolutionäre Maßnahmen ergreifen.

1. Ein Ingenieur versuchte, ein Modul zu optimieren, führte jedoch mehrere Kundenprobleme ein. Dann sagte sein Manager nein. Dann beschloss der Ingenieur, keine "Probleme zu machen", bis ihn Probleme stören.
2. Für ein komplexes System hat der Anbieter bereits viele Patches hinzugefügt und Tausende von Fehlern behoben, um es in der Kundenumgebung stabil zu machen. Aus Sicht der Software hat es keine gute Qualität, aber es funktioniert. Niemand möchte es umschreiben, um die gleiche Anzahl von Fehlern wieder zu beheben.
3. Aus Gründen der Abwärtskompatibilität müssen wir eine Funktion dort behalten, auch wenn sie auf dem Markt nicht beliebt ist.

Es ist immer Faulheit, das ist es, was das Aufblähen verursacht. (oder der Schlamm wie im wegweisenden Artikel zu diesem Thema, der Big Ball of Mud )

Wenn ich zum Beispiel arbeite, haben wir eine "Legacy" -C ++ - Anwendung, die dennoch recht gut gestaltet ist. Die Clients sprechen mit einer API, die mit einem Server kommuniziert, der DB-Arbeit leistet. Alles vernünftig gemacht. Vor kurzem brauchten wir ein zusätzliches Modul, aber anstatt es korrekt zu implementieren, entschied sich der Entwickler, dies in .NET zu implementieren, und schlimmer noch, er entschied, dass der Zugriff auf Daten über die API zu schwierig war (es ist nicht aber ...), dass er DB-Verbindungen herstellen würde direkt. Sie sehen also, wie diese Art von Chaos passiert. (und alle mit Zustimmung des TA, der "schnell" über "gut" stellte)

Ich habe so etwas auch schon einmal gesehen - an einem alten Ort war ein kleiner Teil der GUI HTML, da einige Entwickler es für eine gute Idee hielten, die Daten in HTML zu schreiben und die GUI dies anzeigen zu lassen. Ein kleiner Teil macht also etwas anderes als der Rest.

Kurz gesagt, Faulheit ist schlecht und Konsistenz ist gut (unabhängig von der verwendeten Technologie). Ich hätte lieber eine All-MFC-Anwendung als eine, die aus MFC und Winforms und WebGL besteht und viele verschiedene Back-End-Architekturen enthält, die alles miteinander verbinden.