Синдре Сорхус — автор более, чем 666 модулей npm (666, Карл!). В недавнем AMA (кто не знает, это такой формат, когда кто-либо известный/интересный предлагает позадавать ему вопросы, например, в виде тикетов к гит-репозиторию, хотя, конечно, известнее /r/AMA и фуршет у Лебедева) он пояснил свою позицию по поводу модулей-однострочников, которые зачастую вызывают критику в адрес node.
Я собирался написать пост в блоге на эту тему, но, к сожалению, в этом я не так продуктивен, как в написании кода.
tl;dr Небольшие специализированные модули нужны для повторного использования и для того, чтобы делать большие и сложные штуки, которые легко понять.
Люди слишком легко ведутся на LOC (Lines Of Code, количество строк кода). LOC вообще не имеет никакого значения. Не важно, состоит модуль из одной строчки, или из сотен. Все дело в сокрытии сложности. Думайте о модулях node как о кубиках лего. Вас не интересует, из чего и как они сделаны. Все, что вам требуется знать — как использовать эти кубики для постройки своего лего-замка. Делая маленькие и специализированные модули, вы можете легко строить большие и комплексные системы без контроля за тем, как каждая отдельная деталь работает. Наша кратковременная память конечна. Эти модули могут повторно использовать другие люди и каждое улучшение и исправленный баг получат все из них.
Представьте себе, если бы производители ПК производили процессоры сами. Большинство делали бы это плохо. Компьютеры были бы дороже, а инновации происходили бы медленнее. Вместо этого большинство использует Intel, ARM и прочие.
И это было бы невозможно, если бы npm не работал именно так. Красота многоуровневых зависимостей заключается в том, что я не должен контролировать, какие зависимости зависимостей я использую. В этом его сила.
Несколько лет назад, до Node.js и npm у меня была большая база сниппетов, которые я копипастил в проекты, когда в этом была нужда. Это были небольшие полезности, которые иногда пригождались. Теперь npm — моя база сниппетов. Зачем копипастить, если можно зареквайрить модуль и получить именно то, что нужно. Исправление бага в «сниппете» — всего лишь обновление одного модуля, а не исправление «руками» всех мест, где сниппет вставлялся бы.
К примеру, у меня есть модуль negative-zero. Его работа — сказать мне, что число равно -0. Обычно это не требуется, но случается. И как нам определить, что число — -0. Вполне легко, x === 0 && 1 / x === -Infinity. Так? Вам действительно надо знать, как и почему это работает так? Я бы предпочел подключить negative-zero и сконгцентрироваться на других вещах.
Другой пример. Один из самых популярных модулей на npm — Chalk. Возможно, вы не знаете этого, но, на самом деле, это набор модулей. Он использует модуль для определения поддержки цветов в терминале, для получения ansi-кодов, и т.д. Все это можно было бы включить в основной модуль, и это возможно в большинстве случаев. Но это означало бы, что ктро-либо еще создаст альтернативный модуль для работы со строками в терминале и переизобрете колесо. С этим же набором модулей, люди легко получают выгоду от использования в своих проектах Chalk’а и, может быть, даже помогают косвенно улучшить сам Chalk, улучшая одну из его зависимостей.
И еще пример. Мой модуль user-home нужен только для того, чтобы получить домашнюю директорию пользователя. Вы можете подумать, что может быть проще, чем написать process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME. И большинство так и сделает. Но, правда, зачем каждому из нас знать, как получить домашнюю директорию? Почему бы не использовать готовый «кубик лего»? Ну и, конечно же, вы можете и не знать, что эта проверка — неполная. В Windows вам надо также посмотреть process.env.HOMEDRIVE + process.env.HOMEPATH, а еще вы могли бы также захотеть сделать дополнительные проверки. Лего.
Вы же не шьете себе собственные ботинки? Нет, вы покупаете их в магазине. Большинство не заботит, как изготавливаются их ботинки. Только то, как они хорошо сидят на ноге.
Я хочу, чтобы программировать было проще. Делать программирование более простым — это строить надежные системы. И практический путь в моем видении — это точно не переизобретать все подряд и делать одни и те же глупые ошибки снова и снова.
ссылка на оригинал статьи http://habrahabr.ru/post/262681/
Добавить комментарий