Перенос "функционального блока" из отладочного проекта в рабочий. Поделитесь боевыми решениями.

[sunjob]

день добрый.

опишу ситуацию, ну а вы там... по ситуации.. :о)

задача: в рабочий проект нужно добавить "некий функционал", который еще не написан/не отработан.

что я делаю? правильно - создаю отладочный проект и в нем пишу/настраиваю/отлаживаю этот "функционал".

в результате "решение" обрастает неким рабочим окружением, состоящим из "объектов" (функции, обработчики, lcl компоненты/объекты, итд).
и все это составляет "тот функционал", который и требуется.

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

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

вопрос/тема: как поступают боевые перцы в таком случае? поделитесь опытом.

спасибо.

исходные:

- linux x64
- fpc-3.2.2
- lazarus-3.8.0/4.4.0

[Lucifer]

Git. Создаешь ветку и работаешь в ней. Закончил и отладил - делаешь слияние. Нафига такие сложности с тестовыми проектами и прочим? Вто чтобы что? Чтоб просто тупо скопипастить не то или не скопипастить нужное?

[slyubez]

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

[RRYTY]

когда набирается некая "критическая масса", то уже как-то не в кайф переносить все в ручную

1. Работоспособность проекта обратно пропорциональна единовременному количеству изменений. Наверно, определить "критическую массу" можно именно так: "количество единовременных изменений однозначно нарушающее работоспособность проекта в целом".
2. Автоматический перенос неизбежно приведет к длительной ручной отладке и, опять же, ручной чистке кода от остатков предыдущих решений.

Совет 1: Повсеместно используйте свои классы и объекты, наращивая их функционал - рабочий проект потом просто компилируется с новыми определениями.
Совет 2. Никогда не доверяйте интерфейсам тестовых проектов, интерфейс всегда отлаживается на том, что будет работать у пользователя.

Git, как и subversion, хороши для работы многих удаленных разработчиков, - используем обе системы, наличие единого maintainer'а каждого проекта не обсуждается и его решение всегда односложно и непререкаемо. Один разработчик с их помощью бесцельно привязывается к интернету и осознанно доверяет платформе, без плюсов по отношению к самостоятельной локальной разработке.

[Alex2013]

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

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

[Alex2013]

Сори, вместо редактирования влезла цитата...
Зы
Народ куда дели удаление случайной копии? Реально же неудобно