Вы когда-нибудь полностью переписывали большое приложение C ++ на C #?

Думали ли вы о том, что вместо того, чтобы переписывать с нуля, вам следует начать разделять графический интерфейс и внутренний слой, если это еще не сделано, тогда вы можете начать писать его части на C #.

250 000 строк не были написаны в одночасье, они содержат сотни тысяч человеко-лет усилий, поэтому никто в здравом уме не предложил бы переписать все с нуля сразу.

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

Моя компания действительно это сделала. У нас была база кода C ++ примерно такого размера, и все (программисты, руководство, клиенты) более или менее согласились, что это не лучшая программа. Нам нужны были некоторые функции, которые было бы чрезвычайно сложно реализовать в старой кодовой базе, поэтому мы решили (после многих обсуждений и тестовых проектов) переписать их на .NET. Мы повторно использовали код, который был достаточно модульным с использованием C ++ / CLI (около 20% этого кода - в основном критичные для производительности вещи, которые в любом случае должны были быть написаны на C ++), но остальное было переписано с нуля. На это ушло около 2 человеко-лет, но это количество действительно во многом зависит от типа приложения, размера вашей команды и, конечно, от ваших программистов. Я бы счел все это успешным: мы смогли перестроить всю систему, чтобы включить новые функции, которые были бы почти невозможны со старой базой кода. Мы также могли избежать проблем, которые часто возникали в старом программном обеспечении, путем изменения их дизайна. Кроме того, новая система стала намного более гибкой и модульной в тех местах, где мы узнали, что гибкость была необходима. (На самом деле я иногда удивляюсь, насколько легко новые функции могут быть включены в новую систему, хотя мы никогда не задумывались о них, когда разрабатывали ее.)

Итак, в двух словах: для проекта среднего размера (100–500 тыс. Локаций) переписывание - это вариант, но вы обязательно должны знать цену и рисковать. Я бы сделал это только в том случае, если бы старая кодовая база была действительно некачественной и не поддавалась рефакторингу.

Также есть две ошибки, которых нельзя делать:

1. Наймите нового .NET-программиста и позвольте ему / ей сделать переписывание - кто-то новый может помочь, но большая часть работы и особенно дизайн должны выполняться разработчиками, которые имеют достаточный опыт работы со старым кодом, поэтому у них есть твердое понимание требований. В противном случае вы просто повторите свои старые ошибки (плюс пару новых) на другом языке.
2. Пусть программист на C ++ выполнит перезапись в качестве своего первого проекта на C #. Это рецепт катастрофы по понятным причинам. Когда вы беретесь за проект такого размера, вы должны иметь твердое представление о структуре, которую вы используете.

(Я думаю, что эти две ошибки могут быть причиной того, почему так много переписываний терпят неудачу.)

Его пробовали раньше, не только C ++ => C #, но и VB6 => VB.NET, C ++ => Java и любые другие старые => новые, о которых вы можете подумать. это никогда не работало. Я думаю, что, поскольку люди не считают это преобразование тем, чем оно является на самом деле (полное переписывание), они склонны относиться к нему легкомысленно.

История миграции с C ++ => .NET должна осуществляться через CLI, тщательно решая, что управляемое, а что остается неуправляемым, и «исправляя» по частям.

Expression Blend изначально был приложением MFC. Текущая версия использует WPF для пользовательского интерфейса, но движок по-прежнему полностью родной. Около года назад я видел отличную беседу главного архитектора Генри Соуизрала, в которой он описал процесс миграции. Сделайте UI движка независимым, и вы сможете поддерживать все, что есть в новейшей технологии UI. У команды Expression когда-то было то, что он назвал версией с головой гидры. Два интерфейсных интерфейса, работающих одновременно с одним базовым движком, - таким образом они могли видеть, где поведение непреднамеренно отклонялось от предыдущей версии. Поскольку пользовательский интерфейс подписан на события и уведомления, изменения, сделанные в окне инструментов WPF, отражались в старом окне инструментов MFC.

РЕДАКТИРОВАТЬ: похоже, что некоторые powerpoints имеют вид доступно здесь или как html здесь.

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

Однако, основываясь на нашем опыте, я скажу, что такое переписывание (особенно если вы можете повторно использовать некоторый код бизнес-логики C ++ в .NET) не так технически опасно, как может показаться. Однако это может быть очень социально опасно!

Во-первых, вы должны убедиться, что все полностью понимают, что изначально вы предпринимаете «переписывание» (или «переделку»), а не обновление или «переосмысление». «Психо» 1998 года было поэтапным ремейком оригинала 1960 года. Звездный крейсер «Галактика» 2003 года был переосмыслением оригинала 1978 года. Увидеть разницу?

В нашем случае первоначальный план состоял в том, чтобы воссоздать существующий продукт в .NET. Это не было бы технически сложной задачей, поскольку мы хорошо понимали оригинал. Однако на практике желание добавить, исправить и улучшить всего несколько вещей оказалось непреодолимым и, в конечном итоге, увеличило сроки на 2–3 года.

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

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

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

C ++ не будет автоматически переводиться на C # (в любом случае, вы не захотите его поддерживать), и вы говорите об использовании других фреймворков.

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

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

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

