tgoop.com/dev_easy_notes/254
Last Update:
Хочу рассказать еще одну наболевшую вещь про Gradle, про которую почему-то не принято говорить. В Gradle максимально ебанутая система логирования.
Начнем с того, что при каждом запуске любой таски в gradle, он начинает дико срать в консоль про все этапы конфигурации и порядок выполнения тасок. И я каждый раз задаюсь вопросом, нахера? Предвещая ваш вопрос: "а что делать если есть проблема, или я хочу понять выполняется ли вообще нужная мне таска", так для этого можно сделать отдельный флаг. Сами подумайте, когда вам нужна эта инфа о порядке выполнения? Только в тот момент, когда вы ищете проблему. Захера она включена по умолчанию. Я от gradle как от системы сборки по умолчанию хочу в консоли видеть только две строки: либо все хорошо и сборка успешная, либо все плохо и причину косяка, все ничего более. Однако нет, он насрет в лог 30 строк даже если сделал целое ничего.
Если кто-то пробовал разрабатывать плагин, то должен знать что gradle в каждой таске позволяет получить логер. В gradle используется интерфейс slf4j для логирования. И казалось бы, раз это slf4j который славится возможностью подсунуть свою реализацию, то писать лог можно куда угодно, да? Пизда! Gradle позволяет писать лог только в консоль, хочешь лог в файл перенаправляй поток.
И ладно, пофигу, консоль так консоль, не сильно страшно, это все таки система сборки, а не сервис. Проблема в другом, вот вы делаете свою таску и хотите сделать логи, дебажные, которые не мазолили бы глаза и которые писались только когда нам нужно. Однако запустив сборку с флагом --debug вы увидите все что угодно, но не нужные вам логи. Это просто какой-то кошмар, я не понимаю как эти логи можно анализировать, есть ощущение, что и сами разработчики Gradle давно забили на попытки в них что-то понять и просто отпустили ситуацию.
В конечном итоге в дебаг не получается писать, потому как вы тупо не сможете найти нужные вам логи среди кучи остального мусора. С info ситуация не лучше. В итоге, чтобы увидеть какую-то информацию, приходится использовать метод lifecycle, который отправляет лог в консоль при каждом запуске. Другими словами, Gradle зараза срет кучу всего в консоль, так еще и тебя вынуждает при разработке плагинов срать еще больше.
Никита Пахомов тонко заметил, что в современости есть тенденция у разрабов, по больше насрать логов, которые никому не нужные и ни о чем не говорят, а потом удивлятся о том, почему их программу никто не любит. Вся проблема кроется в том, чтобы наделать кучу ненужных логов, не нужно прилагать никаких усилий, а вот, чтобы выводить только нужную инфу, тут уже нужно думать и проектировать. Ведь по сути, вся информация, которую вы пишете в консоль у CLI проги это ее интерфейс. А где есть интерфейс всегда нужно думать и про UX.
В тему про это есть отличный доклад где разраб из Яндекса рассказывается как они избавились от всех дебажных логах у себя на бэке, и предпочли другие системы для мониторинга. В кратце, стоит всегда задумываться для чего тебе нужен конкретный лог, в каких ситуациях он тебе понадобится, и если ответ "На всякий случай", этот лог тебе не нужен!
BY Dev Easy Notes
Share with your friend now:
tgoop.com/dev_easy_notes/254