Прежде чем начать, я хочу отметить, что я большой поклонник stackoverflow.com. На самом деле, я часто использовал его, делая первые шаги в веб-разработке несколько лет назад в качестве разработчика javascript, и я очень благодарен за это. Я думаю, это звучит довольно знакомо для большинства из вас, верно? Поэтому мы все согласны с тем, что это чрезвычайно полезно, и сообщество, стоящее за ним, просто фантастическое. Мы можем найти почти все, что попросим, ​​и это слишком много раз спасало положение для большинства из нас.

Держу пари, вам интересно, использую ли я его до сих пор. Да, конечно. Я использую его по-другому, чем раньше. Теперь это больше не мой первый выбор, когда я что-то ищу. На самом деле я использую его редко, так как мое мышление и мой рабочий процесс сильно изменились. Быстро найти фрагмент и перейти к следующему заданию — неправильный способ делать что-то инженеру. Как насчет реального понимания? Как насчет глубокого обучения? Вы действительно заинтересованы в том, чтобы копировать и вставлять вещи, созданные другими разработчиками, на всю жизнь или вы хотите научиться решать проблемы и разрабатывать решения самостоятельно? Хм, а смысл? Позволь мне объяснить.

Как мы можем найти свой путь при использовании новых пакетов/технологий?

Самое первое, что вы должны сделать, пытаясь применить новый пакет npm или изучая что-то новое, — это внимательно прочитать документацию. Иногда вам, возможно, придется прочитать его более одного раза, чтобы понять, что происходит на самом деле. В настоящее время команды создают довольно солидные документы, используя уценку и включая множество реальных примеров, поэтому нет никаких оправданий, чтобы пропустить это.

Когда вы имеете дело с более крупной библиотекой, такой как ReactJS, лучше купить книгу или зарегистрироваться для участия в учебном пособии или семинаре, чтобы сделать серьезные шаги в освоении этой новой технологии. Построение прочного фундамента продвинет вас очень далеко вперед.

Шли годы, и я понял, что реальное понимание гораздо важнее, чем запоминание, поэтому решил инвестировать соответственно. Это всегда окупается.

Однако я должен признать, что нет лучшей документации, чем сам код. В большинстве случаев вы также можете погрузиться в код репозитория, чтобы проверить структуру, открытые методы, параметры по умолчанию и т. д. Лично мне нравится изучать, как другие разработчики делают свои вещи и структурируют свои классы и методы. Я помню, как делал это год назад, изучая Redux, и все стало обретать смысл, когда я проверил, что происходит под капотом.

После выполнения этих шагов вы также можете проверить примеры из реальной жизни в репозитории пакета, а затем вы можете попробовать что-то самостоятельно. Очень важно запачкать руки и ознакомиться с тем новым пакетом, который вы пытаетесь внедрить. Это правильный порядок изучения/использования чего-то нового, а не наоборот. Как бы ни возникло у вас искушение начать использовать IDE до прочтения какого-либо файла README, не делайте этого. Если вы это сделаете, то рано или поздно вы начнете ходить туда-сюда, тратя впустую свое время.

Где мы можем найти решения проблем с блокировщиками, с которыми мы сталкиваемся?

Бывают моменты, когда возникает проблема с блокировщиком, все может стать ужасно. Что нам делать тогда? Вы должны начать искать проблемы с пакетами, пытаясь увидеть, сталкивались ли другие люди с такими же проблемами. В большинстве случаев это правда, поэтому тикет уже создан. Надеюсь, кто-то уже отправил запрос на слияние. Это совершенно нормально, и это именно то, как все должно работать в разработке с открытым исходным кодом.

К сожалению, в некоторых случаях вы не можете найти соответствующий тикет, поэтому вам нужно создать новый самостоятельно. После этого самое время использовать stackoverflow и продолжить поиск. Если вы найдете ответ, очень важно вернуться и поделиться им в своем тикете, чтобы помочь другим разработчикам.

