Dev Easy Notes

Так как я стал уже гуру CLI, в голову мне пришла идея, а не оформить ли список best practice по этой теме. Да в канале про android разработку! Ну а чего, все вы рано или поздно станете, или лидами, или тех лидами так или иначе, вам придется сделать парочку задач связанных с инфраструктурой.

Не то чтобы я вообще преисполнился в своем сознании и сейчас выдам прям базу. Однако зная эти советы раньше, я бы точно сэкономил пару тройку дней работы. Ну чтож погнали.

👉 Не делайте CLI на java. JVM для сервера – круто, JVM для мобилки – сомнительно, но окэй, вроде работает, JVM для CLI – проклятие. Часто jar получается огромный, плюс сама jvm весит нефигово и жрет дохера ресурсов. В итоге ты это чудо не добавишь в докер образ, ибо последний разбухнет до невероятных размеров. Делайте CLI на java только в том случае, если у вас есть либа на java и вообще нет никаких других вариантов.

👉 Какой язык использовать? Если не важно как быстро должен работать скрипт берите Python, важно чтобы работал быстро – Go, если нужно еще и системные вызовы использовать и супер перфоманс – Rust. Держите в голове что в 99% случаев скорость работы будет ограничена сетью, а не CPU, поэтому берите Python и не выебывайтесь.

👉 Если не читали про unix way, то перед разработкой CLI тулзы идите и почитайте. Кратко – лучше делать несколько CLI которые хорошо делают что-то одно, чем одну CLI, которая делает все. Даже если она это делает хорошо. Атомарные CLI можно связать вместе через pipe и вообще запускать как угодно, это дает гибкость и избавит от гемора в будущем. Наверное...

👉 Не пишите обработку аргументов сами. Совет скорее для совсем начинающих, тем не менее. Охренеете это делать вручную, всегда сначала погуглите инструменты для вашего языка. Для примера, в python из коробки есть ArgumentParser который позволяет это делать в две строки.

👉 Если вам кажется что использовать yaml для конфигурации программы хорошая идея, то подумайте еще. Я уже обжегся, не советую так делать, используйте ini-файлы.

👉 Не завязывайтесь на окружение. У нас есть внутренний инструмент, который завязывается на переменную окружения CI. Другими словами, работает эта CLI только на CI, и чтобы протестировать ее локально, нужно делать приседания с переменными окружения. Не делайте так, всегда должна быть возможность протестировать CLI локально.

👉 В дополнение к предыдущему. Если вы хотите чтобы прога получала данные из переменных окружения, добавьте возможность указывать их явно через аргументы. Чтобы было так: если в аргументах не указано берем из окружения, если указано берем из аргументов.

👉 Про ключи писал в прошлом посте, но напомню, длинные версии на CI, короткие локально.

👉 Для всех CLI есть один негласный контракт, если много ключей, то их можно записать в файл, а вызывать CLI следующим образом: ./program @path_to_file. Таким образом можно ключи, которые меняются редко вынести в файл и сделать вызов лаконичнее.

👉 Gradle или CLI? Это тянет на отдельный пост, но давайте так. Сначала ответьте на эти вопросы: Вам нужно знать про граф зависимостей? Вам нужно как-то использовать сторонний gradle plugin? Если на один из этих вопросов вы ответили четкое "Да", делайте задачу через gradle плагин, если же сомневайтесь, лучше сделайте скрипт на python. Поверьте так будет быстрее как в разработке скрипта, дебажить gradle плагин это то еще удовольствие, так и в производительности, python скрипт в отличие от gradle не тратит время на конфигурацию или скачиванию самого себя.

👍43❤1👎1

www.tgoop.com/dev_easy_notes/251

4.02K viewsNikita, Jun 29, 2023 at 06:54

Так как я стал уже гуру CLI, в голову мне пришла идея, а не оформить ли список best practice по этой теме. Да в канале про android разработку! Ну а чего, все вы рано или поздно станете, или лидами, или тех лидами так или иначе, вам придется сделать парочку задач связанных с инфраструктурой.

Не то чтобы я вообще преисполнился в своем сознании и сейчас выдам прям базу. Однако зная эти советы раньше, я бы точно сэкономил пару тройку дней работы. Ну чтож погнали.

👉 Не делайте CLI на java. JVM для сервера – круто, JVM для мобилки – сомнительно, но окэй, вроде работает, JVM для CLI – проклятие. Часто jar получается огромный, плюс сама jvm весит нефигово и жрет дохера ресурсов. В итоге ты это чудо не добавишь в докер образ, ибо последний разбухнет до невероятных размеров. Делайте CLI на java только в том случае, если у вас есть либа на java и вообще нет никаких других вариантов.

👉 Какой язык использовать? Если не важно как быстро должен работать скрипт берите Python, важно чтобы работал быстро – Go, если нужно еще и системные вызовы использовать и супер перфоманс – Rust. Держите в голове что в 99% случаев скорость работы будет ограничена сетью, а не CPU, поэтому берите Python и не выебывайтесь.

👉 Если не читали про unix way, то перед разработкой CLI тулзы идите и почитайте. Кратко – лучше делать несколько CLI которые хорошо делают что-то одно, чем одну CLI, которая делает все. Даже если она это делает хорошо. Атомарные CLI можно связать вместе через pipe и вообще запускать как угодно, это дает гибкость и избавит от гемора в будущем. Наверное...

👉 Не пишите обработку аргументов сами. Совет скорее для совсем начинающих, тем не менее. Охренеете это делать вручную, всегда сначала погуглите инструменты для вашего языка. Для примера, в python из коробки есть ArgumentParser который позволяет это делать в две строки.

👉 Если вам кажется что использовать yaml для конфигурации программы хорошая идея, то подумайте еще. Я уже обжегся, не советую так делать, используйте ini-файлы.

👉 Не завязывайтесь на окружение. У нас есть внутренний инструмент, который завязывается на переменную окружения CI. Другими словами, работает эта CLI только на CI, и чтобы протестировать ее локально, нужно делать приседания с переменными окружения. Не делайте так, всегда должна быть возможность протестировать CLI локально.

👉 В дополнение к предыдущему. Если вы хотите чтобы прога получала данные из переменных окружения, добавьте возможность указывать их явно через аргументы. Чтобы было так: если в аргументах не указано берем из окружения, если указано берем из аргументов.

👉 Про ключи писал в прошлом посте, но напомню, длинные версии на CI, короткие локально.

👉 Для всех CLI есть один негласный контракт, если много ключей, то их можно записать в файл, а вызывать CLI следующим образом: ./program @path_to_file. Таким образом можно ключи, которые меняются редко вынести в файл и сделать вызов лаконичнее.

👉 Gradle или CLI? Это тянет на отдельный пост, но давайте так. Сначала ответьте на эти вопросы: Вам нужно знать про граф зависимостей? Вам нужно как-то использовать сторонний gradle plugin? Если на один из этих вопросов вы ответили четкое "Да", делайте задачу через gradle плагин, если же сомневайтесь, лучше сделайте скрипт на python. Поверьте так будет быстрее как в разработке скрипта, дебажить gradle плагин это то еще удовольствие, так и в производительности, python скрипт в отличие от gradle не тратит время на конфигурацию или скачиванию самого себя.

BY Dev Easy Notes