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

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



Прежде чем уйти с головой в учёбу, программисту необходимо понять основы интересующей его технологии. Затем нужно сформировать своё видение этой технологии, научиться мыслить её категориями. В результате, если некто начинает изучать React, сначала ему нужно научиться «думать на языке React». А уже после того, как он разовьёт в себе это качество, он сможет осмысленно знакомиться с мнениями других людей и, отбирая самое ценное, развиваться в избранном направлении.

Автор статьи, перевод которой мы публикуем сегодня, хочет поделиться со всеми желающими тем, что ему удалось узнать о React в ходе формирования собственного видения этой технологии, в ходе её изучения и накопления опыта в этой области. Здесь он расскажет о том, что ему удалось понять за год, работая React-программистом, занимаясь в свободное время собственными проектами и делясь своими идеями на одной JavaScript-конференции.

React — это постоянно развивающаяся технология

Так как React находится в процессе постоянного развития, любой, кто хочет освоить эту технологию, должен быть готовым к постоянному поддержанию своих знаний и навыков в актуальном состоянии. Если вы помните анонс React 16.3.0, то знаете о восторге в сообществе программистов, который вызвали новые возможности. Среди них — официальное API Context, API createRef и forwardRef, строгий режим, изменения в жизненном цикле компонентов. Основная команда разработчиков React и все, кто внёс посильный вклад в развитие проекта, проделали потрясающую работу, стремясь усовершенствовать всеми нами любимый фреймворк. Эта работа не останавливается. Так, например, в версии 16.4.0 появилась поддержка событий указателей (pointer events).

Развитие React продолжается, появление новшеств — это лишь вопрос времени. Среди таких новшеств — асинхронный рендеринг, кэширование, множество изменений, ожидаемых в React 17.0.0, и нечто такое, о чём пока ещё никто не знает.

Учитывая вышесказанное, понятно, что если вы хотите оставаться на переднем крае React-разработки, вам необходимо быть в курсе новшеств. Это означает, что вам нужно знать о том, как работают новые механизмы фреймворка, и о том, почему они были созданы. Вам необходимо понимать то, какие проблемы они решают, и то, как они упрощают разработку.

Не бойтесь разбивать свой код на небольшие фрагменты

React основан на компонентах. Это говорит о том, что данную концепцию следует использовать и смело разбивать крупные фрагменты кода на более мелкие части. Иногда простой компонент может состоять всего из 4-5 строк кода, и, в некоторых случаях, это совершенно нормально.

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

// Этот фрагмент кода совершенно понятен, не правда ли?
return (
  [
   <ChangeButton
    onClick={this.changeUserApprovalStatus}
    text="Let’s switch it!"
   />,
   <UserInformation status={status}/> 
  ]
);

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

import ErrorMessage from './ErrorMessage';
const NotFound = () => (
  <ErrorMessage
    title="Oops! Page not found."
    message="The page you are looking for does not exist!"
    className="test_404-page"
  />
);

В вышеприведённом примере применяются статические свойства. Перед нами — чистый компонент, который ответственен за вывод сообщения об ошибке Not Found и ни за что другое.

Кроме того, если вам не хочется, чтобы повсюду в вашем коде встречались CSS-классы и имена классов, я бы порекомендовал использовать стилизованные компоненты. Это способно значительно улучшить читабельность кода.

const Number = styled.h1`
  font-size: 36px;
  line-height: 40px;
  margin-right: 5px;
  padding: 0px;
`;
//..
<Container>
  <Number>{skipRatePre}</Number>
  <InfoName>Skip Rate</InfoName>
</Container>

Если вы опасаетесь создавать слишком много маленьких компонентов из-за того, что вам кажется, что их файлы засоряют папки с материалами проекта, подумайте о том, чтобы по-другому структурировать ваш код. Я использовал для организации материалов фрактальную структуру проекта, и должен сказать, что это — просто замечательно.

Не останавливайтесь на достигнутом после того, как разберётесь с основами

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

Например, если вы находитесь в начале пути React-разработчика, вы можете обнаружить множество непростых на первый взгляд паттернов проектирования, которые вам стоит исследовать. Среди них — Compound Components, High Order Components, Render Props, Smart Components, Dumb Components и много чего ещё (например, рекомендуется освоить технологию профилирования производительности компонентов).

