Разработка

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

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

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

И у меня возник вопрос на фоне этого момента и лодаша. Я вот подключил к проекту лодаш и использовал одну функцию всего. Насколько это целесообразно, подключать библиотеку ради 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'

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

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

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

Аватар пользователя Kirill Mokevnin
Kirill Mokevnin 20 июня 2020

Зарегистрироваться

или войти в аккаунт

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.

  • 115 курсов, 2000+ часов теории
  • 800 практических заданий в браузере
  • 250 000 студентов

Нажимая кнопку «Зарегистрироваться», вы даёте своё согласие на обработку персональных данных в соответствии с «Политикой конфиденциальности» и соглашаетесь с «Условиями оказания услуг».

Наши выпускники работают в компаниях:

Логотип компании Альфа Банк
Логотип компании Rambler
Логотип компании Bookmate
Логотип компании Botmother