Ёмко сказано. Такой же подход в команде: обсуждаем задачи, планируем вместе, какие-то задачи в любом случае приходиться забирать на себя. Убрать сеньора - получится голый менеджер с вопросами "когда будет готово и сколько осталось ещё сделать?".
Спасибо за идею, логично выглядит. Лишних настроек нет в классе. Вроде как в последних версиях pydantic появилась. Внешнего немного сложно и громоздко получается за счёт префиксов. Используем такой способ для передачи структур, но что-то для ограничения видимости настроек не догадались применить.
Да, все настройки приложения в Settings. По логгеру можно и без DI обойтись тем более, как правильно заметили, никто его заменять не будет. Даже в тестах )) Сделано в одном стиле.
По интригующей теме работы с госами, наверное, не скажу ничего, потому как более интересной была бы реализация через СМЭВ. Однако здесь рассмотрен пример сервиса, работающего через очереди, построенный, да, как вы сказали, на устаревших базвордах луковичной архитектуры и контейнеров. Тема получения ИНН скорее второстепенна в статье. Это лишь полезная нагрузка для построения сервиса, некая абстрактная задача, которую можно развивать и на чём можно учиться.
Согласен с отсутствием нефункциональных требований и метрик качества. Сформулировать сейчас не получится, но в одном из разделов указал на скорость ответа базового сервиса от налоговой. При "развитии" сервиса попытаемся сформулировать и эти требования.
Про тесты написано в последнем разделе. Предвосхищая ваш вопрос почему сначала не пишем тесты, а потом код - так не было запроса на следование TDD.
Самый эпичный провал был месяц назад с Django, настраивая фоновую задачу в селери без указания времени только лишь с днём. В итоге за час запустилась прорва задач и упал прод. Сознался без проблем, санкций не было. Профит в том, что добавили метрики к менеджеру очередей.
Ёмко сказано. Такой же подход в команде: обсуждаем задачи, планируем вместе, какие-то задачи в любом случае приходиться забирать на себя. Убрать сеньора - получится голый менеджер с вопросами "когда будет готово и сколько осталось ещё сделать?".
Спасибо за идею, логично выглядит. Лишних настроек нет в классе. Вроде как в последних версиях pydantic появилась. Внешнего немного сложно и громоздко получается за счёт префиксов. Используем такой способ для передачи структур, но что-то для ограничения видимости настроек не догадались применить.
Да, все настройки приложения в Settings. По логгеру можно и без DI обойтись тем более, как правильно заметили, никто его заменять не будет. Даже в тестах )) Сделано в одном стиле.
Спасибо за первый комментарий к первой статье.
По интригующей теме работы с госами, наверное, не скажу ничего, потому как более интересной была бы реализация через СМЭВ. Однако здесь рассмотрен пример сервиса, работающего через очереди, построенный, да, как вы сказали, на устаревших базвордах луковичной архитектуры и контейнеров. Тема получения ИНН скорее второстепенна в статье. Это лишь полезная нагрузка для построения сервиса, некая абстрактная задача, которую можно развивать и на чём можно учиться.
Согласен с отсутствием нефункциональных требований и метрик качества. Сформулировать сейчас не получится, но в одном из разделов указал на скорость ответа базового сервиса от налоговой. При "развитии" сервиса попытаемся сформулировать и эти требования.
Про тесты написано в последнем разделе. Предвосхищая ваш вопрос почему сначала не пишем тесты, а потом код - так не было запроса на следование TDD.
Самый эпичный провал был месяц назад с Django, настраивая фоновую задачу в селери без указания времени только лишь с днём. В итоге за час запустилась прорва задач и упал прод. Сознался без проблем, санкций не было. Профит в том, что добавили метрики к менеджеру очередей.