Как предотвратить устаревание кода?

Ответ 1

Нет, нет ничего вокруг, хотя Windows 7 все еще может запускать DOS-программы, поэтому им не нравится, что их программы будут неработоспособными. Самая большая проблема, с которой они столкнутся, - это не новая поддержка или новые функции, а сокращение сообщества знаний по этому вопросу.

Моя компания в настоящее время запускает программы в Fortran, Clipper, VB6 и FoxPro, чтобы назвать некоторые из них, некоторые из которых существуют уже более 20 лет и пережили все обновления Windows без потерь. Обычно то, что делает старую программу непригодной, - это невозможность перекомпилировать программу для исправления ошибок.

Это, безусловно, помогает, однако, сломать функциональность ваших программ, чтобы, если вы решите перенести с VB6 на VB.Net, гораздо проще выбрать код многократного использования.

Ответ 2

Отличный вопрос.

Короткий ответ № Нет. Потому что весь код в конечном итоге устареет.

Если вы написали код в ассемблере x86, это продлится некоторое время. C код будет иметь большой срок хранения тоже. Но проблема заключается в том, что чем больше технология отбирается от ассемблера, тем короче срок его хранения из-за многих факторов.

Ответ 3

Не используйте фирменный язык. Конечно, библиотеки и платформы могут измениться, но интересно, что сам язык устарел. Придерживайтесь C, С++ или чего-либо еще с большой пользовательской базой, которая является открытым исходным кодом. Вероятно, они будут работать некоторое время, даже если сопровождающие перестанут его поддерживать - это означает Python, Ruby, Java и, возможно, С#. Мой хрустальный шар не так хорош вне C и С++, но есть веские причины для того, чтобы один из остальных продолжал 20-50 лет.

Visual Basic был забавным, но смешивание кода и пользовательского интерфейса, которое оно продвигает, ужасно с архитектурной точки зрения. Хороший дизайн должен сделать возможным (не обязательно супер легко) изменить бэкэнд, инструментарий GUI и ОС.

Вы застряли с языком, поэтому выберите тот, который не ограничен одним продавцом, который постоянно меняет его.

Попробуйте прочитать Fire and Motion от Joel.

Ответ 4

Учитывая быстрое развитие технологий arround, устаревание является частью обычного цикла жизни для наших приложений.

Я действительно не знаю для настольных/серверных приложений, но в веб-разработке мы говорим, что 5 лет длинный, например ^^

Конечно, можно обновлять, исправлять, исправлять, исправлять, что угодно... Но обычно это ухудшает качество кода и качество самого приложения - это означает, что обслуживание будет стоить все больше и больше по прошествии времени; в конце концов, переписывание всего, вероятно, означает тратить меньше денег на обслуживание.

Ответ 5

Как говорили другие, это не "как мое выражение не может быть устаревшим". Это больше "когда мое приложение становится устаревшим, как я могу быстро выздороветь". И действительно, это просто другая версия других вопросов:

• Когда выйдет новая версия X, как я могу использовать новые функции?
• Когда изменяются бизнес-правила, как я могу вносить изменения в приложение?
• Когда это приложение здесь хочет получить доступ к данным, как быстро выставить данные?
• Когда клиент хочет перейти от толстого клиента к веб-клиенту, как я могу дать ему новую платформу?

Это то, что OO и SOA пытались ответить. Создавайте множество небольших независимых приложений и свободно объединяйте их вместе, используя стандартный механизм. Когда вам нужно обновить по какой-либо причине, вытащите его, обновите и подключите обратно.

Ответ 6

Я не знаю ни одного признанного метода предотвращения устаревания неиспользованного приложения.

Если вы хотите, чтобы продукт не устарел, создайте его для обновления.

В .NET, по крайней мере, у вас есть много и много вариантов для создания повторно используемых компонентов:

• Отдельные сборки, которые могут быть использованы в любом .NET-проекте, и могут быть впоследствии расширены для поддержки взаимодействия COM, если возникает необходимость использовать другую технологию.

• Веб-службы; они могут публиковаться и использоваться практически из любой среды.