Я сделал нечто подобное. Часть моей работы связана с разработкой и поддержкой программного обеспечения ContractEdge. Первоначально он был разработан на Visual C ++ 6 группой из Индии. Затем я взял на себя роль разработчика после того, как это было в основном сделано в 2004 году. Позже, когда Windows Vista стала доступной в качестве бета-версии, я обнаружил, что ContractEdge вылетает в Vista. То же самое произошло и с релиз-кандидатом.

Итак, я столкнулся с решением. Либо ищите проблему в десятках тысяч строк в основном незнакомого кода, либо воспользуйтесь возможностью, чтобы переписать ее на .NET. Ну, я переписал его на VB.NET 2.0 примерно за 2 месяца. Я подошел к этому как к полной переработке, по существу отказавшись от всего, и я просто сосредоточился на дублировании функциональности на другом языке. Оказалось, что в оригинале мне нужно было написать только 1/10 от количества строк кода. Затем мы провели месячную бета-программу, чтобы исправить оставшиеся ошибки. Сразу после этого мы запустили его, и с тех пор он пользуется большим успехом, с меньшим количеством проблем, чем версия C ++, которую он заменил.

В нашем конкретном сценарии я думаю, что переписывание сработало хорошо. Решение было упрощено, поскольку никто из нашей команды не был так знаком с C ++, как с .NET. Так что с этой точки зрения ремонтопригодность теперь намного проще. В настоящее время я думаю, что C ++ - это слишком низкоуровневый язык для большинства бизнес-программ. Вы действительно можете сделать намного больше в .NET с меньшим количеством кода. Я писал на эту тему в моем блоге .

Тотальный перезапись ради перезаписи? Я бы не рекомендовал это.

В дополнение к другим ответам я бы не стал воспринимать «более быстрое время разработки» как должное. Конечно, для большинства "бизнес-приложений", ориентированных на данные, это, вероятно, будет иметь место, но есть много областей, где .NET не принесет значительного повышения производительности, плюс вам нужно принимать во внимание кривую обучения.

Мы сделали большую миграцию C ++ >> C # по мере перехода на .NET. Это довольно сложный проект. Руководство вряд ли возьмется за это финансирование, поэтому придется идти на компромисс. Лучший подход - оставить самые внутренние (или самые низкие) уровни в C ++ и покрыть верхнюю часть C #, с улучшенными API, разработанными с учетом новых концепций, таких как удобочитаемость и удобство использования API, защищенными модульными тестами и расширенными инструментами, такими как FxCop. Очевидно, что это великие победы.

Это также поможет вам немного лучше наслоить ваши компоненты, поскольку заставляет определенные разрезы. Конечный продукт нехороший, так как вы можете в конечном итоге скопировать много кода на C ++, потому что годы и годы кодирования содержат множество исправлений ошибок и множество недокументированных и трудных для понимания оптимизаций. Добавьте к этому все трюки с указателями, которые вы могли бы проделать в C (наш код со временем превратился из C в C ++). По мере стабилизации вы обнаруживаете, что все больше и больше читаете код C ++ и переносите его на C # - в отличие от целей «более чистого дизайна», которые вы имели в виду вначале.

Тогда вы обнаружите, что производительность взаимодействия - отстой. Это может потребовать повторной перезаписи - возможно, теперь используйте небезопасный код C #. Гррр!

Если все члены команды пришли из C ++, новый код также будет похож на дизайн C ++. Попробуйте объединить в команду разработчиков C # и C ++, чтобы в конце вы могли получить API, более похожий на .NET.

Через некоторое время проект может потерять интерес, и MGMT может не профинансировать всю переписывание, поэтому вы получите код C ++ с сахарным покрытием C #, и у вас все еще могут остаться нерешенные проблемы с Unicode / 64-битами. Это действительно требует очень и очень тщательного планирования.

Я был вовлечен в проект очень похожего размера. Из-за нового оборудования и новых требований пришлось переписать интерфейс GUI. Мы решили перенести это на .NET с помощью C ++ / CLI. Нам удалось повторно использовать более половины кода, и перенос работает неплохо.

Мы смогли воспользоваться преимуществами .NET там, где это было наиболее целесообразно. Это сделало большую часть кода намного чище. Мы нашли книгу Стивена Р. Г. Фрейзера «Pro Visual C ++ / CLI и платформа .NET 2.0» очень полезной.

Вы думали о переносе на C ++. NET? Это могло быть менее болезненно.

Сейчас я переписываю довольно большое веб-приложение.

Следует помнить, что при преобразовании с одного языка на другой, особенно с C ++ на .Net, вы можете получить меньше и, вероятно, более чистый код из-за языковых достижений или кода фреймворка.

Это одно из преимуществ для будущей ремонтопригодности, даже если не считать возможности заново спроектировать менее надежные аспекты старого приложения.

Некоторые дополнительные комментарии.

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

Простой перевод приложения на новый язык не принесет больших результатов. Возможно, вы захотите также переделать приложение! Не стоит недооценивать усилия, необходимые для этого. Я предполагаю, что усилия по редизайну + переписыванию могут составить до 50% усилий по исходной реализации. (Конечно, 50% - это абсолютно ненаучное предположение).

Это способ легко обмануть себя, думая: «Ну, C # и WPF настолько продуктивны, что переписать этот беспорядок было бы проще простого!»

Что интересно, большинство ответов людей, которые это сделали, кажутся положительными. Самая важная вещь IMO - это иметь хорошие модульные тесты, чтобы вы могли быть уверены, что ваша перезапись делает то, что вы хотите (что может быть не совсем таким, как то, что делал старый код).