Наша цель - упростить использование библиотек, но 0CJS - это не запуск одной волшебной команды для исправления всех проблем потенциального пользователя вашей библиотеки, это гораздо больше.
Есть много аспектов успеха в создании хорошо написанного инструмента CLI, я не собираюсь останавливаться на всех этих аспектах, только три; Базовые параметры, абстракции и нулевая конфигурация.
Исходные данные
При описании базовой линии я имею в виду, что ваш инструмент должен иметь хорошую основу для успеха. Это цель вашего инструмента, то, как вы подходите к проблеме и как вы решаете ее реализовать. Например, что имеет смысл скрывать от пользователя, а что полезно? Это может быть что-то столь же примитивное, как скрытие текста состояния или вывод информации о том, что делает ваш инструмент, пока пользователь ожидает завершения компиляции.
Чем больше времени вы думаете о том, как ведет себя инструмент, тем меньше времени вы тратите на исправление ошибок и рефакторинг кода, потому что вы думаете о пользователе и о том, с чем он может бороться.
Методика, которая может вам помочь, не связанная с гибкой разработкой, разработкой через тестирование или другими причудливыми терминами, - это схемы проектирования. С webpack-cli мы решили использовать Test Driven Development, но мы также решили написать проектную документацию, чтобы сэкономить нам работу в будущем. Мы заранее знали, как будет выглядеть архитектура, стало проще реализация и абстракции.
Если вы думаете о том, как ваш инструмент может выглядеть через пару месяцев, вы сэкономите несколько месяцев, отвечая на вопросы в своем проекте. Помните о четкой цели.
В качестве примера того, как архитектура может играть огромную роль в долгосрочной перспективе, я хотел бы использовать в качестве примера Полимер-CLI. Полимер полностью основан на классах и запускает команды с помощью раннера. Исходный код тонкий, интуитивно понятный и удобный для новых пользователей с его командами; запускать, анализировать и обслуживать.
Полимер-КЛИ
Абстракции
Абстракции используются во множестве. Вы, наверное, используете его прямо сейчас. Абстракции являются ключевым шаблоном проектирования в инструментах командной строки. Абстракции превосходны, поскольку они скрывают сложность от пользователя. Вы абстрагируете модули, сам инструмент или любой другой тип системы, например Google Chrome, и вам не нужно знать, как работает v8.
Как автор библиотеки, все пользователи хотят сделать одну важную вещь - настраивать. Предлагаемое вами решение не всегда оптимально для их варианта использования, и они хотят настроить ваш инструмент, чтобы он соответствовал их интеграции. Здесь на помощь приходят экосистемы. Экосистемы можно обозначить как другой уровень абстракции, за исключением того, что он основан на самом инструменте. Один из примеров - йомен.
Как автор библиотеки вы могли бы создавать экземпляры каркасов вашего инструмента, в которых yeoman извлекает от вас детали. Yeoman заботится о том, чтобы предлагать пользователям вопросы и готовить структуру папок. Единственное, о чем следует беспокоиться, - это использовать эти входные данные с вашим фреймворком или библиотекой.
Экосистемы служат способом абстрагироваться от сложности, задавая удобные для человека вопросы или абстрагируя вашу основную логику в более удобном API. Это хорошая вещь. Babel преуспел в этом, позволив людям писать плагины для своих инструментов. NPM преуспел в этом, позволив каждому использовать библиотеку с помощью одной команды установки.
В функционировании экосистем есть нюансы, но их объединяет одно - они скрывают сложность.
0Configuration.js
Когда вы, как автор библиотеки, несете ответственность за продвижение передовой практики, вы должны знать, какие значения по умолчанию вы устанавливаете. Представьте, что миллионы людей используют ваш инструмент. В качестве двух примеров возьмем React или Vue. Если React не устанавливает для пользователей подходящие значения по умолчанию, то и пользователь этого не делает. Как автор библиотеки, следуйте советам защитников, Microsoft или Google.
Важно подчеркнуть важность продвижения передовых методов, а не противодействия шаблонам, потому что, если вы как автор не знаете, как установить хорошие значения по умолчанию, зачем пользователю это делать?
Один совет, который я усвоил, работая с webpack-cli, заключается в том, что вам не обязательно соответствовать тому, что говорят все, если вы устанавливаете значение по умолчанию. Например, если у вас есть проект на основе конфигурации, которому нужна точка входа для пользовательского приложения (webpack), почему вы не можете установить точку входа на src / index.js вместо этого по умолчанию? Со временем пользователи последуют этому образцу. Установив соглашения и прислушиваясь к мнению защитников, вы уже преуспеваете.
Еще один момент, о котором стоит упомянуть, - это масштабирование сложности. Первоначальному пользователю может потребоваться большая помощь для начала работы, поэтому просить пользователей заполнить длинные строки кода, чтобы приложение загрузилось и было готово, может быть не лучшим вариантом. Вместо этого увеличивайте сложность. Чем больше пользователей используют ваш инструмент, тем более творчески вы можете подходить к параметрам и позволять пользователям их настраивать. Производительность не всегда бывает односторонней, у пользователей разные способы рендеринга своего приложения. Вместо того, чтобы настраивать это вначале, позвольте пользователям делать это постепенно.
Как вы, возможно, догадались, это то, что 0CJS не только позволяет пользователю сразу запускать ваше приложение, но и помогает им обучать. 0CJS не должен служить оправданием незнания инструмента, а скорее способом использовать его, не зная, как он работает на ранних этапах проекта.
Обучение разработчика важно, потому что, если мы сделаем это, они будут знать, как исправить потенциальные утечки памяти, ошибки или проблемы, которые могут у них возникнуть. Например, представьте, что пользователь использует webpack-offline-plugin, не зная, что это такое. Не зная сервис-воркеров, пользователи могут ими пользоваться. Все дело в том, чтобы скрыть сложность от пользователя, чтобы ему или ей не приходилось реализовывать целого сервис-воркера.
Однако мы действительно хотим рассказать людям о работниках сферы обслуживания, о том, почему они важны и как они работают. Если у пользователя возникнет проблема, ему не нужно постоянно обращаться к Stack Overflow, он может иметь справочную информацию и знания о том, как работает сервисный работник, чтобы знать, в чем проблема.
В заключение я хочу подвести итог, упомянув Create React App и то, как он делает такой отличный инструмент. Приложение Create React устанавливает значения по умолчанию, у него есть руководства пользователя длиннее, чем в академической статье, и он позволяет людям погрузиться в React, не зная ни одного шага сборки. Это то место, где мы хотим быть, когда людям не нужно знать инструменты, прежде чем использовать библиотеку. В конце концов, пользователю может понадобиться узнать об инструменте, но изначально это не важно.
Так на практике выглядит масштабирование сложности. Позволяя людям катапультироваться, они позволяют людям работать со сложностью, но по умолчанию пользователь ничего не знает о лежащей в основе логике. CRA также обучает пользователя, что облегчает привлечение новых людей в область интерфейса.
