Lorsque vous envisagez une mise à niveau dans un outil de développement, quelle est l'importance de la rétrocompatibilité avec vous? Achèteriez-vous toujours Visual Studio 2010 s'il nécessitait des modifications importantes de votre code source? Où est le point de basculement pour vous en termes de compatibilité rétroactive pour les nouvelles fonctionnalités?Quelle est l'importance de la rétrocompatibilité?
Alors que vous avez demandé cela du point de vue du développeur, je pense que ce serait une question plus intéressante en référence au logiciel que vous développez. Donc, je vais répondre à cette question à la place. :)
Le matériel et les logiciels rétrocompatibles (et, plus important encore, compatibles avec l'avenir) procurent un sentiment de sécurité à vos utilisateurs, en particulier lors de l'achat ou de la mise à niveau de plates-formes comme Windows. Si rien d'autre, Windows est connu pour son attention méticuleuse à la rétrocompatibilité. Vous pouvez exécuter des programmes écrits il y a plus d'une décennie sur Windows Vista avec des problèmes mineurs, à condition qu'ils soient "bien écrits" (c'est-à-dire n'utilisez pas d'API non documentées). D'autre part, une attention particulière à la rétrocompatibilité peut vous lier lorsque vous essayez d'introduire de nouvelles fonctionnalités ou de révolutionner la plate-forme. Apple savait qu'il avait un système d'exploitation agonisant, et dans l'un de ses mouvements les plus audacieux, il a acheté NeXT et a décidé de faire de NeXTSTEP le nouveau MacOS. L'une des choses clés qui ont vendu les gens sur la transition était la couche classique rétrocompatible. Encore une fois quand Apple a décidé de passer aux puces Intel, un mécanisme pour exécuter des applications PowerPC sur Intel appelé Rosetta, avec les binaires universelles, a permis aux gens de se déplacer librement entre PowerPC et Intel sans crainte de perte d'application. Une chose intéressante est qu'avec la transition vers Intel, l'environnement Classic a disparu, mais personne ne s'en soucie vraiment car ils ont eu les 5 années précédentes pour quitter Mac OS 9. Il est donc possible d'abandonner la prise en charge des systèmes existants. Tant que vous avez un moyen facile de migrer vers le nouveau système et donner à vos utilisateurs suffisamment de temps pour le faire.
Définir "changements significatifs". Je vais y aller si les changements pourraient être faits avec une "recherche & remplacer" soigneusement, même si elles étaient étendues. Cependant, c'est ce que ferait I. Toute entreprise pour laquelle j'ai travaillé refuserait toute modification du code existant.
Cela dépend des environnements que vous devez prendre en charge et des outils tiers qui peuvent être compatabiles ou non. Par exemple, là où je travaille, nous avons mis à jour tout le monde vers VS2008 à partir de VS2005 à l'exception de notre groupe BI, les outils de BI de SQL Server n'étant pas compatibles avec VS2008. Une fois mises à jour, elles ont été mises à niveau vers VS2008.
Lorsque vous observez VS de manière spécifique, gardez à l'esprit que VS2008 peut cibler .NET 2.0, .NET 3.0 et .NET 3.5. L'astuce consiste à réaliser qu'il cible réellement .NET 2.0 SP1 et .NET 3.0 SP1. En tant que tel, la mise à niveau de l'EDI ne devrait pas vous obliger à apporter des modifications à votre code.
Étant donné que de nombreux changements sont en cours dans le domaine du logiciel et du matériel, je pense que c'est une bonne idée d'être ouvert à de nouveaux changements et de meilleurs outils pendant l'architecture de votre solution. Par exemple, nous n'avions pas de processeurs multi-core et de cartes graphiques haut de gamme ou de carte réseau dans les années 90, donc naturellement les objectifs d'optimisation des compilateurs et des outils étaient différents. Mais en même temps Visual studio comme outils font de leur mieux pour accueillir les anciens cadres et applications.
Je pense que si nous aspirons à un monde meilleur, nous devrions être ouverts à un changement constant jusqu'à ce que cette industrie soit surmaturée. (Peut ne pas arriver dans notre vie si bien :))
En général si vous développez une plate-forme qui sera constamment utilisée par beaucoup d'autres utilisateurs pour construire leurs propres produits, et vous projetez de développer l'application pour un longtemps, alors c'est important. Voyez les projets PHP, Python, Eclipse et d'autres projets open source qui accordent beaucoup d'importance à la rétrocompatibilité. Il est également important lors du développement de services ou d'autres apis ouverts utilisés dans l'architecture n-tier. Vous pouvez avoir toutes les applications d'une entreprise en panne tout le temps lorsque vous changez vos services. Maintenant, si vous construisez une application de film rétractable ou une application commerciale, ce n'est pas si important, car chaque version est séparée de ses prédécesseurs.
Pour les projets domestiques, la rétrocompatibilité n'est pas vraiment importante. Pour le bureau/l'entreprise, c'est absolument essentiel.
Dans un outil de développement, s'il ne fournit pas la compatibilité descendante totale avec mon code précédent, je ne l'achèterai pas et je doute que quiconque le ferait. Franchement, ça ne sert à rien. Si j'ai déjà un compilateur qui fonctionne pour construire mon code source en code exécutable qui fonctionne pour moi, alors je vais l'utiliser. Pourquoi s'embêter à changer mon code pour se conformer à ce qui est évidemment à l'outilleur pas un standard? S'ils forcent les changements de code source d'une version à l'autre, pourquoi prendraient-ils la peine de rendre la prochaine version compatible?
100% rétrocompatibilité avec la source est une exigence.La seule situation où ce n'est pas une exigence totale est lorsque les bits incompatibles sont des extensions; c'est-à-dire des changements d'API spécifiques à l'outil, tels que les plugins Eclipse, etc. Même dans ce cas, j'aimerais la compatibilité, mais je me rends compte que cela ne peut pas être complètement attendu. Mais si vous fournissez une API pour le développement d'applications/outils de base, et ne pouvez pas être dérangé pour maintenir la compatibilité; eh bien, vous n'êtes clairement pas sérieux au sujet de vos outils, et je ne paierai pas d'argent sérieux pour eux.
Je suppose que vous ne voulez pas vraiment dire cela aussi absolument que vous l'avez dit. Par exemple, C# 2 n'est pas 100% rétrocompatible avec C# 1. C'est proche, mais ce n'est pas 100%. D'après votre logique, personne n'aurait dû aller avec VS2005 ou VS2008. –
Je suis également en désaccord. J'ai aidé plusieurs personnes à migrer d'eVC vers Studio et du code qui "fonctionnait" sous eVC ne serait même pas compilé sous Studio parce que le compilateur est bien amélioré. Une fois la compilation terminée, les nouveaux runtimes ont également trouvé beaucoup de problèmes avec le code. Donc, même après des semaines de travail, ça en valait la peine. – ctacke
Pourriez-vous, en tant qu'expert, m'expliquer pourquoi ce n'est pas un article de wiki communautaire? – badbadboy
Parce que c'est une question légitime? Wiki communautaire n'est pas applicable à tout, et je ne reproche pas à Kogus de ne pas y avoir adhéré. –