Как отслеживать изменения логики работы кода в сторонних модулях? Сначала довольно длинное введение, чтобы было понятно, в чем проблема.
Есть сайт, на котором размещаются текстовые материалы в виде статей. Статья — это просто заголовок, текст и id (slug). Есть панель управления для создания, редактирования и удаления статей. Управление статьями вынесено в отдельный модуль, который делается внешними разработчиками.
Модуль статей подключается к сайту (основному приложению), и на события этого модуля можно вешать обработчики. Например, чтобы при добавлении статьи автоматически обновились карта сайта, поисковый индекс и т.п.
Когда-то давно добавился функционал оповещения всех пользователей сайта при добавлении новой статьи. Как только в админке добавляется новая статья — модуль статей испускает определенное событие (article_create). Код основного сайта, подписанный на это событие, запускает рассылку оповещений всем пользователям о том, что вышла новая статья (например, по e-mail или через браузерные уведомления).
Все это работало долго и хорошо, и вот однажды в модуле статей добавился новый функционал: у статей появился флаг is_published "опубликовано/скрыто" (по умолчанию — опубликовано). Теперь статью можно сначала создать в виде черновика, который не виден пользователям, а позже отредактировать и опубликовать.
Однако в коде основного сайта никаких изменений сделано не было (тупо забыли за давностью). Тесты модуля корректно прошли. Тесты основного приложения — тоже. И стала возможной ситуация, когда статья создается, событие article_create испускается, но флаг is_published у этой статьи равен false, а о такой статье никого уведомлять не нужно. Однако код, подписанный на это событие, не поменяли, и в результате пользователям разослалось уведомление о статье-черновике.
То есть очевидно, что возникла несогласованность логики работы внешнего модуля, где добавился флаг isPublished, и использующего этот модуль кода основного приложения, в котором не было добавлено никаких уточнений логики, связанных с этим флагом.
Собственно вопрос: каким образом, с помощью каких возможных тестов или архитектурных подходов можно было бы определить и предупредить такую проблему? В сторону какой темы копать? Понятно, что это, возможно, сбой коммуникации между разработчиками модуля и основного сайта и промах разработчиков основного сайта. Но есть ли какие-то подходы к программированию, которые покажут, что логика работы внешнего модуля поменялась, а логика работы использующего его приложения — нет?
Как отслеживать изменения логики работы кода в сторонних модулях? Сначала довольно длинное введение, чтобы было понятно, в чем проблема.
Есть сайт, на котором размещаются текстовые материалы в виде статей. Статья — это просто заголовок, текст и id (slug). Есть панель управления для создания, редактирования и удаления статей. Управление статьями вынесено в отдельный модуль, который делается внешними разработчиками.
Модуль статей подключается к сайту (основному приложению), и на события этого модуля можно вешать обработчики. Например, чтобы при добавлении статьи автоматически обновились карта сайта, поисковый индекс и т.п.
Когда-то давно добавился функционал оповещения всех пользователей сайта при добавлении новой статьи. Как только в админке добавляется новая статья — модуль статей испускает определенное событие (article_create). Код основного сайта, подписанный на это событие, запускает рассылку оповещений всем пользователям о том, что вышла новая статья (например, по e-mail или через браузерные уведомления).
Все это работало долго и хорошо, и вот однажды в модуле статей добавился новый функционал: у статей появился флаг is_published "опубликовано/скрыто" (по умолчанию — опубликовано). Теперь статью можно сначала создать в виде черновика, который не виден пользователям, а позже отредактировать и опубликовать.
Однако в коде основного сайта никаких изменений сделано не было (тупо забыли за давностью). Тесты модуля корректно прошли. Тесты основного приложения — тоже. И стала возможной ситуация, когда статья создается, событие article_create испускается, но флаг is_published у этой статьи равен false, а о такой статье никого уведомлять не нужно. Однако код, подписанный на это событие, не поменяли, и в результате пользователям разослалось уведомление о статье-черновике.
То есть очевидно, что возникла несогласованность логики работы внешнего модуля, где добавился флаг isPublished, и использующего этот модуль кода основного приложения, в котором не было добавлено никаких уточнений логики, связанных с этим флагом.
Собственно вопрос: каким образом, с помощью каких возможных тестов или архитектурных подходов можно было бы определить и предупредить такую проблему? В сторону какой темы копать? Понятно, что это, возможно, сбой коммуникации между разработчиками модуля и основного сайта и промах разработчиков основного сайта. Но есть ли какие-то подходы к программированию, которые покажут, что логика работы внешнего модуля поменялась, а логика работы использующего его приложения — нет?
Есть сайт, на котором размещаются текстовые материалы в виде статей. Статья — это просто заголовок, текст и id (slug). Есть панель управления для создания, редактирования и удаления статей. Управление статьями вынесено в отдельный модуль, который делается внешними разработчиками.
Модуль статей подключается к сайту (основному приложению), и на события этого модуля можно вешать обработчики. Например, чтобы при добавлении статьи автоматически обновились карта сайта, поисковый индекс и т.п.
Когда-то давно добавился функционал оповещения всех пользователей сайта при добавлении новой статьи. Как только в админке добавляется новая статья — модуль статей испускает определенное событие (article_create). Код основного сайта, подписанный на это событие, запускает рассылку оповещений всем пользователям о том, что вышла новая статья (например, по e-mail или через браузерные уведомления).
Все это работало долго и хорошо, и вот однажды в модуле статей добавился новый функционал: у статей появился флаг is_published "опубликовано/скрыто" (по умолчанию — опубликовано). Теперь статью можно сначала создать в виде черновика, который не виден пользователям, а позже отредактировать и опубликовать.
Однако в коде основного сайта никаких изменений сделано не было (тупо забыли за давностью). Тесты модуля корректно прошли. Тесты основного приложения — тоже. И стала возможной ситуация, когда статья создается, событие article_create испускается, но флаг is_published у этой статьи равен false, а о такой статье никого уведомлять не нужно. Однако код, подписанный на это событие, не поменяли, и в результате пользователям разослалось уведомление о статье-черновике.
То есть очевидно, что возникла несогласованность логики работы внешнего модуля, где добавился флаг isPublished, и использующего этот модуль кода основного приложения, в котором не было добавлено никаких уточнений логики, связанных с этим флагом.
Собственно вопрос: каким образом, с помощью каких возможных тестов или архитектурных подходов можно было бы определить и предупредить такую проблему? В сторону какой темы копать? Понятно, что это, возможно, сбой коммуникации между разработчиками модуля и основного сайта и промах разработчиков основного сайта. Но есть ли какие-то подходы к программированию, которые покажут, что логика работы внешнего модуля поменялась, а логика работы использующего его приложения — нет?
Похожие вопросы
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Для предотвращения подобных проблем в будущем, можно применить следующие подходы:
Автоматизированные тесты: необходимо включить в набор тестов проверку всех возможных состояний статьи, включая состояние is_published. Также стоит проверить, что все события, вызываемые модулем статей, обрабатываются корректно.
Интеграционное тестирование: создать тестовое окружение, в котором можно протестировать взаимодействие модуля статей с основным приложением. Это позволит выявить проблемы в логике работы кода до того, как они окажутся на боевом сервере.
Тесное взаимодействие между разработчиками: важно, чтобы команда, работающая над внешним модулем, была в постоянном контакте с разработчиками основного приложения. Это позволит избежать ситуаций, когда логика работы различных компонентов не согласуется.
Использование контроля версий: следить за изменениями в коде модуля статей и основного приложения с помощью систем контроля версий, таких как Git. Это поможет отслеживать, какие изменения были внесены в код и кто их сделал.
С учетом вышеперечисленных подходов и практик правильного программирования, можно уменьшить риск возникновения несогласованности логики работы различных компонентов приложения и предупредить подобные проблемы.