tgoop.com/dev_easy_notes/199
Last Update:
По какой причине все так не любят C++? Основная причина это недостаток дизайна C++, который слишком многое позволяет разработчику. Одни только макросы могут принести неожиданного поведения (реально можно через define заменить все true на false и потом наслаждаться шоу), а в одном из последних стандартов появилась метаклассы, которые буквально позволяют написать свой язык внутри C++.
С одной стороны такая свобода это максимальная гибкость, с другой стороны это возможность кому угодно одной строчкой просто разнести всю кодовую базу. По этой причине все пытаются использовать другие языки если нам не нужна мега производительность. Новичков можно без каких-либо опасений подпускать к кодовой базе на Java.
Это все к чему, Gradle это C++ мира билд систем. В документации Bazel есть интересная фраза про системы вроде Gradle: too much power to engineers and not enough power to the system.
Это пожалуй главная проблема Gradle из которой вырастают все остальные и про которые я писал в прошлых постах. Он как и C++ позволяют разработчику сделать очень многое, тем самым отстрелив ногу по шею. Легко можно взять и пойти в сеть во время конфигурации или файл или вообще по ssh отправить на удаленный сервер какую-то инфу.
Система никогда не знает что происходит внутри Task и никак не может это ограничить. Если вы не использовали Input и Output, то Gradle вообще не особо понимать нужно ли второй раз перезапускать вашу Task, какие данные вам нужны на вход и т.д. Помимо это все Task в Gradle еще и мутабельные в Runtime. Очень просто сделать плагин, который будет выключать таски компиляции во время конфигурации: tasks.findByPath("assemble")?.enabled = false
Представьте что у вас большой проект с огромной кучей плагинов, каждый из которых уверен, что он самый главный и каждый начинает вносить изменения в граф зависимостей тасок. Ну кошмар же!
Пока проект мелкий и мало скриптов это разумеется ни разу не проблема, однако с ростом масштаба приходится играть в детектива и скрупулезно изучать что делает каждый из плагинов и скриптов по время конфигурации и запуска.
Это проблема очень красиво решается в системах типа Bazel, где Rule (аналог Task в Gradle) вообще ничего не знают ни про других рулов ни про систему вообще. Вы явно должны указать что хотите получить на вход и что выдает ваша рула на выходе. Вы не сможете сходить в сеть или в файл просто потому, что в языке конфигурации отсутствует такая возможность.
Ядро билд системы само решает в каком порядке нужно вызывать Rule и нужно ли их вообще перезапускать. Уже нет проблемы с side-effect потому как их просто невозможно сделать, система ударит вас по рукам.
Gradle развивается и понемногу даже решает эти проблемы. Например, можно использовать механизм Input и Output, чтобы Gradle сам решал, нужно ли вас перезапускать и в каком порядке. Однако никто не запрещает сделать по старинке. Плюс вам же нужно про это найти инфу в документации Gradle которая оставляет желать лучшего.
Подводя итог, хотите разобраться в Gradle по лучше, посмотрите эти три доклада:
👉 Самые базовы вещи
👉 Доклад Зиннатуллина про то, почему в Lift используют Bazel
👉 Также про Gradle, но уже чуть глубже
BY Dev Easy Notes
Share with your friend now:
tgoop.com/dev_easy_notes/199