Урок 1: Сделайте это проще
Чтобы сделать вещи публичными, нужно, чтобы они были простыми. Это как учить маленького мальчика, как пользоваться ложкой, чтобы зачерпнуть еду со стола. Я представляю себя тем самым парнем, который заглядывал в коды библиотек, чтобы понять, о чем думал первоначальный создатель. Код должен быть явным!
Если для объяснения кода необходимо создать функцию, сделайте это!
export const constructUrl = (url, qs = {}) => (
url + appendQuery(qs)
);
Урок 2: Имейте README.md
Раньше я был парнем, который хотел бы испачкать руки, чтобы починить шкаф IKEA, не просматривая предоставленное чрезвычайно хорошо документированное руководство. Удовольствие от обнаружения, где подходит каждый гвоздь, и физического сверления его обеспечивает максимальное чувство достижения. Однако такой подход делает вещи очень непредсказуемыми и отнимает много времени. Представьте себе проблему и разочарование, когда вы закончили сборку шкафа и обнаружили, что на верстаке остался только винт, который должен быть внутри.
Этот сценарий слишком распространен в мире проектов с открытым исходным кодом. Творцы — уникальные люди, которые видят проблему и решение со своей точки зрения. Их код лучше всего отражает их мысли, но просмотр тысяч строк кода — очень трудоемкий процесс. Файл README.md позволяет потребителю заглянуть в мысли создателя. Позволяя нам согласовать наш вариант использования с создателем, понимая, поможет ли эта библиотека нам в нашем стремлении решить проблему.
Урок 3. Подайте пример
Что может быть второй лучшей альтернативой, если потребитель не понимает выражение ваших мыслей через файл README.md? Дайте им пример!
Все любят хороший пример для подражания!
Урок 4. Написание тестов
Я не могу не подчеркнуть важность этого урока. Опубликовать библиотеку через npm очень просто. Слишком просто! Это означает, что любой Том, Дик и Гарри, посетивший несколько учебных занятий, может написать свою собственную библиотеку, и люди смогут начать ее скачивать. О, черт, мы могли бы начать нашу собственную лимонную проблему
Рынок лимонов: неопределенность качества и рыночный механизм — это статья экономиста Джорджа Акерлофа 1970 года, в которой исследуется, как качество товаров, продаваемых на рынке, может ухудшиться в присутствии информационная асимметрия между покупателями и продавцами, оставляя после себя только лимоны.
https://en.wikipedia.org/wiki/The_Market_for_Lemons
Так что же помогает контролировать качество кода (не говорю, что все библиотеки, написанные без тестирования, плохие). Правильно, ТЕСТЫ!
Тесты дают потребителю гарантию того, что библиотека работает так, как заявлено, а инструменты покрытия обеспечивают дополнительный уровень уверенности в том, что весь написанный код протестирован. Без сюрпризов.
Урок 5: Процесс сборки
Одной из первых проблем, с которыми я столкнулся при выпуске релиза, была необходимость создать папку lib. Локально эта папка всегда игнорируется вездесущим файлом .gitignore. Затем я узнал о всемогущем .npmignore. Благодаря этому сообщению в stackoverflow
Настроить процесс сборки Travis было легко и просто. Документация, представленная на Travis, очень проста для понимания, и все так, как должно быть.
Я настроил процесс сборки, который включает запуск теста, отправку отчета о покрытии тестами в Coveralls и, наконец, его публикацию в npm.
использованная литература
