51 подписчик
Вчера делал рефакторинг в Планфиксе
Рефакторинг — это процесс, в рамках которого вы исправляете какие-то прежние ошибки или вносите изменения, которые ничего нового не сделают, станет удобнее работать.
У меня возникла задача, что дата оплаты счета должна меняться более гибко и быстро. Это связано с нюансами курса валюты и нашими рисками при работе с иностранцами. В случае необходимости, тратится много времени администратора аккаунта, чтобы все поправить.
Оказалось, что дата в счете устанавливается в десятке разных мест (почтовые правила, сценарии), а устанавливается в “Дата завершения”, которая в свою очередь подвержена изменениям Надзадачи или в связанном аккаунте.
Сложно еще в том, что изменение происходит в потоке прочих изменений в сценарии, это связанные действия.
Что сделал?
1. У нас уже есть поле “Срок оплаты до”, ввел его в шаблон задачи.
2. Пока пошла переиндексация нескольких тысяч задач, сделал версию контроллирующего сценария на дату завершения и он начал нажимать кнопку процесса. А кнопка ставила значение полю “Срок оплаты до” и “Дата завершения”, потому что пока индексация не завершена, должно работать в оба варианта;
3. По всем сценариям и почтовым правилам прошелся, поставил нажатие кнопки самым первым действием;
4. Протестировал, вроде ок.
5. Уведомил свою команду, что появилось новое поле и на что оно влияет;
6. Уведомил контрагентов, что были такие правки и могут быть проблемы, пусть сообщают, если что.
7. Начал в голове думать, как бы еще зарефакторить остальное, ведь десяток почтовых правил тоже во много повторяется и в случае правок может оказаться неудобно это разгребать.
8. Создал 3 фильтра задач:
- шаблоны не содержат еще поля (смотрел скорость)
- шаблоны содержат поле, но не содержат в нем значения (начал устанавливать массовым изменением “Срок оплаты до” из “Дата завершения”)
- шаблоны содержат, но нет “Дата завершения” (массовое действие уже из другой даты пошло)
9. Дождался всех изменений, проверил пустоту фильтров, удалил их.
10. Прошел по всем шаблонам счетов (около десятка), причастных к биллингу, поменял там переменную;
12. Кнопку сделал невидимой, чтобы не мешала людям;
13. Вспомнил про асинхронность, добавил в сложный сценарий контроля всех параметров, чтобы еще одно поле проверял на наличие значения в новом. Таких оказалось два сценария (РФ и РБ)
Трудоемкость работы с 5к задач: 1,5 часа с небольшими отвлечениями
И это все манипуляции только ради одного поля. Делал архитектор этой системы, зануда в таких вопросах, знающий все нюансы. А значит, что любой другой человек потратит еще время на:
- анализ задач и их логов
- анализ сценариев, которые задействованы
- задаст уточняющие вопросы
- попробует на паре задач, потестирует, перестрахуется
- начнет пробовать раскатывать изменения
Я думаю, что трудоемкость будет до 3 раз выше, потому что изменение серьезное, пугающее, требует аккуратности.
Но, если знать алгоритм работы выше, то проблем будет минимум, потому что есть подстраховка дублирующихся данных.
2 минуты
11 апреля 2023