Обычно начало работы с новой технологией — это не так уж и просто. Новичок попадает в бескрайнее море учебных руководств и статей. При этом за каждым из подобных материалов стоит личное мнение его автора, а каждый автор заявляет, что именно его устами глаголет истина.
С точки зрения здравого смысла понятно, что далеко не все статьи, опубликованные в интернете, способны принести реальную пользу, поэтому тем, кто пытается освоить что-то новое, приходится оценивать публикации в попытке найти ответ на вопрос о том, стоит ли тратить на них своё время.
Прежде чем уйти с головой в учёбу, программисту необходимо понять основы интересующей его технологии. Затем нужно сформировать своё видение этой технологии, научиться мыслить её категориями. В результате, если некто начинает изучать 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, сформируйте у себя понимание этой технологии, и, если увидите, что то, что происходит в вашем проекте, идёт вразрез с тем, что вы поняли, будьте готовы защитить свою точку зрения.
Иногда вам может казаться, что используя новейшие технологии и создавая сложный код, вы заявляете всему миру примерно следующее: «Я — не начинающий разработчик, я становлюсь профессионалом. Вот какой код я пишу!».
Честно говоря, я сам был таким в начале карьеры разработчика. Но со временем приходит понимание того, что код, который написан без стремления что-то кому-то доказать, код, в котором технологии не используются только потому, что они могут быть в нём использованы, без серьёзных причин прибегать к этим технологиям, значительно облегчает жизнь любого разработчика. Вот в чём это выражается:
- Над проектом, который не переусложнён, может работать не только тот, кто понимает устройство этого проекта, но и другие члены команды. В результате задачи разработки, исправления ошибок, тестирования, и многие другие, может решить не только создатель этого проекта.
- Другие программисты могут понять то, что вы делаете, не тратя слишком много времени на выслушивание ваших разъяснений. Вы сможете ввести их в курс дела за пару минут.
- Когда основной разработчик, скажем, уходит в двухнедельный отпуск, другие свободно могут взять на себя его задачи, при этом им не придётся просиживать целый рабочий день над тем, что делается в течение пары часов.
Люди хорошо относятся к тем, кто не усложняет им жизнь. Таким образом, если вы стремитесь к тому, чтобы в команде вас уважали, и к тому, чтобы быть на хорошем счету у начальства, старайтесь писать код для команды, а не для себя. В результате вы станете человеком, с которым легко и приятно работать.
Рефакторинг — это нормально
Вы, в ходе работы над неким проектом, можете десятки раз менять точку зрения на некоторые вещи, а менеджер проекта может ещё чаще пересматривать свои взгляды. Кто-то критикует то, что сделали вы, и вы, если критика обоснована, начинаете что-то менять; вы критикуете работу других, и они, прислушиваясь к вам, переделывают то, что написали. В результате код приходится постоянно переписывать.
Не стоит воспринимать подобное как нечто негативное. Учитывая то, что программистам постоянно приходится изучать что-то новое, рефакторинг — это совершенно нормально. Развитие — это обычно путь проб и ошибок. И чем чаще некто спотыкается, продвигаясь по этому пути, тем легче ему будет справляться со сложностями и идти дальше.
Однако, для того, чтобы рефакторинг не превращался в кошмар, рекомендуется достаточное внимание уделять тестам. Не стесняйтесь тестировать всё, до чего можете дотянуться. Пожалуй, каждый программист либо уже столкнулся, либо ещё встретится с ситуацией, в которой хорошие тесты помогут ему сэкономить массу времени. А если вы, как и многие другие, полагаете, что тесты — это пустая трата времени, попытайтесь воспринимать их не так, как прежде. А именно, вот преимущества, которые получает разработчик и его команда от хороших тестов:
- Вам не приходится подолгу просиживать с коллегами, объясняя им, как всё работает.
- Вам не приходится объяснять причины, по которым нечто вышло из строя.
- Вам не приходится исправлять чужие ошибки.
- Вам не приходится исправлять ошибки, которые объявились через несколько недель после релиза.
- У вас, благодаря чёткой организации проверок проекта, появляется время на решение различных задач, не связанных с отладкой неизвестно откуда берущихся ошибок.
На самом деле здесь приведён лишь небольшой список преимуществ, которые получают программист и его сослуживцы от хорошо организованной системы тестирования проектов.
Любовь к своему делу — основа успеха
Год назад я решил стать более продвинутым React-разработчиком. Мне хотелось, кроме прочего, выступать на различных мероприятиях, делиться радостью узнавания нового с другими людьми.
Я могу всю ночь просидеть за компьютером, занимаясь любимым делом и наслаждаясь каждой минутой происходящего. Дело тут в том, что если человек к чему-то по-настоящему стремится, то, тем или иным образом, всё вокруг помогает ему идти к цели. Например, недавно я впервые выступил на небольшой конференции перед двумя сотнями зрителей.
За это время я вырос как React-разработчик, узнал много нового. В частности, это касается различных паттернов проектирования, принципов разработки проектов, внутренних механизмов фреймворка. Теперь я могу общаться на темы, которые раньше казались мне недоступными, и, более того, могу учить других тому, на что раньше и взглянуть не решался. При этом сегодня я чувствую тот же восторг и удовольствие, что и год назад.
Поэтому я порекомендовал бы каждому спросить себя: «Тебе нравится то, чем ты занимаешься?». Если ответ на этот вопрос отрицателен — найдите то, что вам по-настоящему нравится, что-то такое, о чём вы можете часами говорить, что-то такое, чем можете заниматься дни и ночи напролёт, чувствуя себя при этом совершенно счастливым. Для того чтобы расти и развиваться в любой области, каждому надо найти то, что ему по душе. Человека нельзя заставить добиться успеха в чём бы то ни было. Человек может достичь успеха лишь тогда, когда он сознательно и с удовольствием занимается тем, что ему нравится.
Если бы я мог вернуться на год назад и встретить там самого себя, я сказал бы себе именно это для того, чтобы подготовить себя к большому и интересному пути, который меня ждёт.
Уважаемые читатели! Какими советами, подсказанными опытом, вы могли бы поделиться с начинающими веб-разработчиками?
Автор: ru_vds