• Интерфейсы и Inversion-of-Control могут использоваться для поддержки свободно взаимозаменяемых компонентов, которые теоретически могут возникать из чего-то, что даже не .NET(просто создайте COM-оболочку);

• Inter-process communication - если все остальное не работает, вы можете буквально просто создать файл с отображением памяти или именованный канал и начать переадресацию данных из (или предназначенных) для совершенно нового приложения.

Фактически, некоторые из этих вещей, вероятно, применимы к вашему текущему проекту VB. Существует, как правило, множество различных способов продления полезного срока службы существующего продукта, постепенно переходя основные функциональные возможности в новую технологию.

Я не hardcore SOA, но это именно та проблема, которую SOA пытается решить. Я занимаюсь многими услугами - на самом деле, почти все существенное здесь происходит через какой-то веб-сервис в какой-то момент - и я чувствую себя вполне комфортно, зная, что я могу полностью разорвать сервис в любое время и заменить его службой на другая платформа. Все, что нужно сделать, это выплюнуть SOAP или JSON, и мои клиенты .NET все еще могут его использовать. Или, наоборот, если мне нужно заменить клиентов, я могу просто подключиться к модели богатого домена, которая уже существует в сервисах.

Фактически, я уже это сделал - архитектура была построена полностью поверх платформы Delphi 7. Теперь все это на .NET 3.5, и никогда не было никакого жесткого перерыва с одной системы на другую. Мы начали создавать простые SOAP-сервисы, затем переместили много бизнес-логики в приложениях в службы, и в конечном итоге, когда приложение было не чем иным, как оболочкой, мы заменили его несколькими .NET-клиентами (есть несколько отдельные приложения), а затем начал добавлять различные функции безопасности и оптимизации, которые могут поддерживаться только на новых платформах. И так далее и т.д.

Так что это определенно можно сделать, если вы планируете заранее. Конечно, здесь есть несколько людей, которые будут советовать не планировать вперед, ссылаясь на YAGNI... и, возможно, это правда, для определенных проектов. Все зависит от того, насколько дорого или критически важно проект. Если продукт должен длиться в течение 50 лет, тогда вы можете подумать об инвестировании в какую-то прочную архитектуру и дизайн, что упростит вам добавление и удаление подкомпонентов.

Ответ 7

Они должны спросить себя, почему они думали, что было бы неплохо написать этот проект в VB6 для начала! Разве они не знали, что он уже не поддерживается и устарел? Если вы начнете использовать устаревшие технологии, что вы можете ожидать?

Они также должны рассмотреть возможность улучшения структуры своего кода VB6 и сделать его более объектно-ориентированным. Это упростит переход на .NET. Помимо прочего, они могут попытаться отделить функциональность от внешних классов, доступных через COM. Те же самые классы могут быть доступны из VB.NET. Кроме того, эти более мелкие части могут быть легче перенесены.

Ответ 8

Лучший способ - использовать инструменты и библиотеки кросс-платформенной разработки. Таким образом, Microsoft не может осуждать вещи, от которых вы зависите (поскольку они не контролируют их). Если вы зависите от чего-то конкретного от одного поставщика, то вероятность того, что в какой-то момент они вас заберут.

Ответ 9

Не сосредотачивайтесь на коде, который не может быть устаревшим. Редко вы работаете в стеке, которое применимо. Вместо этого сделайте свой код понятным и сжатым, чтобы вы могли его перенести, когда придет время. Вместо этого сосредоточьтесь на том, чтобы не позволить себе устареть. Работайте над тем, чтобы оставаться в курсе событий и знать, что происходит в вашем стеке, и старайтесь знать, что происходит, даже если вы не можете посвятить время, чтобы полностью применить себя к нему.

Учитывая эмуляцию и виртуальные машины, у меня возникает ощущение, что "устаревший" код будет иметь даже более продолжительный срок службы, чем предполагалось ранее. Это больше инструмент, в отличие от ОС, который вас должен беспокоить.

Ответ 10

Это зависит (возможно) от разделения кода от дизайна, особенно в веб-приложениях, которые часто сильно подвержены капризам моды. Но база кода запускается в текущей технологии, то есть ОС все равно будет запускать ее, тогда нет причин для "обновления".

