Russian Qt Forum

 Наверное, правильный ответ - "Да крутись оно все конем!"
 Но идеал наталкивается на реальность. А реальность в том, что никакого ТЗ нет и быть не может. Если, конечно, не считать за ТЗ уже с грехом пополам работающую программу, которую надо сделать "еще лучше".
 Я знаю про метафору, что вносить изменения в уже распространяемую программу то же, что делать внутриполостную операцию на бегущем человеке. Но поверьте, другого выхода у нас не было. Или я его не смог найти. Моя вина.
 Но что случилось, то случилось. Как поет нестареющая звезда нашей эстрады, "фарш невозможно провернуть назад".
 Короче, использовать работающую программу как образец для подражания совершенно невозможно. Там тьма решений, вызванных просто моей неумелостью, заплаточностью сиюминутных потребностей и просто неправильным интерфейсом.
 То есть интерфейс надо менять кардинально. А вот этого-то мой консервативный и многоголовый заказчик не хочет.
 И мне остается только исподволь предлагать ему другой. Оставляя ему возможность "жить по-старому". И игнорировать все его хотелки к старому варианту. Фактически прекратить поддержку старого проекта за исключением явных моих ляпов. Которые, увы! есть и будут.

Хорошо такое читать перед сном, сразу вырубает

Краткий ответ: НЕТ, такое решение в корне ошибочно. Подробности

Название топика хорошее, но содержание стартового поста уж чересчур эмоционально. Право, не стоит посыпать голову пеплом типа "Ах, не предусмотрел(и)! Моя вина!" и.т.п. Ситуевина совершенно стандартная: есть старое (древнее, замшелое и.т.п.) но работающее приложение, вот надо перевести его на Qt. Конечно задача большая и непростая, такие не каждый день возникают, но это отнюдь не редкость.

Ага, и документации нет (в лучшем случае огрызки). И содержание "W-приложения" Вы хорошо себе представляете процентов так на 30% (если не меньше, дальше смутно). Это нормально, в такой ситуации я был. Вот некоторые ошибки которые я сделал (хотя чужой опыт редко учит)

1) Не пытайтесь нанять "Qt спеца". Да, есть немало людей хорошо владеющих Qt, но здесь не это  главное - гораздо важнее знать/понимать портируемое приложение, а вот этим (кроме Вас) никто заниматься не будет.

2) Не "хватайтесь за окно". Увидев старенькую часть UI в голову моментально приходят мысли типа "Да на Qt это же как 2 пальца об асфальт! А можно и намного лучше - и легко!". Но беда в том что Qt-приложения-то у Вас нет и куда приткнуть новое окно - хз. А "сборная солянка" быстро задолбает.

3) "Та ну его нафиг! Возиться с этим калом мамонта! Переписать все с нуля - и все дела".  Именно такие резвые советы даются чаще всего - ведь дающий их сам-то в W-приложение не полезет. Здесь уместно вспомнить библию (не ручаюсь за точность цитаты)
Святая правда, повторить весь имеющийся ф-ционал "с нуля" возможно только если он "достаточно мал", тогда можно просто портировать "в лоб". Но чаще эта радость недоступна.

Так, ну пока хватит, надо и другим дать высказаться.

Да. Для меня это очевидно.

Вообще, у меня такое ощущение, что вы мои проблемы очень хорошо понимаете. Видно, что и сами были в похожей ситуации. Ну и как? Выкарабкались?:)

Вопрос не в тему. Как вам удается цитировать часть поста с указанием авторства? У меня получается или цитирование всего поста (кнопка "цитировать") или я просто копипастю эту часть и окружаю ее "квотами".

Вы сразу и ответили на свой вопрос :).

Можно поинтересоваться: в каком году зародилась эта WinAPI-программа?

И для дальнейшего размышления: почему именно в Qt? Не появится ли через 3-5 лет тема: "Стоит ли переводить код из старых Qt-программ "потихонечку" в SomeOtherFramework"? :)

Приходилось заниматься подобным портированием.
Как правильно говорит Igors, лучшее и правильное решение будет - "переписать всё".
При этом выправляя (или меняя) архитектуру и концепты. Была мажорная версия 5.X.Y (без Qt), станет 6.0.0 (с Qt).

В принципе, при наличии (бес)конечности времени и желания, я бы начинал с MVP - Minimum Viable Product.
Т.е. решение, содержащее поначалу минимум самого нужного функционала, но с правильной архитектурой и идеями.
Скорее всего, у Вас есть такой функционал в старом приложении, но криво сделанный.
Сделайте ровно и на Qt. Тестируйте, показывайте заказчику. Параллельно понемногу доращивайте до 6.1.0, 6.2.0 и т.д.

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

