Элегантный способ обработки подобного кода
У меня есть программный проект, который работает просто отлично.
Теперь этот проект необходимо скорректировать, чтобы смоделировать новую, но связанную систему.
Какие существуют стратегии, чтобы эти два кода были хорошо организованы?
Они будут иметь кодовую базу примерно на 90% одинаковую, но есть много функций, которые требуют небольшой корректировки.
Я думал о следующем:
- Различные ветки в git-репозитории: идеальный контроль над двумя проектами, но общие изменения должны быть сделаны в каждой ветке отдельно.
- Моделирование различных режимов программы с помощью прагм C ++ (#ifdef Project1 …):
это сохраняет изменения локальными, но затрудняет чтение кода.
Я не слишком удовлетворен этими решениями. Есть ли лучший подход?
Решение
У нас та же проблема, и вот как мы ее решаем:
- У нас есть только одна ветка на нашем репозитории Git
- Помимо обычных файлов, у нас есть разные файлы в зависимости от конфигурации: access_for_config1.cpp, access_for_config2.cpp, …
- Мы используем шаблон дизайна лайк завод абстрагировать конкретную часть от общей части
- Для небольших очень специфических частей в общих файлах у нас есть
#ifdefраздел в соответствии с конфигурацией - У нас есть разные правила в нашем make-файле для каждой конфигурации: для конфигурации мы компилируем общий файл + определенный файл и устанавливаем правильный флаг. Кроме того, используя eclipse в офисе, мы также определяем различные конфигурации сборки, чтобы обеспечить правильное выделение.
Преимущество этого подхода состоит в том, чтобы поддерживать общую часть всегда синхронной, и мы правильно изолируем каждую конкретную часть.
Но вы должны быть осторожны с не очень далеким фрагментом кода из каждой конфигурации. Например, при использовании аналогичного (но не одинакового) кода в разных конкретных файлах возможная ошибка может быть исправлена только в одной конфигурации. Его можно уменьшить, определив какой-то фрагмент кода в качестве общего шаблона или переосмыслив дизайн, чтобы поместить некоторую часть в общий
Надеюсь, что ответ поможет вам
Другие решения
Какие существуют стратегии, чтобы эти два кода были хорошо организованы? У них будет кодовая база примерно на 90%
Это не совсем то, что вам нужно, но просто убедитесь, что вы знаете об этом.
Submodulesразрешить встраивание сторонних репозиториев в отдельный подкаталог исходного дерева, всегда указывает на конкретный коммит.
Различные ветки в git-репозитории: идеальный контроль над двумя проектами, но общие изменения должны быть сделаны в каждой ветке отдельно.
Вы можете зафиксировать изменения в одной ветви, а затем использовать cherry-pick, чтобы добавить их в любую другую нужную ветку.
detector