Иногда все еще хуже, потому что вы можете понять, что этот пакет не обновлялся месяцами. В общем, это означает, что сопровождающие потеряли интерес, или они слишком заняты, или, может быть, этот пакет не так популярен. Должны ли мы использовать это в первую очередь? Думаю, нет. Я всегда встревожен, когда вижу, что последний коммит был сделан 6 месяцев назад или что пакет имеет что-то вроде 8 звезд. Это то, что я проверяю перед установкой нового пакета, чтобы избежать возможных проблем в ближайшем будущем.

Пришло время искать альтернативу, но перед этим вам лучше создать тикет, чтобы поделиться своими мыслями или попросить внести некоторые изменения и улучшения. Не бойтесь и не желайте этого. Поскольку мы полагаемся на проекты с открытым исходным кодом, очень важно заботиться об их развитии, даже если мы не являемся частью группы сопровождающих.

Бывают случаи, когда вы не можете найти подходящий пакет. Что вы должны сделать? Вы можете разветвить этот предыдущий пакет, который вы нашли, и отправить запрос на слияние, если изменений, которые вам нужны, не так много. Нет смысла изобретать велосипед, когда есть основы. Если это не так, то, вероятно, вы можете начать с нуля и создать свой собственный свежий пакет.

Приведу пример из реальной жизни. Я использовал компонент с открытым исходным кодом ReactJS для рендеринга предварительного загрузчика svg. Мне понравился этот пакет, потому что он предлагал большое разнообразие вращающихся иконок svg. Однажды я внес некоторые изменения в свою кодовую базу и понял, что добавленные классы через className на самом деле не отображаются. Что я должен делать? Я проверил код этого компонента и обнаружил, что className даже не передается в качестве свойства. Что это значит? Этот компонент вообще не ожидал получить className, поэтому я тщетно пытался передать его. Так просто. Я просмотрел его выпуски на Github и обнаружил недавний выпуск, в котором упоминается именно эта проблема. Однако я не смог найти запрос на слияние. Без проблем. Я отправил новый, чтобы решить эту проблему.

Следуйте строгому шаблону и остановите спонтанный глобальный поиск

Итак, теперь, когда мы шаг за шагом объяснили все это и поняли, насколько важно использовать пакетную документацию, код и систему тикетов, чтобы достичь более глубокого понимания и помочь пакетам, которые мы используем, развиваться дальше, давайте посмотрим на другой пример из реальной жизни. . На днях я сидел рядом с коллегой. Его задачей было добавить новое промежуточное ПО Redux. Он создал ветку, а затем сразу перешел к stackoverflow, чтобы узнать, как ему настроить applyMiddleware(), чтобы применить более 1 промежуточного программного обеспечения. В его рабочем процессе поиск был самым первым и последним шагом. Что Вы думаете об этом? Вы видите, куда я клоню? Я твердо верю, что это было плохим решением.

Redux имеет великолепную документацию с хорошо объясненными примерами. Даже если он не смог найти ответ в документах (сомневаюсь, что это произойдет, но все же), то он должен знать, что правда в самом коде:

Вы видите это? Вот как выглядит метод applyMiddleware(), и реальный ответ кричит перед нашим лицом с этим оператором распространения.

Заключение

Как вы знаете, такие платформы, как stackoverflow, довольно мощные и чрезвычайно полезные, но они никогда не должны быть нашим первым шагом при попытке реализовать новую функциональность или решить проблему. Чем больше мы развиваемся как инженеры, тем больше нам нужно получить настоящее понимание. Настоящее понимание является ключевым фактором, позволяющим подняться по карьерной лестнице, получить лучшую работу, больше зарабатывать, жить достойной жизнью, добиться реального прогресса. Мы не сможем достичь настоящего понимания, если перестанем читать или перестанем играться с новыми технологиями и кодом пакетов. Копирование и вставка материалов поможет нам быстро заработать, но таким образом мы ничего не создадим. В большинстве случаев это фрагменты, с которыми мы не совсем знакомы, но мы знаем или думаем, что они работают, так как некоторые ребята дали зеленый свет. Это то, что должен делать инженер? Новичок может сделать это, пытаясь найти свой путь, но настоящий инженер должен однажды перестать это делать. Это тупик.