Что лучше, 15мб зависимостей или свой велосипед?

При разработке публичного npm пакета часто возникает вопрос, использовать ли существующе
решение, которое тянет с собой чуть-ли не половину всех популярных пакетов с npm, или написать свой велосипед.

Чтобы сузить область, уточню детали. Свой велосипед - это примерно 1000-1500 стро
кода без зависимостей, естественно есть вероятность наделать много багов (но это как повезет). Время на разработку и отладку - день-два. Альтернатива - пакет который отлично решает эту задачу но тащит с собой ~150 вложенных зависимостей на ~15мб. 

Как считаете, что предпочтительнее? И по каким критериям прежде всего решаете, какой сделать выбор в данной ситуации?
    

Ответы

Ответ 1

В разработке ПО есть принцип KISS (keep it simple, stupid — «делай это проще, дурачок»)
Вполне логичный, в *nix системах очень распространенный. На мой взгляд в общем случае надо работать в соответствии с ним...

НО. Нужно трезво оценивать цели и задачи своего решения, и стороннего решения.
Если оно создано, поддерживается и развивается известным надежным разработчиком
если нужный вам функционал не является в этом решении "побочным". То почему нет?
Так же стоит подумать. Набор который тянется: на сколько велик шанс, что он буде
крайне полезным в проекте, который использует ваше решение; не будет ли большая вероятность конфликтов с аналогичными решениями (или разница в версиях).
Так же важно понять значимость этого функционала в вашем проекте. Возможно вы оди
раз напишете эти 1500 строк и хватит на долгие годы, это одно. (тогда этот вариант вполне годен) Другое, если гарантированно эти 1500 строк потребуют и поддержки и развития и, как следствие, сократят доступное время на разработку основного функционала

Как пользователь история к месту: попросили меня как-то LAMP на чистую винду поставить
Если не ошибаюсь инсталлятор MySQL был написан на .Net. В итоге ради установки ПО котором
не нужен NET потребовалось выкачивать сотню мегабайт... Подумайте если велик шанс, что среди пользователей вашего решения большей части вряд ли понадобятся все эти зависимости - значит лучше свой велосипед...


Ответ 2

В мире npm как то принято тянуть побольше зависимостей. И тут выход такой:


если это Ваш личный проект, тогда можно делать как нравится. В личных проектах велосипеды - самая правильная вещь (если цель проекта освоить новые технологии).
если это проект "на попробовать", "взлетит/не взлетит" (ака стартап) - тогда побольш
зависимостей, поменьше своего кода. Нам же идею проверять, инвесторов потенциальных радовать, а не код вылизывать. Потом, возможно, можно будет и переписать.
если это проект рабочий (то есть, делается на работе), тогда лучше спросить у менеджера/тимлида/
тому подобное. Если сам тимлид/менеджер, тогда пункты выше. Но тут может оказаться, что юротдел может сказать, что некоторые пакеты имеют "неправильные лицензии" или "сомнительное происхождение" и их придется делать самому.


Но тут есть ещё одна штука. Нужно смотреть, а что за зависимости. Мало чего там
Может они конфиденциальную информацию собирают и в закрома засылают. И прецеденты уже были.

Мне также нравится следующая система. Собираем проект с готовых пакетов, смотрим
что бы лицензии у них были "хорошие, с возможностью модификации". А потом, когда проек
"похоже работает", начинаем вычищать, переписывая критические участки. К примеру, можн
использовать одну мелкую функцию с огромного пакета. Вполне возможно, что есть смысл ее извлечь в отдельный свой пакет. Хотя сейчас набегут хипстеры-оптимизаторы и скажут: "а вдруг завтра понадобиться ещё одна функция? и что извлекать снова? диски сейчас большие, памяти много, процессор пользователь докупит". Но таких нужно игнорировать и пользоваться здравым смыслом.