Кто-нибудь порекомендует воссоздать НОВЫЕ проекты и повторно добавить источник и почему?

Question

У нас есть большая программная система на основе SQL, которая существует с Delphi 1. Она использует одни и те же исходные файлы проекта во всех своих различных проектах.Недавно мы начали обновление до Delphi XE2, и я обдумывал идею создания НОВЫХ файлов проекта и повторного добавления всех исходных кодов снова - чтобы они получили рекомендуемые значения по умолчанию для нового Delphi.Проект XE2.

Кто-нибудь порекомендует это?И каковы риски?Очевидно, это сложная задача, переопределить номер версии, названия проекта / описание / информацию о компании и т. Д. Но меня пугает размер оригинальных проектов.3 основных исполняемых файла и многие другие, всего около 3 миллионов строк кода.

Основная причина, по которой я думаю об этом, заключается в том, что я видел, как новые проекты Delphi XE2 автоматически создают подпрограммы-каталоги для каждой платформы и выпуска (Win32, Win64, Debug, Release и т. д.).Наши проекты в настоящее время находятся в беспорядке, и я пытаюсь их исправить.

Так что вы скажете по этому поводу?И почему или почему это не хорошая идея?Может ли быть какая-то альтернатива «Сбросить» значения по умолчанию?

Answer 1

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

В настоящее время наши проекты в беспорядке, и я пытался их убрать.

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

Очевидно, что это трудная задача, переопределить номер версии, названия проекта / описание / информация о компании и т. д.

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

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

Основная причина, по которой я думаю об этом, заключается в том, что я видел, как новые проекты Delphi XE2 автоматически создают подкаталоги для каждой платформы и выпуска (Win32, Win64, Debug, Release и т. Д.)

Для этого не нужно заново создавать файл проекта, просто измените Output Directory и Unit Output Directory в параметрах компилятора вашего проекта на следующее:

.\$(Platform)\$(Config)

Answer 2

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

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

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

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

Answer 3

Хотя это и не должно причинять вреда, я не уверен, что вы выиграете много.

Усилия и время, потраченные на такую ​​идею, кажутся рабочим проектом, и я не вижу никакой выгоды в этом.ит.

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