Quelles sont les causes qui conduisent à un logiciel surchargé? [fermé]

Aujourd'hui, j'ai décidé d'effectuer une installation propre pour les pilotes Creative Sound Blaster, car ils commencent toujours à se débrouiller seuls après un certain temps. Et cela signifiait que je devais suivre toute la procédure de nettoyage. Et cela m'a pris près de 2 heures ..

Et honnêtement, je ne vois pas pourquoi?! Et bien que Creative, à mon humble avis, soit le premier vainqueur absolu pour la production de logiciels de mauvaise qualité qui ne fonctionnent jamais, le problème de ballonnement ne leur est pas exclusif.

PC avec pilote d'appareil photo numérique Canon aura environ 10 entrées Canon qui sont interconnectées avec toutes sortes de connexions. Visual Studio est également un excellent exemple, il y a environ 50 entrées pour une installation complète, et la réparation de cette chose n'est possible qu'avec un nuking complet. Et une fois, il a même réussi à ruiner l'installation du système d'exploitation lors de la mise à niveau de VS2k8 vers VS2k8SP1 ou quelque chose du genre. Il s'avère que 5 Go d'espace libre n'étaient pas suffisants pour un patch de 300 Mo ...

Donc, cela semble vraiment être un problème répandu. De nos jours, presque toutes les applications contiennent généralement des décompresseurs, plusieurs "amis" espions qui sont installés, les pilotes font généralement environ 600 Mo pour tout, y compris les imprimantes, etc.

Mais pourquoi? Est-ce la faute du développeur? Des applications comme celle-ci sont un cauchemar à prendre en charge, elles ne fonctionnent jamais à 100% de nos jours, et presque tous les utilisateurs que je connais sont très négatifs sur tout le ballonnement qu'ils obtiennent en tant qu'installation obligatoire du pilote pour la clé USB / l'imprimante / l'appareil photo / la carte son / le navigateur.

Il semble que NSIS de Nullsoft est le seul système de configuration propre qui ne soit pas gonflé, d'après ce que je sais, par exemple, l'installation de Firefox. Installation propre et à peu près basée sur xcopy sans aucun problème.

Alors pourquoi les gens n'utilisent pas de configurations et d'applications simples qui ne sont pas enracinées sur 30 couches d'interconnexion? Est-ce parce que les développeurs sont paresseux? Utilisation d'outils Codegen? Est-ce parce que les entreprises forcent les applications lourdes à plaire aux utilisateurs? Quelle est la cause, et y a-t-il un espoir que le logiciel revienne à l'essentiel un jour? Quelles sont les étapes pour éviter d'écrire des ballonnements lorsque vous démarrez une nouvelle application à partir de zéro?

Je suppose qu'il y a beaucoup de fonctionnalités que quelqu'un a pensé être une bonne idée. Cependant, si beaucoup de gens ont tous des idées distinctes qui sont rassemblées dans une seule application, c'est ainsi que cela peut devenir si compliqué. Je ne blâmerais pas le développeur dans le cas de grands produits d'entreprise où il devrait y avoir des chefs de produit qui ont la responsabilité de ce qui est dans le produit et comment l'optimiser sous différentes perspectives.

Un autre aspect à cela serait la dette technique qui n'est probablement pas bien gérée dans la plupart des cas, car elle n'est pas considérée comme un excellent investissement en temps. Je soupçonne que les nouvelles fonctionnalités et les corrections de bogues ont plus de sens que les refactorisations ou autres tâches de dette qui peuvent sembler avoir peu de valeur commerciale immédiate. À quelle fréquence une équipe de développeurs aurait-elle quelques semaines pour nettoyer le code hérité si la base de code est plutôt ancienne? Ma conjecture ne serait pas souvent.

Pour citer Joel dans la Lettre de stratégie IV: Bloatware et le mythe 80/20 :

[...] il y a beaucoup de bonnes raisons pour le bloatware. D'une part, si les programmeurs n'ont pas à se soucier de la taille de leur code, ils peuvent l'envoyer plus tôt. [...] Si votre fournisseur de logiciels s'arrête, avant l'expédition, et passe deux mois à presser le code pour le réduire de 50%, l'avantage net pour vous va être imperceptible. [...] Mais la perte pour vous d'attendre deux mois supplémentaires pour la nouvelle version est perceptible, et la perte pour la société de logiciels qui doit renoncer à deux mois de ventes est encore pire.

Beaucoup de développeurs de logiciels sont séduits par l'ancienne règle "80/20". Cela semble avoir beaucoup de sens: 80% des gens utilisent 20% des fonctionnalités. Vous vous assurez donc que vous n'avez besoin que de mettre en œuvre 20% des fonctionnalités et que vous pouvez toujours vendre 80% de copies.

Malheureusement, ce n'est jamais le même 20%. Tout le monde utilise un ensemble différent de fonctionnalités. [...]

Lorsque vous commencez à commercialiser votre produit "lite" et que vous dites aux gens: "hé, c'est lite, seulement 1 Mo", ils ont tendance à être très heureux, puis ils vous demandent s'il a leur caractéristique cruciale, et ce n'est pas le cas, alors ils n'achètent pas votre produit.

