Я уверен, что вы уже сталкивались с проблемами кодирования, независимо от того, является ли основная тема поднятием кода, замыканиями, промисами или циклом обработки событий. Этот немного отличается по причинам, которые станут очевидными.
Задача: создать генератор случайных строк.
Каковы ваши первые мысли, когда вы читаете что-то подобное? Некоторые, получив такой вызов (некоторые могут сказать, что это требование), могут немедленно приступить к созданию макета функции или библиотеки, которые будут выдавать случайные элементы. Другие будут сидеть сложа руки и начинать размышлять, как справиться с такой задачей. Другие могут сразу запустить Google и начать поиск ответов Stack Overflow.
Если ваш первый ответ был одним из перечисленных выше, то я боюсь, что вы не справились с задачей.
Почему? В конце концов, разработчики разрабатывают. Они создают вещи из кода. Почему выполнение цели разработчика может привести к провалу?
Причина проста. Разработчики никогда не развиваются просто так. В подавляющем большинстве случаев они не являются островами сами по себе. Современные разработчики существуют в экосистеме, где их окружают менеджеры проектов, тестировщики, инженеры по разработке, специалисты по эксплуатации, NOC, бизнес-аналитики и системные аналитики… этот список можно продолжать и продолжать.
Да, код разработчиков. Да, разработчики делают возможным новый бизнес, создавая продукты. Тем не менее, разработчики никогда не должны слепо бежать в одном направлении только потому, что кто-то говорит: «БЕГИТЕ!»
ИТ — это услуга, ориентированная на услуги. Каждый участник обязан обеспечить, чтобы их клиенты, внутренние или внешние, были довольны. Разработчики обычно делают это, делая то, что у них получается лучше всего. Но это не один из тех случаев.
Требования
Представьте, что клиент или продакт-менеджер предъявляет вам вышеуказанное требование. Если вы сразу приложите пальцы к клавиатуре, то в лучшем случае будете крутить колеса, а в худшем станете предметом праведного гнева. Потому что на данный момент вы не представляете, что вы строите.
Но вы, конечно же! Это просто генератор случайных строк, верно? Неправильно, потому что на данный момент у вас нет требований. Какие типы строк вы тоже генерируете? Сколько? Должна ли эта длина быть переменной? Каков более широкий контекст? Самое главное, зачем это нужно покупателю? Этот последний вопрос — лучший способ спасти рассудок, потому что он может пролить свет на эти надоедливые скрытые требования.
Если бы вы сразу начали программировать, вы бы и не догадались, что клиенту на самом деле нужен надежный генератор паролей. Или создатель руководства. Люди сами по себе — острова, когда отсутствие связи служит морем. Я могу гарантировать, что клиент не увидит двусмысленности в этом требовании. «Это сияющий маяк, который четко указывает, что нужно!» — воскликнет этот человек. Но мы уже показали, что это совсем не так.
Хуже того, этот пример до боли очевиден в отношении того, сколько информации отсутствует. Правда в том, что даже если у требования есть непонятные спецификации, оно все равно может скрывать те непокрытые потребности, которые нигде не указаны, но абсолютно должны быть реализованы, чтобы оно увидело свет.
Иногда у вас может быть замечательный БА, чтобы выявить эти невысказанные потребности. Независимо от того, делаете вы это или нет, вы, как разработчик, обязаны задавать вопросы. В конце концов, это повлияет на вашу работу так же сильно, как и отсутствие модульных тестов.
Колеса на автобусе
Но не задавать вопросов — это только один из грехов в этой ситуации. Если вы сразу начнете писать код, то совершите одну из самых серьезных ошибок, которые может совершить разработчик: изобретать велосипед.
Благодаря программному обеспечению с открытым исходным кодом и процветающему сообществу, стоящему за Node, существует более дюжины библиотек, которые именно то, что вам нужно. В нашем примере chancejs — феноменальная утилита, которая создаст для нас много разных типов случайных предметов. Я использовал его во множестве различных проектов, и он еще не разочаровал.
Например, для одного клиента мне пришлось создать обработчик форм, который генерировал случайные данные. Во-вторых, мне пришлось создавать случайные объекты для формирования БД. Вот краткий пример того, как включить шанс в скрипт node.js. Начните с установки шанса с помощью
npm установить -g шансы
После этого включите библиотеку в свой скрипт. Ниже предполагается, что вы используете ES6.
константный шанс = требовать('chancejs').Шанс();
Тогда это просто, как
шанс.имя();
создать случайное имя или
шанс.хэш({длина: 25});
Чтобы получить хороший uuid. Ознакомьтесь с документацией для многих других примеров.
Заключение
Смысл этой статьи не в том, чтобы сказать, что вам следует избегать создания библиотек. В конце концов, у вас может быть уникальное требование, которое не было выполнено. Или вы не можете найти качественную библиотеку, соответствующую вашим потребностям. Я также не призываю вас держаться подальше от проблем с кодом. Они могут стать отличным инструментом для обучения вас новым методам или концепциям, которые сделают вас более сильным разработчиком.
Скорее имейте в виду, что как разработчик вы теперь принадлежите сообществу и, возможно, команде, которой потребуется ваше мнение и понимание. Списываться вслепую служит лишь для того, чтобы лишить окружающих ясности и даже доставить то, что никому не нужно.