Найти в Дзене

Совершенный код: библиотека или своё решение

Стоит или не стоит ставить библиотеки ради нескольких простых функций? Не проще ли их написать самим? Эти вопросы регулярно возникают у начинающих разработчиков. На Хекслете их задают практически все, кто проходит проекты. Давайте разбираться. И у меня возник вопрос на фоне этого момента и лодаша. Я вот подключил к проекту лодаш и использовал одну функцию всего. Насколько это целесообразно, подключать библиотеку ради 1 функции? Я ведь решил задачу и руками с помощью чистого js. Какую это проблему решит? Прежде всего, на эти вопросы нет однозначного ответа. В каждом конкретном случае нужно учитывать множество факторов, начиная от того, какой характер данного кода, заканчивая условиями запуска, то есть где и на чем работает программа. Ниже поговорим про эти факторы. Размер кода В бэкенде размер исходного кода практически не имеет значения. Плюс-минус мегабайт или даже десять ничего не значат. Современный софт содержит огромное количество ресурсов, вес которых на порядки превышает размер
Оглавление

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

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

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

Размер кода

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

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

Зависимости

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

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

Где выгода?

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

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

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

import _ from 'lodash';
// Довольно популярная функция, которая нередко нужна в проектах
_.compact([0, 1,
false, 2, '', 3]);
// => [1, 2, 3]

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

// Полезные примеры:

_.intersection([2, 1], [2, 3]);
// => [2]

_.union([2], [1, 2]);
// => [2, 1]

_.zip(['a', 'b'], [1, 2], [
true, false]);
// => [['a', 1, true], ['b', 2, false]]

const object = { 'a': { 'b': 2 } };

_.has(object, ['a', 'b']);
// => true

_.
get(object, 'a.b.c', 'default');
// => 'default'

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

  • Даты
  • Строки
  • Коллекции

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

Автор оригинальной публикации — Кирилл Мокевнин.