Как-то так.

Конец прошлого тысячелетия. 1997. А до этого еще был ДОС-вариант:)
Я не гонюсь за модой. Просто понравилось. Пришлось по руке. Чего не скажу о том же Бюльдере.
Вообще, к использования новых инструментов прихожу гигантскими скачками. Так что вряд ли через 3-5 лет соблазнюсь неким SomeOtherFramework...:)

Тогда понятно и объяснимо :).


Дело не в моде. Выше Racheengel говорил о выправлении архитектуры. Я к тому, что не надо сильно завязываться на Qt, как сейчас завязано на WinAPI. Если есть возможность, то стоит рассматривать Qt как "один из видов GUI", который впоследствии можно заменить на другой, не переписывая опять всё приложение с нуля.

Делаю. Показываю. Заказчик стоит в позиции "Чем бы дитя не тешилось..." Но эта тропинка протаптывается.
А вот это и впрямь дельный совет. Надо попробывать. Беда в том, что плагинами никогда не занимался. Но думаю, это-то освоить можно. Какие-то вопросы смутно и несформулированно видятся. Но до них, конечно, нужно еще дойти...

Вы говорите о разделение движка и представления? Конечно! В проекте есть довольно весомая вычислительная часть. Написанная на чистом Си. И она остается почти без изменений. И переходит из проекта в проект. И даже "подкармливает" побочные проекты.
Скажу больше. В воздухе давно уже носится идея сделать из десктопного веб-приложение. И там вся математика ровно та же. Только перетранслированная на ОС хостера. Что получилось без особых проблем. А все остальное - фактически это новое гуи. И вот тут попытка привлечения "спецов по сайтостроению" закончилась полным крахом. Легче сделать самому. Что и было начато. Но... Тут меня стало уже немножко не хватать... Хотя в этом направлении у меня развязаны руки. Это должно позиционироваться как новый проект с похожим функционалом, и мы не обязаны повторять всех неудачных решение исходного

По теме нашел почитать "Эффективная работа с унаследованным кодом" и перечитать "Мифический человеко-месяц" )

Цитирую все и вырезаю ненужное  :)

Ой смотрите. Если заказчик не понимает что портинг занимает по меньшей мере месяцы - не стоит и начинать.

Похоже этой "кусочной" участи никому не избежать, что бы ни советовали :) Она ведь так заманчива! Ну попробуйте, главное почувствовать когда соскочить

Правду сказать - с большим трудом, но удалось нащупать верный путь. Нужно сначала написать эмулятор старого фреймворка на Qt, "поднять" все текущее UI, пусть оно будет точно таким же (в смысле ничего нового),  но будет Qt-приложением. А потом уже расправляться с конкретными окнами и контролами, там уже дело пойдет веселее, а главное - над Вами "не капает", не висит груз перевести ВСЕ", что-то работает по-старинке - ну и ладно. Кстати если у Вас Borland-OWL, то не исключено что такой эмулятор уже кто-то и запостил (не один же я такой умный  :))

Ну раз основная вычислительная часть уже есть и не завязана на GUI, то лучше "с нуля" проектировать и реализовывать новый GUI на Qt.
Если вы углубитесь в Win-реализацию, то просто потеряете кучу времени. Представьте, что вы хотите получить, разбейте это на этапы по важности и реализуйте.
Потратьте время и хорошо продумайте архитектуру, что бы GUI сильно не пересекался с бизнес-логикой, тогда в дальнейшем смена GUI будет проходить безболезненней. Неплохо сразу продумать систему плагинов, расширять такую систему будет проще.

Да понимает он все! Слава Богу, не первый год работаем!
Золотые ваши слова!
Читали еще в прошлом тысячетелетии, и с большим удовольствием. Особенно понравился слоган о 9-ти женщинах, пытающихся выносить ребенка за месяц.:D
В те времена это было откровением. Теперь можно только снисходительно посмеиваться. Особенно чудна идея о "Хирургической Бригаде". Но наверное, там есть еще много чуднОго. И вправду перечитать, что ли?:)
А вот этого мне, боюсь, не осилить. Ибо к этому старому испытываю такое глубокое и стойкое отвращение, что еще и эмулировать его...:)
Да, тот ресурс у нас правда неограничен...:)

