Параллельная разработка на Java и C # - PullRequest
2 голосов
/ 20 февраля 2009

Я поддерживаю два очень похожих планировщика - один на Java и один на C #. Версия C # была изначально создана с использованием JLCA, а затем изменена вручную. Версия Java была значительно изменена за последние несколько недель кем-то другим (поэтому я должен отследить его изменения), и я задаюсь вопросом, следует ли преобразовать ее с помощью одного из инструментов, доступных в Интернете, или просто попробовать вносить изменения вручную каждый раз, когда возникает необходимость. Эта проблема может часто возникать для меня - есть ли способ поддерживать версии программного обеспечения на двух разных языках и держать их в шаге настолько безболезненно, насколько это возможно ?! Предложения будут оценены!

Ответы [ 5 ]

2 голосов
/ 20 февраля 2009

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

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

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

2 голосов
/ 20 февраля 2009

Я не уверен, если это даже вариант для вас, но вы можете подумать о разработке на Java, а затем преобразовать файлы JAR в сборки .NET с помощью IKVM . Я не использовал его в течение нескольких лет, но тогда он работал довольно хорошо.

1 голос
/ 20 февраля 2009

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

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

0 голосов
/ 20 февраля 2009

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

0 голосов
/ 20 февраля 2009

Рассматривали ли вы J #?

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

Помните, что J # устарел и больше не доступен в VS 2008 (вам понадобится старая копия Visual Studio 2005), однако, в зависимости от сложности вашего проекта, это может быть работоспособным решением.

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