Обратная совместимость при написании кода
Недавно при разработке одного из проектов, наша команда предложила писать новый функционал на новых рельсах (решениях). И нам задали простой вопрос, а как оно будет совместимо со старым функционалом. Так и родилась эта статья.
Рассмотрим классическую схему работы сайта.
Как видно на схеме, мы как пользователи сайта работаем в браузере и общаемся только с FRONT часть сайта. (Да у многих сайтов, BACK и FRONT по сути единая система, но идеологически и функционально они все же отличаются).
В свою очередь ФРОНТ отправляет свои данные на BACK систему, а та в свою очередь, как то обрабатывает эти данные. Причем в 90% случае в просто складывает их в BD.
Как же мы получаем данные? Достаточно просто, мы запрашиваем страницу, фронт (браузер или скрипты) стучится на бэк. Бэк в свою очередь стучится в БД, забирает данные, готовит их и возвращает на фронт часть.
Когда мы поняли, как работает основная схема. Давайте рассмотрим несколько сценариев развития:
Предположим у нас устаревшие технологии и мы хотим обновить всю систему, но переписать все сразу мы не можем. И вот мы выделили кусочек функционала, который вроде как можно писать рядом. У нас получится примерна следующая схема:
В этой схеме кажется все логично, если пользователь запросил раздел новостей, ему ответит приложение 1, а если раздел вопросов и ответов, то приложение 2.
Но что если приложению 1 понадобились данные из приложения 2? В этом случае тоже проблем не будет, до тех пор, пока данные может менять только приложение 1.
Как только у данных становится более чем один управляющий, появляется риск конфликтов.
На примере:
У вас были пользователи и у них были ФИО, телефон, почта. И вот приложение 1 поменяло структуру данных и поле телефон больше не использует! Но приложение 2 не знает об этом и считает, что телефон должен быть. И оно перестает корректно работать.
Из этого делаем вывод, что пока данным управляет 1 элемент - риск конфликтов мал. А значит, выносить в новые решения лучше совершенно новый функционал. Либо только использовать данные, но не управлять ими.
Далее, даже при работе 1 приложения, схема работы остается таже! Иными словами, у вас есть 6 экранов, которые используют ту же сущность человека с телефоном, почтой и ФИО. И вот вы убираете ФИО, на своем экране и удаляете из БД. И еще 5 экранов ломаются!
Вывод: данные надо переносить комплексно ( с доработкой всей системы) или не трогать. За одним исключением, когда вы добавляете данные. В этом случае их ее никто не использует, а значит и ломаться нечему.
