Я вот работал несколько лет в небольшой компании, у нас был аккуратный проект с небольшими микросерисами и вообще не было ничего сложного в том, чтобы запускать 1-2 микросервиса локально дебагером и тестить каким-то постманом.
И сейчас я вот попал в крупную компанию на серьёзный проект, и для меня стало вообще неожиданносью, что его разрабатывают без локального запуска. Пишут код, тесты, идут на dev. Типа слишком сложно локально сымитировать окружение вне контейнеров.
Подскажите, насколько вообще это типичная практика, работать без локального запуска и дебага?
Я плохо для себя это представляю ибо всегда ловил буквально десятки ошибок/багов именно дебагером, но может быть конечно надо поменять подход и начать писать более аккуратно с более качественными тестами.
насколько вообще это типичная практика, работать без локального запуска и дебага
Например, это была общепринятая практика в эпоху перфокарт. :) Программу выбивали на перфокартах, потом дожидались очереди на запуск, чтобы посмотреть результат (обычно распечатку). Если результат кривой - глазами искали ошибку. Дебаггеры появились позже, когда перфокарты умерли.
Я плохо для себя это представляю ибо всегда ловил буквально десятки ошибок
Помимо тестов можно добавлять в код вывод отладочных сообщений, например, какие-то значения переменных, по которым можно оценить правильность куска кода, или сообщение о выполнении какого-то условия, о вызове какой-то функции (предполагаются относительно редкие события, конечно). Эдакий эрзац-дебаггер.
слишком сложно локально сымитировать окружение вне контейнеров
такое вполне возможно, особенно если продукт сложный, многомодульный и динамично меняется.
в конечном счете все упирается в деньги, можно в один клик создать снапшот тестовой установки с базой, но если это потребует еще несколько серверов, кто за это будет платить?
Есть точка зрения (от функциональщиков) что если у тебя код разбит на функции и они покрыты тестами
то никакой дебаг тебе не нужен. А если вдруг стал нужен - то что-то у тебя не то с тестовым покрытием.
Я тут не могу на 100% согласиться потому что я лично не видел чисто функциональных проектов. Но
эта мысль очень правильная. Она заставляет задуматься.
Вообще сам процес дебага появляется когда программист говорит "я не знаю чему будет равна эта
переменная в этой функции". Это как раз тестом и проверяется. Еще есть кейс когда програмист не знает
какой результат вернул внешний datasource (база или микросервис). Но мы это закрывали логгированием
уровня debug всех внешних сервисов (и желательно в отдельные логи).
Есть особые условия безопасности когда программист физически не имеет доступа к периметру где работает
его код. Я такое видел и даже участвовал. Это банковские продукты которые очень сильно защищены.
И понятное дело что никто debug port вам туда не откроет. За этим следят безопасники и единственное
что у вас будет для анализа это логи. Поэтому логи .. логи и еще раз логи с разной детализацией.
Вобщем отсутсвие практики дебага на проекте - это нормально. Это просто повод сесть и задуматься
а как вообще вам писать код чтоб не делать ошибок. Я считаю что это возможно. Вобщем это скорее
положительный челлендж. Пробуйте и у вас получиться.
Исходя из практики применения этого термина в 99% случаев имеется в виду remote debugging. И если я или кто-то другой вас попросит "подебажить" приложение - мы не будем иметь в виду просмотр логов.
Исходя из практики применения этого термина в 99% случаев имеется в виду remote debugging. И если я или кто-то другой вас попросит "подебажить" приложение - мы не будем иметь в виду просмотр логов.
Вы просто ещё не сталкивались с ситуациями когда запуск для отладки не возможен.
Многие апи имеют квоты, другие просто не дают тестовый режим. Подключение бывает с ограничениями по айпи.
По этому задачу разбиваешь на части .
И например вместо полного запуска всего Андроид приложения и кучи тапок до нужного момента используешь механизм тестов. Запуск отлаживаемой функции сразу из тестов и уже с нужными данными от предыдущих шагов (тестовый набор).
Простой
Сложный