Une grande partie est liée aux dépendances d'un produit. Votre système d'exploitation est livré avec de nombreuses bibliothèques standard pour toutes sortes de choses. Cependant, ces bibliothèques standard ont des versions différentes tout au long de l'évolution du système d'exploitation, et aucun programme d'installation générique ne peut supposer que la version spécifique sur laquelle il a été construit sera réellement présente sur le système d'exploitation.

Par conséquent, le programme d'installation complet devra inclure la version correcte de chaque dépendance pour s'assurer que tout fonctionnera définitivement après l'installation, quel que soit l'état initial de chaque dépendance sur l'ordinateur cible. Cela peut être assez lourd pour certains types d'applications, par exemple les applications basées sur .NET qui doivent être déployées sur les systèmes Windows XP.

Jusqu'à récemment, un système d'installation avec lequel je travaillais avait besoin que chaque version précédente de .NET soit installée pour pouvoir déployer la dernière version, ce qui signifiait que toute application .NET 3.5 nécessitait des binaires d'installation pour .NET 1, 2, 2.5 et 3 AU-DESSUS de 3.5. Dans ce cas, seul l'installateur est gonflé.

Une solution de contournement est un programme d'installation Web, qui télécharge uniquement les composants qui ne sont pas réellement présents sur le système cible - et cela peut être un avantage gigantesque de taille / ballonnement. Bien sûr, cela limite vos installations aux systèmes disposant d'une connectivité Internet.

Je pense que cela a beaucoup à voir avec la couche après couche de code de bibliothèque. De toute évidence, lorsque vous utilisez une bibliothèque, vous n'utilisez pas tout ce qu'elle contient, de sorte que l'excès s'additionne lorsque vous incluez de plus en plus de bibliothèques.

Combinez cela avec le fait que le coût d'une heure de travail d'un programmeur devient de plus en plus cher alors que la puissance de traitement / stockage de l'ordinateur typique devient moins cher chaque année, vous voyez qu'il est en fait plus rentable de cette façon.

• "Nous avons besoin de quelque chose pour faire X. Utilisons la bibliothèque $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, car je l'ai utilisée dans un autre projet"
• "Je pense que nous n'avons plus besoin de cette partie de code, mais pour nous assurer que rien ne casse, il suffit de le garder"
• Pas ou pas assez de tests unitaires, ce qui conduit à
• Pas de refactoring
• Pas de suivi, où les paramètres ont été stockés au fil des ans, alors maintenant les paramètres sont partout
• ...

C'est un cercle vicieux où tout le monde dans les cycles de désespoir peut être blâmé . Un cycle de désespoir comprend les étapes suivantes:

1. Les gens d'affaires demandent des fonctionnalités gonflées.
2. Les développeurs implémentent les fonctionnalités gonflées même s'ils savent qu'ils ne devraient pas.
3. Les clients paient pour les fonctionnalités gonflées même s'ils ne veulent que le produit mais pas la fonctionnalité stupide.
4. Les gens d'affaires croient que les clients veulent les fonctionnalités gonflées.
5. Allez à la première étape et répétez.

Comment l'arrêtez-vous? Il n'y a pas de réponse facile sur la façon de procéder, mais il est clair que pour arrêter le cycle, l'une des étapes doit être interrompue. Ainsi, il ne peut être rompu que par les entreprises, les développeurs ou les consommateurs qui entreprennent une action révolutionnaire.

1. Un ingénieur a tenté d'optimiser un module mais a présenté plusieurs problèmes avec les clients. Ensuite, son manager a dit non. Ensuite, l'ingénieur a décidé de ne pas «faire de problèmes» jusqu'à ce que les problèmes le dérangent.
2. Pour un système complexe, le fournisseur a déjà ajouté de nombreux correctifs et corrigé des milliers de bugs pour le rendre stable dans l'environnement du client. Il n'a pas une bonne qualité du point de vue logiciel mais ça marche. Personne ne veut le réécrire pour corriger à nouveau le même nombre de bogues.
3. pour des raisons de compatibilité descendante, même si une fonctionnalité n'est pas populaire sur le marché, nous devons la conserver.

Sa paresse invariablement, c'est ce qui cause le ballonnement. (ou la boue comme dans l'article fondateur sur ce sujet, la Grande Boule de Boue )

Par exemple, là où je travaille, nous avons une application C ++ "héritée" qui est néanmoins assez bien conçue. Les clients parlent à une API qui parle à un serveur qui fonctionne DB. Tout est judicieusement fait. Récemment, nous avions besoin d'un module supplémentaire, mais plutôt que de l'implémenter correctement, le développeur a décidé de l'implémenter dans .NET, et pire encore, il a décidé que l'accès aux données via l'API était trop difficile (ce n'est pas mais ...) il établirait des connexions DB directement. Vous voyez donc comment ce genre de gâchis se produit. (et tout cela avec l'accord de l'AT qui a mis "vite" sur "bien")

J'ai déjà vu ce genre de chose auparavant - à un ancien endroit, une petite partie de l'interface graphique était en HTML, car certains développeurs pensaient que c'était une bonne idée d'écrire les données en HTML et que l'interface graphique affiche cela. Donc 1 petite partie fait quelque chose de différent du reste.

En bref, la paresse est mauvaise et la cohérence est bonne (quelle que soit la technologie utilisée). Je préfère avoir une application entièrement MFC qu'une application qui est en partie MFC et en partie Winforms et en partie WebGL avec de nombreuses architectures back-end différentes reliant le tout ensemble.