В продолжение мысли из прошлой статьи про «лучшее — враг хорошего», но с чуть другого угла

В продолжение мысли из прошлой статьи про «лучшее — враг хорошего», но с чуть другого угла.

Недавно наткнулся на заметку, где автор жалуется на неудобство стандартных ассерт-функций в Go. В итоге большинство разработчиков тащат в зависимости testify. Казалось бы — мелочь: подключил и забыл. Но это лишняя зависимость, на которую ты не влияешь. Хотя тот же assert можно накидать за пару минут.

И вот тут начинается интересное.

Я уже говорил на митапе в Иннополисе про то, что лишние абстракции и зависимости часто вредят, хотя в моменте решение кажется удобным. Причины простые:

📌 Нет контроля над кодом → зависимость может тянуть за собой десятки других пакетов. Достаточно вспомнить историю с удалением left-pad, когда «однострочник» парализовал npm-экосистему.

📌 Отсутствие понимания, что происходит внутри → да, исходники есть, но как много людей реально читают код перед установкой?

📌 Фактор ИИ → всё больше библиотек генерируется нейросетями. Это инструмент, но более непредсказуемый. История Лео Мартинеса — хороший пример того, как ИИ может внести критичные ошибки.

Поэтому всё чаще вижу одну и ту же стратегию у опытных инженеров:

⚡️ Если можно сделать свою реализацию быстро — делай, не тяни зависимость.

В больших проектах это особенно важно: со временем появятся новые требования, а чужую библиотеку просто так не расширишь. Останется либо форкать, либо переписывать с нуля. И оба варианта дороже, чем потратить лишние 30 минут на старте.

Когда зависимость всё-таки оправдана:

📌 Решает сложную задачу, на которую у вас уйдут недели или месяцы (шифрование, парсинг excel, обработка видео и т.д.).

📌 Имеет большую и активную комьюнити-поддержку, регулярные обновления и прозрачную разработку и является индустриальным стандартом (например, pytest или React).

📌 Есть проверенные кейсы её использования в проектах с требованиями, схожими с вашими.

📌 Вы готовы читать и понимать её код, чтобы при необходимости исправить или расширить функционал.

Короче, чем меньше «чёрных ящиков» в коде, тем проще жить, поддерживать и развивать проект. Но если уж тянете библиотеку — делайте это осознанно.