Эта заметка открывает серию постов [DC] - Delphi And C++. В [DC] я буду сравнивать Delphi и С++(Qt). Синтаксис, типы данных, алгоритмы, классы, паттерны, gui, все что можно сравнить в рамках здравого смысла.
Мне не раз встречались задачи по переносу приложений или кусков кода с С/C++ на Delphi. Обратное встречается реже, но тоже не исключено. Проблему переноса кода с одного языка на другой можно решать по-разному. Можно переписать "в лоб". Можно портировать, изменив архитектуру проекта или заменив языковые средства, на более подходящие/удобные/любимые в новой среде.
Универсального способа нет и никогда не будет. Все упирается в программиста, его знания, владение языками, понимание принятых парадигм программирования, особенностей стиля. Сроки тоже не резиновые. Каждый решает за себя сам.
Параллельный перенос. Оба языка очень мощные и имеют обширный арсенал языковых средств и конструкций, который пересекается на процентов на 80. Конечно, цифра субъективная, но она отражает процент кода, который я переносил без особых шаманств. Простое переписывание кода в идентичных языковых конструкциях не делает его удобнее в новой среде, зато несет минимальный груз ошибок. Если нужно просто перетащить код, протестировать и забыть о нем - переписывание "в лоб" вполне уместно. Когда речь идет о трансляции заголовочных файлов библиотек, это вообще единственный вариант. Хотя и в нем встречаются подводные камни.
Портирование. С другой стороны встает вопрос об эффективности кода и удобстве его дальнейшей поддержки. Что удобно в С++ не всегда удобно в Delphi. Говоря об удобстве, я имею ввиду личные предпочтения программиста. Это напрямую отражается на скорости и качестве работы программиста. Мне гораздо приятнее работать в "своем стиле", чем кусать колючий кактус, портируя приложение с кривой (на мой взгляд) архитектурой. Этот способ хорошо работает на небольших проектах, где можно быстро и полно оценить архитектуру готового решения.
Гибрид. Крупный или непонятный проект. Крупный и непонятный, это вообще алис. Самый запущенный и трудоемкий случай. Тут придется идти в несколько этапов. Порядок произвольный, но лучше этот:
- перенос максимального количества кода с минимальными изменениями
- постепенное осознание архитектуры приложения целиком, очень редко бывают модульные приложения, которые можно портировать частями
- перенос оставшегося кода в любом виде, главное что бы работало
- тестирование всей системы целиком
- плавное и постепенное изменение кода и архитектуры под себя
- тестирование после каждого значимого шага
Перенос и портирование приложений задача творческая, что во многом обусловлено "буйством красок и полетом фантазии" разработчиков первичного продукта. Это делает перенос "в лоб" сложным, а порой и просто невозможным. Портирование и перенос приложений это крайняя мера, к которой лучше не прибегать. Порой проще разобраться в предметной области самому и написать грамотное приложение, чем убить кучу времени и в результате не портировать очередной "шедевр".
Комментариев нет:
Отправить комментарий