Делал сегодня странное. На проде прокидывал метрики поискового движка через дотнетный сервис.
И это не моя прихоть – движок (meilisearch) закрывает эндпоинт metrics авторизацией и у нашей инфраструктуры пока что нет инструментов подпихивать в сборщики auth-токены для такого дела.
😠 Проблема
Если делаешь вынужденное ебанутое решение, то через годы забываешь, зачем вообще ты такое делал. И когда тебя спрашивают, то потупленно смотришь на свои тапочки и думаешь что-то вроде “Так, а и правда, зачем?”
Потом конечно вспоминаешь, но все же.
Так вот от такой штуки может спасти практика ведения Arhitecture Deceision Records или ADR
🤓 Решение
Короткая записка в папочке adr и в формате md (к примеру adr/adr-002.md в пояснительном дикпике выше показано как это выглядит) спасет вас от любой напасти!
Я про эту практику слышал лет пять назад, но внедрять не приходилось. А тут говорили вчера с нашим ЕМом Женей Васильевым и он вот предложил вести. А я быстро согласился и уже сегодня мне эта штука пригодилась!
Формат очень простой вот шаблончик:
# Заголовок:
Название документа должно быть короткой именной фразой, например, «Развертывание на Ruby on Rails 3.0.10» или «LDAP для многопользовательской интеграции».
## Контекст:
Этот раздел описывает действующие силы (технологические, политические, социальные и локальные для проекта), которые, вероятно, находятся в противоречии друг с другом. Язык должен быть нейтральным, просто описывая факты.
## Решение:
Здесь описывается наш ответ на перечисленные силы, излагаемый полными предложениями в активном залоге («Мы будем …»).
## Статус:
Решение может быть в статусе:
1. Предложено – если ещё не согласовано всеми заинтересованными сторонами
2. Принято – когда оно согласовано
3. Устарело – если позднее ADR изменяет или отменяет решение
4. Заменено – с указанием ссылки на новое решение
## Последствия:
В этом разделе описывается итоговый контекст после принятия решения. Здесь должны быть перечислены все последствия – положительные, отрицательные и нейтральные, так как они влияют на будущую работу команды и проекта.
🅰️ Итого: Если приходится делать ебанутые вещи, то попробуйте залогировать это в вышеприведенном формате. Быстро и потом голова болеть не будет у того, кто все это будет поддерживать. Ну точнее болеть будет, но вас он уже не сможет наругать.
И кстати, это вообще универсальный метод и мобильщикам подойдет! 📞
Оффтоп: Кстати, посмотрите офигенный доклад Жени про Тестирование сервиса через API. Давно считаю эту практику одной из мастхэвных и мне кажется, что она есть уже у всех. Но если у вас нет, то вам точно будет полезно!