Как приспособить программу к многочисленным изменениям?

Question

[Crunkor]

Представьте ситуацию, что программа работает правильно и всех она устраивает. В программу поступают каждый день данные и они успешно сохраняются в БД.
В один прекрасный день появляется указание о том, что методы, которые отвечают за обработку и загрузку данных в БД нужно переделать. Программа успешно переделывается. Но теперь возникает необходимость загрузки данных по старому формату. Как быть в такой ситуации? Таких изменений может быть много.
Я вижу тут следующие варианты решения задачи...
1. Хранить отдельную ветку на гитхабе со старым методом. В таком случае в этой старой ветке не будет новых фич.
2. Создавать несколько методов с условными названиями "Загрузка Январь", "Загрузка Март", "Текущая загрузка".

Подскажите какие-нибудь best practices в этом вопросе.

Answer 1

[Евгений Мамонов]

Если я верно понял задачу, то у вас база в одном формате, а данные приходят в разных.
Если это так, тогда вам нужно просто сделать 3 класса:
1 - преобразовывает данные в формате 1 во внутреннюю структуру (пригодную для сохранения в базу)
2 - преобразовывает данные в формате Х во внутреннюю структуру
3 - сохраняет данные из внутренней структуры в базу
Это стандартная практика для подобных задач.
Если вам будет нужно сохранять данные не в базу, а куда то еще, например в облако - вы просто добавите еще один класс, который умеет сохранять данные в нужном формате/на облако.

Comments

[Алексей Черемисин]

Дополню в ответу.
Это шаблон проектирования - Адаптер. Вот https://ru.wikipedia.org/wiki/%D0%90%D0%B4%D0%B0%D...
и вот https://refactoring.guru/ru/design-patterns/adapte...
и вот - https://dzone.com/articles/adapter-design-pattern-...
и так можно - https://www.tutorialspoint.com/design_pattern/adap...

Answer 2

[nApoBo3]

Версионость api. Обеспечивается может разными методами. Если старое api будет поддерживаться не ограниченное время, а анализ должен быть сквозным, то данные на слое ниже нужно сводить в один формат.

Answer 3

[Sergey Shvyrev]

Работал, как то на одном жирном клиенте. Была подобная ситуация. Даже сложнее. Паттерн стратегия определял тип инстанцируемого приложения.
Фич было очень много и некоторые деградировали периодически. Выбрали ворклоу - GitFlow. С нашими целями справлялся.

Рекомендую. Но не навязываю.

Вы уже определились хранением версий в гите. Осталось выбрать workflow. Предлагаю прочитать сравнение от Atlassian : link
Выберете, что более подходит для ваших целей.

Спасибо.