Когда вы рассматриваете обновление в инструменте разработки, насколько важна обратная совместимость с вами? Вы по-прежнему будете покупать Visual Studio 2010, если это потребует значительных изменений в исходном коде? Где переломный момент для вас с точки зрения обратной обратной совместимости для новых функций?Насколько важна обратная совместимость?
Хотя вы просили об этом с точки зрения разработчика, я думаю, что это будет более интересный вопрос в отношении разрабатываемого программного обеспечения. Поэтому я собираюсь ответить на этот вопрос. :)
Аппаратное и программное обеспечение, совместимое в обратном направлении (и, что более важно, совместимое с будущим), обеспечивает ощущение безопасности для ваших пользователей, особенно при покупке или модернизации платформ, таких как Windows. Если ничего больше, Windows известна своим тщательным вниманием к обратной совместимости. Вы можете запускать программы, написанные более десяти лет назад в Windows Vista, с незначительными проблемами при условии, что они «хорошо написаны» (т. Е. Не используют недокументированные API).
С другой стороны, строгое внимание к обратной совместимости может связывать ваши руки, когда вы пытаетесь внедрить новые функции или революционизировать платформу. Apple знала, что у нее есть умирающая ОС, и в одном из самых смелых шагов она приобрела NeXT и решила сделать NeXTSTEP новым MacOS. Одной из ключевых вещей, которые продавали люди на переходном этапе, был класс, совместимый с предыдущим поколением. Опять же, когда Apple решила переключиться на чипы Intel, механизм запуска приложений PowerPC в Intel под названием Rosetta, наряду с Universal Binaries, позволил людям свободно перемещаться между PowerPC и Intel, не опасаясь потери приложения.
Интересно, что с переходом на Intel классическая среда исчезла, но никто не заботился, потому что им предшествовали 5 лет для перехода от Mac OS 9. Таким образом, в конечном итоге можно отказаться от поддержки устаревших систем, поскольку поскольку у вас есть простой способ перехода на новую систему и дать вашим пользователям достаточно времени для этого.
Определите «существенные изменения». Я бы пошел на это, если бы изменения могли быть сделаны с тщательно обработанным «поиском & заменить», даже если они были обширными.
Однако, это то, что I сделал. Любая компания, над которой я работала, не сможет изменить какие-либо изменения в существующем коде.
Это зависит от того, какие среды вам необходимо поддерживать и какие инструменты сторонних разработчиков используются, а какие могут быть или нет.
Например, где я работаю, мы обновили всех до VS2008 от VS2005, за исключением нашей группы BI, поскольку инструменты SQL Server BI не были совместимы с VS2008. После того, как они были обновлены, они были обновлены до VS2008.
Если вы смотрите на VS, имейте в виду, что VS2008 может ориентироваться на .NET 2.0, .NET 3.0 и .NET 3.5. Трюк заключается в том, чтобы понять, что он на самом деле нацелен на .NET 2.0 SP1 и .NET 3.0 SP1. Таким образом, для обновления IDE не требуется внесение изменений в код.
Поскольку в области программного и аппаратного обеспечения происходят изменения, я считаю, что неплохо быть открытым для новых изменений и более эффективных инструментов при архивировании вашего решения. Например, в 90-х годах у нас не было многоядерных процессоров и высокопроизводительных видеокарт или сетевой карты. Поэтому, конечно, цели оптимизации составителей и инструментов были разными. Но в то же время Visual studio как инструменты делают все возможное, чтобы разместить старые фреймворки и приложения.
Я думаю, что если мы с нетерпением ждем лучшего мира, мы должны быть открыты для постоянных изменений, пока эта отрасль не станет зрелой. (Может не произойти в нашей жизни, хотя :))
В genreal, если вы разрабатываете платформу, которая будет постоянно использоваться многими другими пользователями для создания собственных продуктов, и вы планируете разработать приложение для долгое время это важно. См. PHP, Python, Eclipse и другие проекты с открытым исходным кодом, которые придают большое значение обратной совместимости. Это также importan при разработке сервисов или других открытых apis, используемых в n-уровневой архитектуре. У вас могут быть все приложения на предприятии, которые постоянно ломаются, когда вы меняете свои услуги.
Теперь, если вы создаете приложение для упаковки в термоусадочную пленку или приложение для бизнеса, это не так важно, так что каждая версия отделена от своих предшественников.
Для домашних проектов обратная совместимость действительно не важна. Для офиса/предприятия это абсолютно важно.
В инструменте разработки, если он не дает полной обратной совместимости с моим предыдущим кодом, я не буду покупать его, и я сомневаюсь, что кто-то это сделает. Честно говоря, нет смысла. Если у меня уже есть компилятор, который работает для создания моего исходного кода в исполняемый код, который работает для меня, то я буду использовать его. Зачем мне менять код, чтобы соответствовать тому, что, очевидно, не для стандартного инструментария? Если они вынуждают изменения исходного кода от одной версии к другой, почему они потрудились сделать следующую версию совместимой?
100% обратная совместимость с источником является обязательным требованием.Единственная ситуация, когда это не является общим требованием, - это когда несовместимые биты являются расширениями; то есть изменения API, характерные для этого инструмента, такие как плагины Eclipse и т. д. Даже тогда я хотел бы получить совместимость, но я понимаю, что это невозможно полностью ожидать. Но если вы предоставляете API для базового приложения/разработки инструмента и не можете быть обеспокоены поддержкой совместимости; хорошо, тогда вы явно несерьезны в своих инструментах, и я не буду платить им серьезные деньги.
Не могли бы вы, как опытный парень, объяснить мне, почему это не сообщество wiki? – badbadboy 2008-11-20 19:56:38
Потому что это законный вопрос? Community Wiki не применим ко всему, и я не виню kogus за то, что не выбрал его. – 2008-11-20 20:05:53