Когда программирование превратилось в склеивание библиотек
Пару месяцев назад я выступал с докладом о веб-компонентах для технической компании, где у большинства участников не было предыдущего опыта работы с ними. Это была очень веселая и хорошо принятая беседа, завершившаяся более получасовым раундом вопросов аудитории.
Ближе к концу кто-то спросил меня, означает ли это, что мы возвращаемся во времена того, что он называл «спагетти-кодом, подобным jQuery», из-за необработанного кода манипуляции с DOM, который я показал. Я мог видеть, как некоторые другие согласно кивают, и эта реакция действительно заставила меня задуматься.
Судя по всему, код, который не является частью какого-либо фреймворка или библиотеки, а представляет собой то, что мы называем «ванильным JavaScript», воспринимается как плохой и «спагетти-код». Это даже не должно вызывать удивления.
Целое поколение разработчиков начало использовать фреймворки и стартовые наборы, которые поставляются с целым набором зависимостей из коробки. Просто запустите npm install и настройте шаблоны кода в соответствии со своими потребностями.
Хотя это может быть хорошим местом для начала, нам нужно понимать, что программирование - это нечто большее, чем объединение сторонних библиотек.
Я не против зависимостей
Прежде всего позвольте мне прояснить, что я не выступаю против использования зависимостей. Фактически, у меня есть некоторый опыт работы с несколькими интерфейсными фреймворками.
Однако я рекомендую вам спросить себя, действительно ли вам нужны эти зависимости для вашего следующего проекта, прежде чем вы подумаете о том, какие из них использовать.
Это очень важный вопрос, который стоит задать себе. Это вопрос, который, как мне кажется, задают недостаточно, если его вообще задают.
Заблуждение «Не изобретайте колесо заново»
Вы, наверное, слышали это много раз. Как разработчику вам не следует «изобретать велосипед», вместо этого вам следует использовать библиотеку, которая уже выполняет то, что вы пытаетесь создать.
Это хороший совет, например, когда вам нужна ORM базы данных, потому что нет смысла писать ее с нуля, когда уже есть хорошие.
Проблема в следующем: где мы проводим черту, когда решаем, что кодировать сами, а когда использовать стороннюю зависимость?
В 2016 году разработчик пакета left-pad решил удалить все свои пакеты из NPM по юридическим причинам, и этим он почти сломал Интернет. Это было иллюстрацией того, насколько безумной стала зависимость от стороннего программного обеспечения.
Единственная задача left-pad - заполнить левую часть строки нулями или пробелами. Пакет состоит всего из нескольких строк кода, и младший разработчик также может написать его в несколько строк. Фактически, он уже устарел в пользу стандартного String.prototype.padStart(), но от него зависели тысячи проектов.
И становится еще хуже. Пакет isarray состоит всего из четырех строк кода и проверяет, является ли данный аргумент массивом. Конечно, это предназначено для старых браузеров, которые не поддерживают собственный метод Array.isArray(), но это может быть написано буквально одной строкой кода любым разработчиком.
Самостоятельное программирование - это не «изобретать велосипед». На самом деле нет необходимости иметь это как зависимость в вашем проекте.
Мы понятия не имеем, что используем
Тем не менее, люди утверждают, что лучше использовать уже доступные сторонние модули - даже если они очень маленькие - потому что они прошли «боевые испытания» и являются «проверенными решениями».
Вопрос: вы уверены?
Вы знаете, что зависимость - это хорошо проверенное и проверенное решение, или вы просто предполагаете, что это так?
Вы действительно знаете все, что находится в вашей node_modules папке?
Я не знаю, и, вероятно, никто не знает. Честно говоря, вам не обязательно, но, по крайней мере, вы должны подумать о том, что установить в качестве зависимости, а что кодировать самостоятельно.
Вам действительно нужна раздутая библиотека для простых HTTP-вызовов, когда в каждом современном браузере уже есть fetch? Или большую библиотеку синтаксического анализа дат, которую вы можете написать самостоятельно, используя несколько строк кода, и которая только делает то, что вам действительно нужно?
Похоже, что целое поколение разработчиков слишком небезопасно, чтобы писать и использовать свой собственный код, и вместо этого они прибегают к склеиванию библиотек, которые, по их предположению, хорошо протестированы и не содержат ошибок.
Но это ложное чувство безопасности.
Как мы стали такими незащищенными?
Почему мы, разработчики, так боимся доверять нашему собственному коду и предпочитаем использовать чужой код, который думаем лучше и безопаснее?
В конце концов, эти люди, публикующие свой открытый исходный код на Github, также являются разработчиками, как и мы. Они тоже несовершенны и могут писать код с ошибками. Однако мы предпочитаем доверять им, а не себе.
Я понимаю, что вы не хотите, например, писать такую библиотеку, как RxJS или React. Это большие библиотеки, которые существуют уже много лет, имеют много участников и хорошо протестированы. Я бы не рекомендовал реализовывать их заново, если вы не хотите извлекать уроки из этого.
Но для меньшей функциональности, которую вы можете легко запрограммировать самостоятельно и полностью адаптировать к своим потребностям, я бы рекомендовал написать это самостоятельно. По крайней мере, вы можете легко изменить и исправить его при необходимости.
Я полагаю, что неуверенность разработчиков в написании собственного кода объясняется годами использования библиотек и фреймворков, которые скрыли от нас родную платформу JavaScript. Это уже началось с jQuery и ухудшилось с появлением таких фреймворков, как Angular и React.
Это абстракции, которые по своей природе воспринимаются как сложные. Из-за этого разработчики склонны использовать их как черные ящики.
Опять же, я не противник фреймворка и вижу ценность, которую они приносят. Но теперь кажется, что есть целое поколение разработчиков, которые знают только, как программировать с использованием фреймворка, и практически не знают базовую платформу. Они не знали бы, как работать с необработанным DOM, потому что они почти не сталкивались с ним, если вообще когда-либо.
Я участвовал в нескольких вечнозеленых проектах, где первым вопросом было какую структуру мы должны использовать, а не , если мы вообще должны ее использовать. По умолчанию предполагалось, что необходим фреймворк, а главным аргументом было то, что фреймворк предоставит все, что нам нужно, и мы не должны изобретать колесо.
Ирония заключается в том, что многие из этих людей не обладали достаточными знаниями о нативной платформе, чтобы сказать, был ли выбранный фреймворк правильным выбором.
Понятно, что сложность этих фреймворков пугает, особенно для начинающих разработчиков. Они будут использовать их как черные ящики, не понимая, как они работают.
Фреймворки тоже не поощряют это, поскольку их задача - упростить программирование, скрывая низкоуровневые детали и API.
Это создает зависимость от фреймворка, что, в свою очередь, не дает разработчикам уверенности в том, что они могут сами кодировать.
Использование зависимостей - аутсорсинг вашего бизнеса
Когда вы используете зависимость в своем приложении, вы в основном передаете эту часть на аутсорсинг другому разработчику, поэтому вам лучше быть уверенным, что этот человек выполняет свою работу хорошо.
Если у вас есть бизнес и вы поручаете обслуживание клиентов какой-либо другой компании, у вас будут большие проблемы, если они все испортят. Что, если у них другое представление о том, что такое хорошее обслуживание клиентов?
Вы, вероятно, не позволите этому случиться, и вы должны относиться к зависимостям в вашем приложении таким же образом. Это не означает, что вам нужно читать исходный код всех ваших зависимостей, но, по крайней мере, вы должны иметь твердое представление о том, как это работает.
Знай фонд
Но для этого вы должны сначала хорошо разбираться в программировании на обычном JavaScript, поскольку это основа всего.
Фреймворки переднего плана определенно приносят пользу, но также имеют сложность и накладные расходы. Я прошел через боль, изучая и внедряя несколько фреймворков, и могу сказать вам, что вам нужно убедиться, что ваши усилия того стоят.
Нет причин не использовать родную платформу, и вы будете удивлены, увидев, что она может предложить в наши дни.
Не попугайте, говоря, что нельзя изобретать велосипед. Сначала изучите фундамент, а затем затем решите, действительно ли вам нужна эта библиотека или фреймворк.
Вы станете лучшим разработчиком для этого.
