Доброе утро,Код слияния из нескольких папок
Я работаю над устаревшим кодом. Этот старый код состоит из нескольких проектов (язык C с NI LabWindows CVI) и никогда не управлялся в системе управления версиями, но только в папках. Со временем это стало немного грязным, и были созданы копии этой папки и были внесены изменения во все папки в зависимости от проекта, который был построен. В результате есть 5 папок, каждый из которых содержит разные базы кодов, для которых один раз был одним и тем же кодом. Также многие файлы были изменены во всех папках, потому что они используются в нескольких проектах. Каждый проект был построен только из 1 из 5-ти папок (поэтому проект А был создан только в папке 1, проекте b в папке 4 и т. Д.). Это не только сырой код, но и файлы пользовательского интерфейса.
Я надеюсь, что это было ясно до сих пор.
Моя задача состоит в том, чтобы объединить весь код в одну базу кодов (начиная сначально). И я хотел бы получить некоторые предложения.
А вот план: 1. создайте базовую версию одной папки, предположительно, с наибольшим количеством изменений. 2. создать репозиторий GIT для хранения кода и всех изменений 3. Пройти все папки и объединить файлы в базовую версию с помощью программного обеспечения для сравнения файлов. (Папка 1 - базовая линия, слияние папки 2 на базовую линию, слияние папки 3 на базовый уровень и т. Д.)
Есть ли у вас какие-либо комментарии к этому плану? То, что хорошо? Плохо? Есть ли инструменты, которые я могу использовать?
Не делайте никаких предположений о достоверности содержимого в любой из предыдущих папок. Просто потому, что у одного .c файла больше изменений в нем, чем соответствующий .c в другой папке, не означает, что он был реализован лучше, чем другой. Начните с списка потребностей пользователя или, если они доступны, оригинальные спецификации, на которые было написано программное обеспечение. Затем начните с чистого листа, особенно с файлами UIR. (сбрасывать старые и создавать свои собственные). CVI известен совместимостью UIR между версиями. Если вы нашли, что старые .c/.h были хорошо написаны, извлеките отрывки из них, но начните чистку – ryyker
Вы правы в предположениях. не являются оригинальными спецификациями, потому что это программное обеспечение было разработано «на лету» и широко модифицировано с любой документацией по требованию или документацией по изменению. Иногда, когда мне повезет, код документирован или содержит отметку даты/времени.Когда-то, когда мне не повезло, эти данные/метки времени полностью устарели. В основном, что вы говорите, это повторить все? (или большинство из них). Похоже, это вызовет настоящую проблему, потому что все неписанные требования, разработанные на протяжении многих лет, трудно извлечь из кода. – TriceratopsMagician
Если вам нужно повторить это, будьте тверды, чтобы начать с набора производных требований перед началом реализации в новой версии. В какой-то мере новые требования могут быть получены из обратной инженерии, которую вы будете делать при оценке исходного кода и отчуждении того, что именно оно было создано. Кроме того, проконсультируйтесь с другими заинтересованными сторонами (пользователями) программного обеспечения, чтобы узнать, какие недостатки функции существуют, и добавьте их в требования. Откажитесь от своих функций, они не вносят вклад в цели программного обеспечения, но включают их в дизайн, если они это делают. – ryyker