Описание API в текстовом виде в конфлюенсе - зло. Такое описание может вполне сойти за ТЗ разработчику, который погружен в проект и у которого аналитик всегда под рукой, но для внешних пользователей бесполезно. Для внешних пользователей это должна быть спецификация openapi и примеры рабочих (с корректной авторизацией и корректными dto) запросов, которые можно выполнить самостоятельно.
Описание БД в текстовом виде в конфлюенсе тоже считаю избыточным. Разрабу оно не нужно и оно устареет после первого спринта. Если на помощь все равно нужны или архитектор или разработчик, то легче выгрузить модель из реальной БД.
Но в целом статья понравилась своим целостным подходом.
По поводу встреч 1:1 есть хорошее правило, которое не позволяет сойти им совсем на нет. Как только ты проводишь встречу с подчиненным, то сразу ставишь следующую в календаре через 3-4 месяца.
Могу порекомендовать книгу Максима Дорофеева «Джедайские техники». Там раскрыта тема почему так происходит с физиологической и психологической точки зрения. Очень пересекается с данной статьей.
Отдельный сокет для того, чтобы перезапуском одного из двух сервисов (nginx) можно было вернуться в исходное состояние. Это не принципиально, решений тут можно придумать десяток.
У меня нет точного ответа на этот вопрос. Наибольшую загрузку на диски у нас дает mysql, версия «больше остается на кеши» хорошая, но количество памяти под мускул мы не меняли.
Я понял, что это был не восторг. Данные привел исходя из мониторинга. На данный момент главная страница загружается за 140 мс. Я не хотел обсуждать конкретные цифры, в статье я хотел показать общую динамику.
Мы тебя рады тут читать с любыми штуками!
Хорошо бы данную информацию размещать в статье
Список APM впечатляет, но хочется каких-то практических советов. На каком инструменте остановился автор для мониторинга API в своем продукте?
Покритикую немного
Описание API в текстовом виде в конфлюенсе - зло. Такое описание может вполне сойти за ТЗ разработчику, который погружен в проект и у которого аналитик всегда под рукой, но для внешних пользователей бесполезно. Для внешних пользователей это должна быть спецификация openapi и примеры рабочих (с корректной авторизацией и корректными dto) запросов, которые можно выполнить самостоятельно.
Описание БД в текстовом виде в конфлюенсе тоже считаю избыточным. Разрабу оно не нужно и оно устареет после первого спринта. Если на помощь все равно нужны или архитектор или разработчик, то легче выгрузить модель из реальной БД.
Но в целом статья понравилась своим целостным подходом.
Вот такое решение вам не подходит?
https://learning.postman.com/docs/sending-requests/capturing-request-data/capturing-http-requests/
Тоже не видел систем лучше, но его теперь не купить для корпоративного использования, нужно искать другие варианты.
Использующие методику обзора 360 с вами тут категорически не согласны
По поводу встреч 1:1 есть хорошее правило, которое не позволяет сойти им совсем на нет. Как только ты проводишь встречу с подчиненным, то сразу ставишь следующую в календаре через 3-4 месяца.