Ну это "конечная цель", но как ее достигнуть? Давайте создадим новый Qt проект, нарисуем MainWindow и будем переписывать туда старые окна под Qt? Так, что ли? Если так, то:

- если говорим "портирование", то тем самым утверждаем что "текущий ф-ционал остается неизменным". Сначала должно просто "ходить на Qt", пусть косо, криво, но хоть как-то ходить, т.е. Qt-приложение должно стартовать и окна открываться. Это уже успех. Только после этого можно пересматривать архитектуру и концепты. А попытка проскочить сразу - просто авантюра

- вот было старое приложение, которое постоянно (и наверное заслуженно) ругали. Но теперь его НЕТ. И, хуже того, когда оно опять будет (хотя бы со старым ф-ционалом) - неизвестно, ответить заказчику нечего. И в таком "подвешенном" состоянии будете находиться месяц за месяцем. Вряд ли хорошие новые концепты придут в голову под таким тяжелым прессом. Зачем же было загонять себя в такое положение?

Конечно все эти рассуждения справедливы лишь для "достаточно большого" UI. Если "в лоб" проходит, то и думать нечего, делать в лоб - да и все.

Сначала добиться минимально работоспособного приложения на  qt с минимально нужным функционалом, но с уже чистой архитектурой и кодом. А потом доращивать и делать новые окна.  как то так.

Это может прокатить если "весь старый код - мой", впрочем и то не всегда (недавно обнаружил что НЕ МОГУ портировать собственный плагин начала нулевых). Но чаще бывает что код писался неск авторами, и шансы на "чистую архитектуру" практически нулевые, быстро упремся в устаревшие структуры данных. Рефакторинг и портинг - хотя и связанные, но все-таки разные задачи и смешивать их некорректно.

Ну. смысл портировать без рефакторинга может быть только в 2 случаях:

1. старая архитектура и так хороша.
2. заказчик хочет всё "на вчера" и не готов платить за улучшения.

Пункт 2, однако, опасен. Его стоит выбирать только если 100% уверен, что "быстро взлетит".

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

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

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

Особых угрызений совести не испытываю, так как ругаю-то самого себя.:D Да, вы правы. Чуточку здоровой суеверности в нашем деле не повредит:)

Потихонечку - можно.

Причём я бы начал с отделения мух от котлет. То есть с вынесения вещей, не зависящих от фреймворка, в отдельные места. И тут необязательно заморачиваться с плагинами или DLL, как подсказывали выше. Возможно (в случае C++) - просто в отдельные классы. То есть приведение в порядок на уровне исходного кода.

Чем это хорошо? Тем, что это полезно даже вне зависимости от того, дойдут ли Ваши руки до Qt. Это сделает программу более обозримой, позволит обкладывать её тестами, как угодно, и пр.

Ну а вот как только вынесете всю non-GUI функциональность в отдельные классы - тогда у вас может сразу наступить резкое просветление на тему, тащить ли сюда Qt. Причём для разных классов программ ответ на этот вопрос неочевиден.

Если (предположим худшее) Ваша программа - это GUI-обёртка над какой-нибудь БД, то увы, перенос на Qt означает практически полное переписывание с нуля. Ну разве что готовые SQL-запросы можно будет перетащить (что, кстати, иногда тоже немало).

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

Обычно в реальных проектах происходит нечто среднее.

P.S. Упс, посмотрел соседнюю тему и понял, что совет запоздал - портирование, как я понял, уже началось, причём не по тому пути, по которому пошёл бы я сам. :(

Уверяю вас, в этом нет ничего страшного. Программист находится в более выигрышном положении, чем Боратырь из сказки. Он может послать своих виртуальных лошадок по всем трем дорогам, а сам в это время стоять у камня и репу чесать.:)
Это в основном уже сделано, и работа в этом направлении продолжается. И что из того, что делается без классов и на старом добром Си. Приемлемого структурирования программ можно добиться и на нем. А инкапсуляция, как и другая "защита от дурака" тут не очень нужна. Ибо этот дурак - я сам. А от него, сами понимаете, защиты нет.:)
Нет, слава Богу, нет. БД там, конечно, есть. Но она чисто моя, самопальная. И уже вполне удачно перенесена в диалоговую часть, которую таки удалось сделать на Qt. С этим-то я справился. Но сейчас меня интересует встраивание окон-результатов. Ибо некоторые из этих окон просто просятся. А некоторые - еще не просятся. Вот оттуда-то и идея этого кентавра. Но, как известно, "в местах перехода чудища особенно уязвимы" (Апдайк):)