Когда-нибудь сделанный общее количество переписывают большого приложения C++ в C#? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, есть две ошибки, которые вы не должны делать:

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

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

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

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

В настоящее время я переписываю довольно большое веб-приложение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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