Давайте просто согласимся с одним! Существует множество хороших разработчиков.
Однако и плохих тоже немало. И я с уверенностью могу сказать, что вы уже сталкивались и с теми, и с другими. Если нет, то, возможно, вам просто повезло. Но, скорее всего, вы просто не были в отрасли долгое время.
Или, возможно, просто недостаточно внимательно смотрели. Возможно, вы не знаете, как их отличить. Вы не знаете, какие черты следует искать в отличном разработчике. И не знаете, как определить плохого разработчика. В любом случае, нет причин для беспокойства. Потому что сегодня я научу вас, как отделить лучших от остальных.
Я довольно долгое время был рядом с разработчиками. И мне выпала честь побывать в обоих мирах. Я видел лучших и видел худших. Но, будучи оптимистом, я решил сосредоточиться на позитивном.
Я попытался вспомнить все то, что произвело на меня впечатление в хороших React-разработчиках, и перечислить их в этой статье (без особого порядка). Глядя на эти черты, вы сможете быстро понять, кто является экспертом, а кто еще учится.
Итак, не теряя времени, давайте начнем с первого.
1. Он оценивает каждую зависимость
Менеджер пакетов node просто великолепен. Он поставляется со всеми замечательными пакетами, созданными сообществом. Если бы не npm, я не думаю, что JavaScript был бы на том месте, на котором он находится сегодня. Если вы столкнулись с какой-либо проблемой, есть большая вероятность, что кто-то другой был в том же месте. Они уже реализовали решение. И они были добры поделиться им с вами в виде пакета npm.
Нет нужды говорить, что npm - это огромный актив для разработки. Однако он может парализовать ваше мышление. В итоге вы будете решать каждую проблему с помощью нового пакета. И в итоге ваш пакет вырастет в размерах, как культурист на стероидах.
В свое оправдание я не говорю, что импортировать пакет для решения проблемы - это плохо. В этом нет ничего плохого. Но действие, которое отделяет хороших разработчиков от плохих, - это проведение исследований.
Новички просто импортируют любой пакет, не задумываясь. Если он сработал, они просто переходят к другой проблеме. С другой стороны, программисты с большим стажем будут оценивать пакет. Они проверят лицензирование или сообщество, стоящее за ним. Они также используют такие инструменты, как bundlephobia, чтобы проверить размер и детали пакета.
Можете ли вы вспомнить кого-то, кто занимается подобными вещами? Изучайте их, учитесь у них!
2. Она использует проверку типов
Должен признаться. Когда я начал изучать React, я увидел, что многие люди используют проверку типов. Я знал, для чего нужны PropTypes, но не понимал, зачем.
Я считал, что вся цель JavaScript заключается в том, чтобы не заботиться о типах. Но когда я начал работать над более сложными проектами. И приобретая все больше реального опыта, я быстро понял, что проверка типов - мой друг. И она также необходима для создания стабильного и свободного от ошибок продукта.
PropTypes быстро стал моим хорошим другом, но наша дружба была немного шаткой. Я заметил, что у нас есть проблема. Я мог видеть ошибки типов только при отрисовке компонентов. Поэтому их было очень легко пропустить.
В глубине души я знал, что Typescript решит эту проблему раз и навсегда. И когда я заметил, что все крупные компании начинают его внедрять. Я понял, что был прав. Typescript - это то, что нужно.
Вам не нужно изучать Typescript, чтобы стать отличным разработчиком React. Но вы должны использовать какую-то форму проверки типов. И вы должны использовать ее правильно. Использование Typescript или PropTypes не сделает вас хорошим разработчиком волшебным образом. Вам нужно убедиться, что вы правильно набираете текст (что может быть самостоятельным руководством).
Для начала постарайтесь следовать этим простым правилам.
Не используйте в Typescript
Используйте PropTypes.shape вместо PropTypes.object
Используйте PropTypes.arrayOf вместо PropTypes.array
3. Он понимает бандлеры
Вы когда-нибудь видели, как разработчики вносят изменения в конфигурацию Webpack? Давайте предположим, что они великолепны. Иначе они даже не стали бы заглядывать в этот файл. Я не думаю, что бандлеры сложно изучить, но поначалу они могут быть пугающими. И если кто-то чувствует себя уверенно, заглядывая в этот файл конфигурации, он, вероятно, знает, что делает.
Однако нужно ли вам знать, как они работают? Скорее всего, нет, вы можете относиться к ним как к "черному ящику". В конце концов, такие инструменты, как CRA, облегчают вам начало работы без нулевой конфигурации. Но по мере того, как вы становитесь более опытным, вы склонны искать улучшения и оптимизации в своем рабочем процессе.
А для этого вам придется заглянуть под капот. Но не волнуйтесь, как вы быстро поймете, освоить их не так уж сложно. Такие инструменты, как Webpack или Rollup, очень хорошо документированы. А изменить что-то в конфигурации - дело одной-двух строк.
Если вы хотите совершенствоваться как разработчик, я настоятельно рекомендую начать изучать бандлеры.
4. Она не определяет функции внутри Render
Я с уверенностью могу сказать, что вы определили хотя бы одну функцию внутри render. Я знаю, что так и есть, но каждый раз, когда я это делаю, у меня возникает странное чувство. Что-то было не так.
В некотором смысле, в этом нет ничего плохого. По крайней мере, не при использовании в простом компоненте. Но когда ваши компоненты становятся все сложнее. Лучше, чтобы все функции были определены вместе. Не пряча их внутри функции рендеринга. Поступая таким образом, вы отделяете логику отображения от функциональной логики. И, в конечном счете, вы сделаете свой компонент гораздо более легким для чтения.
Ваши коллеги будут любить вас за это.
5. Он последовательный
Есть одна вещь, которую я больше всего люблю в React. Он не подвержен сомнениям. И хотя это можно рассматривать как преимущество, за это приходится платить. Затраты на то, чтобы делать одно дело, используя разные подходы. Именно это может быстро создать некоторые проблемы. Особенно когда несколько человек работают над одним проектом.
Что отличает хороших разработчиков React от плохих, так это то, что они последовательно используют одни и те же подходы. Они пишут компоненты определенным образом, они обрабатывают состояние определенным образом. Каждая парадигма обрабатывается с помощью одного и того же подхода, снова и снова. Нет необходимости говорить о том, что вам будет очень приятно разбираться в кодовой базе такого типа.
Но великие разработчики React даже не используют одни и те же паттерны последовательно. Они идут на шаг дальше. Они следят за тем, чтобы тот же уровень последовательности поддерживался во всем проекте. Иногда это может быть болью в заднице. Но в долгосрочной перспективе ваш проект будет легче поддерживать.
6. Она не смешивает слои приложения
Вы когда-нибудь заглядывали внутрь компонента и сразу пугались? Вы обнаруживали, что уставились на код, не понимая, что происходит. Скорее всего, этот компонент заботился о множестве вещей.
Следил за состоянием, обрабатывал бизнес-логику, и пока мы все это делаем, давайте также получим данные.
Такими компонентами очень сложно управлять. Но еще важнее то, что их трудно понять. Возможно, кто-то понимал их во время кодирования. Но если посмотреть на них пару месяцев спустя, то это уже совсем другая история.
Хорошие разработчики понимают архитектуру. Они знают, как мыслить отдельными блоками. Каждый блок архитектуры должен иметь конкретную цель. Вам когда-нибудь советовали разделить бизнес-логику, управление состояниями или выборку данных? Что ж, человек, который сказал вам это, был отличным разработчиком React.
7. Он сохраняет простоту
Простоту можно объяснить как искусство не усложнять вещи. Для примера, в JavaScript очень легко писать изящные однострочные фразы. Поначалу они могут выглядеть хорошо. И вы можете поверить, что ваши коллеги будут проповедовать ваши навыки. Просто потому, что вы можете писать такие односложные фразы. Но на самом деле это не так.
Односложные фразы экономят место, с этим не поспоришь. Но в долгосрочной перспективе они делают код трудночитаемым. Просто посмотрите на эти два примера кода. Они оба делают одно и то же. Но один из них проще для понимания. Как вы думаете, какой из них легче?
8. Она знает продвинутые паттерны
React имеет очень быструю кривую обучения. Просто используя один из его простейших API или концепций, вы можете достичь удивительных вещей. Вам даже не нужно изучать продвинутые паттерны. И все равно вы можете создавать потрясающие вещи. Но значит ли это, что вам не нужно изучать продвинутые шаблоны?
В React есть такие продвинутые концепции, как контекст, порталы, составные компоненты или реквизиты рендеринга. И они включены в библиотеку не просто так. Они там, чтобы помочь вам решить ваши проблемы. Однако, отказываясь изучать их, вы ограничиваете себя. И ограничиваете потенциал своего приложения.
Великие разработчики React знают эти паттерны вдоль и поперек. И они знают свои правильные приложения. Вам может показаться, что эти паттерны сложны. Но на самом деле они очень хорошо документированы и просты для понимания. Все, что вам нужно сделать, это проявить немного инициативы. И начать изучать продвинутый раздел React Docs.
Заключение
Наша работа как разработчиков заключается в том, чтобы обеспечить выполнение работы. Но есть одна вещь, которая отличает лучших от остальных. Великие разработчики будут следить за тем, чтобы работа была сделана, но их также будет волновать то, как она сделана.
Все качества, упомянутые в этой статье. Они помогают убедиться в том, что разработка идет гладко. И что все члены команды хорошо проводят время, работая над проектом.
Я не говорю, что вы должны обладать всеми этими качествами. И я также не говорю, что нет больше качеств, которые делают отличного разработчика. Но если вы знаете кого-то, кто делает хотя бы половину из перечисленного, то, скорее всего, он хорош. А если вы делаете их сами, то, скорее всего, вы тоже отличный разработчик.