Освойте все эти технологии, и вы поймёте — почему и зачем они используются. В результате их изучения вы обнаружите, что теперь вам удобнее разрабатывать проекты на React.

// Всё это выглядит весьма таинственно?
// На самом деле, всё не так уж и сложно, если в этом разобраться.
render() {
  const children = React.Children.map(this.props.children,
   (child, index) => {
      return React.cloneElement(child, {
        onSelect: () => this.props.onTabSelect(index)
    });    
 });  
 return children;
}

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

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

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

Не стремитесь к чрезмерному усложнению проектов

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

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

Иногда вам может казаться, что используя новейшие технологии и создавая сложный код, вы заявляете всему миру примерно следующее: «Я — не начинающий разработчик, я становлюсь профессионалом. Вот какой код я пишу!».

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

1. Над проектом, который не переусложнён, может работать не только тот, кто понимает устройство этого проекта, но и другие члены команды. В результате задачи разработки, исправления ошибок, тестирования, и многие другие, может решить не только создатель этого проекта.
2. Другие программисты могут понять то, что вы делаете, не тратя слишком много времени на выслушивание ваших разъяснений. Вы сможете ввести их в курс дела за пару минут.
3. Когда основной разработчик, скажем, уходит в двухнедельный отпуск, другие свободно могут взять на себя его задачи, при этом им не придётся просиживать целый рабочий день над тем, что делается в течение пары часов.

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

Рефакторинг — это нормально

Вы, в ходе работы над неким проектом, можете десятки раз менять точку зрения на некоторые вещи, а менеджер проекта может ещё чаще пересматривать свои взгляды. Кто-то критикует то, что сделали вы, и вы, если критика обоснована, начинаете что-то менять; вы критикуете работу других, и они, прислушиваясь к вам, переделывают то, что написали. В результате код приходится постоянно переписывать.

Не стоит воспринимать подобное как нечто негативное. Учитывая то, что программистам постоянно приходится изучать что-то новое, рефакторинг — это совершенно нормально. Развитие — это обычно путь проб и ошибок. И чем чаще некто спотыкается, продвигаясь по этому пути, тем легче ему будет справляться со сложностями и идти дальше.

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

1. Вам не приходится подолгу просиживать с коллегами, объясняя им, как всё работает.
2. Вам не приходится объяснять причины, по которым нечто вышло из строя.
3. Вам не приходится исправлять чужие ошибки.
4. Вам не приходится исправлять ошибки, которые объявились через несколько недель после релиза.
5. У вас, благодаря чёткой организации проверок проекта, появляется время на решение различных задач, не связанных с отладкой неизвестно откуда берущихся ошибок.

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

Любовь к своему делу — основа успеха

Год назад я решил стать более продвинутым React-разработчиком. Мне хотелось, кроме прочего, выступать на различных мероприятиях, делиться радостью узнавания нового с другими людьми.

Я могу всю ночь просидеть за компьютером, занимаясь любимым делом и наслаждаясь каждой минутой происходящего. Дело тут в том, что если человек к чему-то по-настоящему стремится, то, тем или иным образом, всё вокруг помогает ему идти к цели. Например, недавно я впервые выступил на небольшой конференции перед двумя сотнями зрителей.

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

Поэтому я порекомендовал бы каждому спросить себя: «Тебе нравится то, чем ты занимаешься?». Если ответ на этот вопрос отрицателен — найдите то, что вам по-настоящему нравится, что-то такое, о чём вы можете часами говорить, что-то такое, чем можете заниматься дни и ночи напролёт, чувствуя себя при этом совершенно счастливым. Для того чтобы расти и развиваться в любой области, каждому надо найти то, что ему по душе. Человека нельзя заставить добиться успеха в чём бы то ни было. Человек может достичь успеха лишь тогда, когда он сознательно и с удовольствием занимается тем, что ему нравится.

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

Уважаемые читатели! Какими советами, подсказанными опытом, вы могли бы поделиться с начинающими веб-разработчиками?