tgoop.com/golangprofi/507
Last Update:
👣 Почему сообщество #golang старается не использовать сторонние библиотеки?
Некоторые причины исторические (до Go 1.11 в Go была довольно печальная история управления зависимостями), некоторые культурные (сообщество Go пропагандирует простоту и самодостаточность), но некоторые из них, я бы сказал, являются хорошей практикой независимо от используемого языка.
Безопасность - когда вы добавляете зависимость, вы добавляете разработчика (или команду разработчиков), с которым вы никогда не взаимодействовали, в качестве участника вашего проекта. Вы должны проанализировать библиотеку, как если бы она была написана собственными силами, и убедиться, что она соответствует вашим задачам и не несет никакого риска.
Сложность в поддержке - теперь вы и ваша команда должны поддерживать добавленную библиотеку в актуальном состоянии.
Воспроизводимые сборки - Вы можете добиться этого с помощью библиотек сторонних производителей, но чем меньше вам придется об этом беспокоиться, тем лучше.
Просто нет необходимости - Это одна из лучших причин. В Go есть замечательная стандартная библиотека, и вы можете добиться очень многого, используя ее.
Так когда же следует обращаться к библиотеке?
Если то, что вы хотите реализовать, является функционально сложным, имеет приемущества от поддержки сообществом и берется из надежного источника, то использование библиотеки может быть хорошим вариантом.
Примерами библиотек, которые, на мой взгляд, являются достойными для внимания:
- Библиотеки шин сообщений (Kafka, RabbitMQ и т.д.)
- Библиотеки БД (Mongo, Postgres).
- Сложные криптографические вещи алгоритмы, которые не поддерживаются стандартной библиотекой.
👇 Напишите в комментаряих о ваших любимых сторонних библиотеках.
@golangprofi
BY Golang Юниор
Share with your friend now:
tgoop.com/golangprofi/507