В рамках процесса судопроизводства по кредиту может приходить несколько десятков видов писем: от судебного приказа из суда до квитанции об оплате долга от клиента. Поэтому на старте проекта была сделана возможность через админ-панель добавлять в виде шаблонов новые типы писем с любыми наборами полей и редактировать текущие.
Со временем бизнесу понадобилось, чтобы система автоматически реагировала на регистрацию определенного типа письма. Например, если в системе регистрируется письмо с судебным приказом, система должна автоматически к сумме основного долга прибавлять сумму госпошлины. Подобные реакции системы сложно запрограммировать, когда письмо полностью хранится в базе данных, и нет никакой связи с кодом.
Нам нужно было связать письмо из базы данных с кодом, чтобы при его регистрации запускать нужные процессы. Есть простой путь – скорее временное решение: при настройке шаблона письма в админ-панели выбирать функциональность, которая будет запускаться при регистрации письма.
Например, для шаблона письма «Судебный приказ» выбирать запуск функциональности «Начисление государственной пошлины». Это «костыль», ведь если пользователи системы случайно уберут запуск функциональности из настроек письма, то система сломается.
Правильный путь – разобраться с бизнесовой частью и узнать, как «работают» эти письма: как часто появляются новые типы писем, как часто меняется состав вносимых в систему данных, нужно ли при добавлении нового письма или изменении текущего сразу же менять реакцию системы на письмо. После этого можно будет отрефакторить функциональность регистрации входящих писем.
Например, убрать возможность добавления/редактирования писем через админ-панель и перенести все типы писем в код. Тогда реакции системы при регистрации определенных типов писем будут работать «правильно». Также можно будет добавить эффективную валидацию внесенных данных при регистрации письма.
Такие решения и нужны продукту.
Легко ли переписать продукт с нуля Нет. Как минимум потому, что на это потребуется вдвое-втрое больше времени (и денег), чем ушло на первоначальную версию. В нашей практике был подобный случай.
Смотря что. Работал в одной крупной известной всем компании, там регулярно переписывали компоненты с нуля и достаточно успешно. Просто в процессе выясняется, что что-то можно смело выбросить, а что-то воткнуть в новую архитектуру большим куском, если подстелить соломку.
Тут соглашусь. Часто время и усилия, необходимые на рефактор как отдельных компонентов, так и проекта в целом, зависят от того, как регулярно обновляется кодовая база и как качественно написан продукт.
Круто, когда можно переписывать отдельные компоненты. Но проект может быть монолитом и тогда есть два пути: переписать его полностью за один присест, либо отделять от него кусочки (микросервисы), написанные с нуля. Второй способ очень популярный, но и у него есть существенные минусы:
1) Отделение от монолита кусочков занимает очень большое время, и переход от монолита к микросервисам растягивается на годы.
2) Если у вас сервис, который постоянно изменяется в силу внешних причин или конкуренции на рынке, то долгое время придется активно дорабатывать большой ком грязи через боль и слезы :)
Поэтому, как нам кажется, по возможности все равно лучше не доводить до ситуации, когда нужно полностью переписать проект :)
Кучу денег на продукт может не потратите, но зато потратите на другое
ну и классно же, деньги они для того чтобы их тратить :)