Реальный способ гарантировать, что ваш код длится вечно, но это написать приложение, которое становится настолько незаменимым в использовании, но так дорого переписывать, что все, в том числе не переустановка ОС и оборудования, выполняется, чтобы обеспечить его работу. Я считаю, что одним из примеров этого является то, что некоторые основные системы на арене социального обеспечения/правительства США все еще работают в начале 1960 года COBOL и работают на старых мэйнфреймах IBM.

Ответ 11

С открытым исходным кодом или, по крайней мере, на платформе с открытым исходным кодом.

Я не знаю никаких проприетарных систем 1970-х годов, которые мы используем в соответствии с их старым использованием, но я знаю много открытых исходных кодов.

Это не идеальный механизм - все языки меняются, как бы незначительно, на эти временные рамки, а затем вам нужно сделать обновления для своего кода, чтобы получить новейшие материалы. Но я знаю множество серверов, на которых работает код, который был в течение десятилетий без изменений.

Еще лучше, с открытым исходным кодом или, насколько это возможно. Даже лучше, чем иметь возможность ничего не делать, может ничего не делать, пока другие люди обновляют его для вас. Требуется работа, чтобы запустить сообщество, но как только началось, их трудно остановить!

Утилита любой программы с открытым исходным кодом падает до нуля после конечного времени. Это не гарантирует, что open-source заставит его оставаться отличным от нуля, но, по крайней мере, шанс.

Ответ 12

Напишите стандартные (ANSI или ISO, я бы избежать ECMA) определения, которые в настоящее время серьезно используются. Избегайте ничего, зависящего от одной компании, или когда единственная полная реализация исходит от одной компании. Не используйте расширения языка поставщика. Будьте осторожны, чтобы избежать предположений о языке, таких как размер типа данных: если вы используете int для хранения размеров памяти, а не size_t, вам может быть сложнее работать в 64-разрядной системе.

Помните, что Microsoft замечательна среди компаний для сохранения обратной совместимости, и они сломали VB6 для вас. Любая другая компания, вероятно, будет хуже.

В любых значительных приложениях будут части, зависящие от платформы. Разделите их, чтобы ограничить то, что должно быть переписано, если платформа изменится.

Очевидно, в этом есть затраты. Например, я рекомендовал, чтобы приложения Windows выполнялись в Visual С++, при этом MFC использовался через слой абстракции, поскольку С#,.NET, VB.NET и F # не соответствуют моим критериям. Тем не менее, это то, как создать долгосрочную программу, если ваша цель.

Ответ 13

Я, должно быть, пропустил этот вопрос в феврале, извините. Насколько я вижу, никто не обратился к вашим коллегам с заключением, что им придется перестроить [свое приложение VB6] с нуля, чтобы перейти на .Net.

Это неверно: им не нужно переписывать, есть альтернативные методы, и они обычно далеко проще и дешевле, чем полностью переписать.

Вот официальный совет Microsoft UK:

Выполнение полного переписывания в .NET намного более дорогостоящее и сложное, чтобы преуспеть [чем конвертирование]... мы бы рекомендовали этот подход только для небольшого числа ситуаций.

Из сообщение в блоге от парня Microsoft, который консультировался по поводу перезаписи:

Многие компании, с которыми я работал в первые дни работы .NET, сначала смотрели на переписывание, отчасти обусловленное сильным желанием улучшить базовую архитектуру и структуры кода одновременно с переходом на .NET. К сожалению, многие из этих проектов столкнулись с трудностями, и некоторые из них никогда не были завершены. Проблема, которую они пытались решить, была слишком большой. [Это тот момент, когда у ваших коллег будут серьезные проблемы со своим боссом - люди увольняются в этот момент]

Скажите своим коллегам, чтобы проверить , > screencast, объясняя 5 основных вариантов миграции VB6 → VB.Net. Они должны выбрать путь вперед вместе со своим боссом. Это может быть переписывание, но они должны войти в него с открытыми глазами.

И они, вероятно, не должны писать ничего нового в VB6...