Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 <p>Стоит или не стоит ставить библиотеки ради нескольких простых функций? Не проще ли их написать самим? Эти вопросы регулярно возникают у начинающих разработчиков. На Хекслете их задают практически все, кто проходит проекты. Давайте разбираться.</p>

2 <blockquote><p>И у меня возник вопрос на фоне этого момента и лодаша. Я вот подключил к проекту лодаш и использовал одну функцию всего. Насколько это целесообразно, подключать библиотеку ради 1 функции? Я ведь решил задачу и руками с помощью чистого js. Какую это проблему решит?</p>

3 </blockquote><p>Прежде всего, на эти вопросы нет однозначного ответа. В каждом конкретном случае нужно учитывать множество факторов, начиная от того, какой характер данного кода, заканчивая условиями запуска, то есть где и на чем работает программа. Ниже поговорим про эти факторы.</p>

4 <blockquote><p>Подписывайтесь на<a>канал Кирилла Мокевнина в Telegram</a>- чтобы узнать больше о программировании и профессиональном пути разработчика</p>

5 </blockquote><h2>Содержание</h2>

6 <ul><li><a>Размер кода</a></li>

7 <li><a>Зависимости</a></li>

8 <li><a>Где выгода?</a></li>

9 <li><a>Дополнительные материалы</a></li>

10 </ul><h2>Размер кода</h2>

11 <p>В бэкенде размер исходного кода практически не имеет значения. Плюс-минус мегабайт или даже десять ничего не значат. Современный софт содержит огромное количество ресурсов, вес которых на порядки превышает размер любой библиотеки. И даже если бы такая проблема стояла, то библиотека, предоставляющая простые функции, по определению не может занимать много места.</p>

12 <p>Во фронтенде ситуация чуть сложнее, но сейчас всё сводится к тому, как организована библиотека. Если у неё правильно организованны экспорты, то в результирующем бандле (собранным, например, вебпаком) окажутся только те функции, которые реально используются. А это очень мало.</p>

13 <h2>Зависимости</h2>

14 <p>Некоторые разработчики по каким-то своим соображениям избегают или стараются минимизировать зависимости (сторонние библиотеки) в коде. Здесь уже не обходится маленькими функциями, в таких проектах может быть довольно много своих решений для уже готовых инструментов.</p>

15 <p>Здесь особо нечего сказать. Зависимости - это нормально, если они позволяют сократить время разработчика и тратить больше времени на прикладную логику, чем на инфраструктурные задачи.</p>

16 <h2>Где выгода?</h2>

17 <p>Не все библиотеки одинаково полезны. Есть несколько базовых тем, которые, как правило, в языках раскрыты плохо. К ним относятся работа с коллекциями, работа со строками и датами. Кроме них, в разных языках есть разные более специфические разделы, которые требуют расширения. Именно в этих ситуациях библиотеки стоит добавлять в зависимости даже ради одной функции. И вот почему.</p>

18 <p>Как правило, там где нужна одна функция, скоро понадобится другая. Это происходит незаметно, и делают это другие люди. В итоге один написал функцию, затем другой в другом месте, и не факт, что они знают о функциях друг друга. Такие ситуации быстро превращаются из "еще рано" в "уже поздно", когда по всему коду понаделана куча функций, которые есть в соответствующих библиотеках. А дальше, когда программисты уходят на другие проекты, там начинается то же самое. В итоге по разным проектам разбросаны кучи стандартных функций, которые написаны разными людьми, содержат баги, не имеют документации и скорее всего плохо или вообще не протестированы.</p>

19 <p>Свой код никогда не будет так же тщательно протестирован и документирован, как популярные библиотеки. Попробуйте открыть<a>lodash</a>и посмотреть размер документации. Здесь же проявляется еще один плюс подобных библиотек. Они настолько распространены и стандартизированы, что работать с ними умеет большинство разработчиков. А значит, код проекта станет понятнее и проще для всех, кто с ним работает.</p>

20 <p>Есть еще один интересный, но неочевидный плюс в сторону использования подобных библиотек. Они содержат большое количество функций, до которых самостоятельно додуматься бывает крайне сложно. Использование этих библиотек заодно повышает уровень самого разработчика, он узнает о том, как можно решать большинство стандартных проблем минимумом кода при правильных абстракциях. Для этого, конечно, нужно периодически просматривать эти функции, но оно того стоит. В проектах Хекслета регулярно случается, что наши студенты переизобретают велосипед только потому, что они не знали о стандартных решениях. И когда говорят "мне нужна всего лишь одна функция", то на практике оказывается что не одна, просто разработчик об этом не знает в силу отсутствия нужного опыта.</p>

21 <p>В каждом языке есть свой набор библиотек, которые считаются обязательными практически для любого нетривиального проекта. Основные направления:</p>

22 <ul><li>Даты</li>

23 <li>Строки</li>

24 <li>Коллекции</li>

25 </ul><p>Что касается других, более редких библиотек, то ситуация может быть сложнее, и не всегда очевидно, стоит ли тащить библиотеку. Главное, принимая подобное решение, руководствоваться прагматизмом и не быть категоричным.</p>

26 <h2>Дополнительные материалы</h2>

27 <ul><li><a>Проектирование функций</a></li>

28 </ul>