для написания быстрого кода разработчик должен

Разработчик Bitrix Framework. Программирование

1. Можно ли сделать сайты в разной кодировке по системе многосайтовости?

+ Нет. Все сайты на одном ядре должны быть в одной кодировке.
— Да. Требуется дополнительная настройка системы.

2. При программировании в Bitrix Framework нельзя:

1. редактированием шаблона самого сайта и файлов CSS
2. редактирование страницы сайта
3. редактирование шаблонов компонента и файлов CSS компонента, либо изменение вывода данных с помощью файлов result_modifier.php и component_epilog.php
4. использование обработчиков событий
5. кастомизация компонента и разработка собственного компонента (модуля)

4. Оптимизацию сайта необходимо начинать с

— включения автокеширования и управляемого кеширования
+ поиска основных узких мест
— удаления всех неиспользуемых модулей
— получения оценки производительности сервера в мониторе производительности
— анализа настройки компонентов и модулей

5. Когда лучше начинать использовать кеширование:

— с самого начала разработки сайта
— на начальном этапе эксплуатации сайта, пока он не вышел на планируемые нагрузки
+ при разработке веб-сайта после того как обеспечена наиболее оптимальная работа с базой данных с выключенным кэшированием
— после того как сайт «упадет» в первый раз
— при выходе сайта на пиковые нагрузки

6. Основные методы достижения оптимальной производительности

— увеличение мощностей за счет разворачивания веб кластера
+ кеширование «узких» мест
— использование собственных запросов в БД (более простых)
+ изменение логики для избавления от лишних и тяжелых запросов
— увеличение буферов базы данных
— использование стандартных компонентов везде, где возможно
+ ограничение выбираемых полей в запросах АПИ

7. Основные ошибки в программировании, вызывающие проблемы в производительности:

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

+ при выборке разделов без необходимости включается подсчет числа элементов
— в настройках компонентов устанавливается малое время кеширования
+ при написании своих компонентов не ограничивается кеш методом SetResultCacheKeys
— не включают html кеширование перед сдачей проекта клиенту
— использование комплексных компонентов вместо простых
+ в result_modifier для каждого элемента дополнительные поля выбираются дополнительным запросом
+ чтобы получить число элементов делается полная выборка с подсчетом средствами php

8. Файлы, к которым нельзя обращаться напрямую, должны:

+ содержать в начале следующий код
— иметь уровень прав 0755
— располагаться вне системной папки /bitrix

9. Для написания быстрого кода разработчик должен:

+ понимать, какие системные действия выполняют АПИ функции
— разбивать большие товарные каталоги данных на несколько инфоблоков
+ проектировать структуру данных исходя из последующих задач по выборке и фильтрации данных, а не только из простоты интерфейса
— использовать кеширование везде, где это возможно
+ знать, как работают инструменты отладки в Битриксе
+ ограничивать объём данных в кеше
+ использовать кеширование везде, где это необходимо

10. Перед сдачей проекта необходимо протестировать его с помощью:

+ инструмента Монитор качества
— инструмента Проверка сайта
— модуля Монитор производительности

11. Оптимизировать работу с БД можно:

— созданием прямых запросов к БД
+ правильным проектированием структуры данных, выбор связей и их реализация средствами системы инфоблоков

12. Файл init.php:

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

13. Bitrix Framework позволяет использовать следующие способы хранения кеша:

— в файлах, а также с использованием memcached, но только при установленном модуле «Веб-кластер»
— только в файлах
+ как в файлах, так и с использованием memcached
+ как с использованием memcached, так и APC

Источник

Что такое хороший код, или как стать востребованным разработчиком

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

Начну, пожалуй, с философии, а именно, со слов Сократа: «Вот вам мой совет — никогда не слушайте ничьих советов».

Уверен, что вопрос «Что такое хороший код?», возник с самого начала появления такой отрасли как программирование. И в процессе становления этой индустрии критерии оценки довольно серьезно менялись. Вот некоторые из них:

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

Я занялся программированием более 20 лет назад и честно пытался придерживаться правил написания хорошего кода, которые были актуальны на тот период времени. Только вот в чем фишка: как бы я ни старался, меня не покидало ощущение, что я написал нехорошо и можно сделать лучше. И я старался снова, осваивал новые технологии, некоторые канули в лету, некоторые развились настолько, что стали иметь мало общего с первоначальным прототипом, и все равно я так и не получил 100% уверенности, что да — этот код написан хорошо. И как оказалось, причина этому довольно проста. Хорошего кода в классическом понимании не существует, потому что невозможно угодить всем и вся. Но в процессе поиска ответа на вопрос, как научиться писать хороший код, я получил ответы на множество других вопросов и, что самое важное для программиста — это профессиональный опыт и знания. И я готов поделиться своим опытом в своих статьях.

И вот первый совет: если хотите быть профессиональным разработчиком, готовьтесь к тому, что придется учиться постоянно.

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

Легко масштабируемый продукт — это продукт, на внесение изменений в который уходит минимум средств (под средствами понимаются любые трудозатраты: будь то труд/ часы разработчика или тестировщика, время, затрачиваемое на управление проектами и даже время на коммуникацию!)

Разобрались с первым, правильно написанный код — это код, который легко масштабируется.
Примечание: у любого правила есть исключения, и на моем опыте они выглядят следующим образом. У кода (программы) существует два основных критерия: первый — это быстродействие, второе — масштабируемость. Так вот добиться их одновременно — пустая трата времени так как они, как правило, противоречат друг другу. Часто намного дешевле увеличить быстродействие с помощью добавочного железа, чем нанять группу разработчиков, которые оптимизируют программу, при том что при оптимизации увеличивается вероятность насаживания новых багов и т.д., и, наверное, самый главный плюс — это управляемость кода.

Совет второй — ваша задача как разработчика, это понять, что нужно заказчику. Чем точнее вы это поймете, тем точнее вы это реализуете.

Чем быстрее и гармоничнее происходит процесс, тем более важной частью команды Вы становитесь:

• Программирование — это командный вид отрасли, если хотите преуспеть в ней, то с этим придется считаться;

• Если вы думаете, что вы самый умный программист, а все остальные программисты тупые, то советую переехать из Антарктиды и прекратить общаться с пингвинами. Допускаю, что они не очень сильны в этой области, но, если вы все-таки находитесь в цивилизации и являетесь сотрудником маленькой компании, тогда вперед в большую. Уверяю на 100% вас там ждут, правда, вас проверят на наличие знаний и спрашивать о них будут не пингвины;

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

Первое. Продукт должен быть доставлен в срок. Гениальный программист никогда не соблюдает сроки, и причина проста: он ВСЕГДА пытается найти наилучшее решение, не понимая, что лучшее — враг хорошему.

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

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

Четвертое. Гениальный программист не понимает, что, если в контроле «КНОПКА» обнаруживается текст «КНОПКО» — для заказчика это баг.

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

Как отличить хороший код от плохого?

По сигнатуре кода. В большинстве случаев хороший код от плохого отличается логикой и архитектурой. Используйте в разработке принципы SOLID и всегда их придерживайтесь.

Что нужно всегда помнить при разработке программ?

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

Сколько и чему нужно учиться чтобы стать востребованным (и хорошо оплачиваемым) разработчиком?

Текст объявления: «Нужен личный водитель до 20 лет с навыками эксперта по рукопашному бою, умению пройти тренировочный рубеж спецназа ГРУ за минуту в водолазном скафандре, при этом поджарив одновременно 10 пирожков на одной сковородке». Примерно так обычно описываются должностные обязанности. Но это совершенно не значит, что вам все это нужно выполнять. В требованиях, как правило, указан максимум. Выделите из всего круга то, что вы знаете и умеете, добавьте немного артистизма и красок, и вперед — убеждать наших менеджеров по персоналу. Но прежде чем это сделать, все-таки оцените трезво свои знания. А то у некоторых есть один очень хороший симптом под названием «Я знаю очень много», который сразу говорит о том, что вы обладаете посредственным багажом знаний. С другой стороны, если у вас большое количество вопросов и вы начинаете понимать, как мало вы знаете, то это уже показатель, что ваш багаж знаний солидный и можно претендовать на уровень разработчика, а не джуниора.

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

• достичь уровня начинающего разработчика (junior) вполне можно за 6 месяцев;
• достичь уровня разработчика (developer) — за 12-18 месяцев;
• продвинутого разработчика (key developer) — 2-5 лет;
• экспертного уровня(seignior) — от 7 лет и выше.

С чего начать?
В качестве ответа на этот вопрос хорошо подходит высказывание Лао-Цзы: «Даже самое долгое путешествие начинается с первого шага».

Источник

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

Программировать быстро — это легко! Так считает инженер-программист компании Google, который все публикации в своем блоге подписывает лаконичным «Макс». Макс также работает главным архитектором, комьюнити-менеджером и релиз-менеджером в Bugzilla Project. Мы в Alconost впечатлились и перевели его советы о том, можно ли как научиться программировать с космической скоростью.

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

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

Теперь давайте разберемся, как, собственно, стать быстрее? Может, это врожденное магическое умение? Надо ли быть «умнее» других, чтобы быть быстрым?

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

Всякий раз, когда замечаете, что топчетесь на месте в размышлениях, знайте: что-то пошло не так.

Это может звучать невероятно, но работает исключительно хорошо. Задумайтесь: когда вы сидите перед вашим редактором, но работа идет небыстро, потому ли это, что у вас низкая скорость набора? Я сомневаюсь: «слишком много набирать» — редкая проблема программистской производительности. Паузы, когда вы не набираете, — вот что все замедляет. А чем обычно заняты в таких паузах разработчики? Пытаются перестать думать — может быть, о проблеме, об инструментах, о сообщении в почте, да о чем угодно. Но всякий раз, когда такое случается, оно означает проблему. Размышления сами по себе — не проблема, но признак какой-то другой проблемы. Вероятно, вместо того, чтобы ходить по кругу в своих мыслях, вам стоит обратить внимание на что-то из этого:

Понимание

Самая распространенная причина непродуктивных размышлений разработчика — неполное понимание какого-то слова или символа.

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

Таких вариантов — бесчисленное множество. Многие пользуются языком программирования, не разбираясь, что (, ), [, ], <, >, +, * и % означают в этом языке. Некоторые разработчики не понимают, как на самом деле работает компьютер. Помните мой «Единственный секрет программиста-рок-звезды»? Вот где суть! Ведь если ты по-настоящему понимаешь, тебе не надо прекращать ненужные размышления. Это также побудило меня написать книгу: понимание того, что есть незыблемые законы создания программного обеспечения, может избавить от многих эпизодов «борьбы с размышлениями».

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

Рисование

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

Начинание

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

Часто фрагмент кода, с которого проще всего начать, — это «ядро» приложения. Например, если бы я взялся писать приложение YouTube, я бы начал с видеоплеера. Воспринимайте это как упражнение по непрерывной поставке: пишите код, который действительно сначала создает продукт — неважно, каким дурацким или незначительным он может получаться. Видеоплеер без пользовательского интерфейса — уже продукт, выполняющий полезную задачу (воспроизведение видео), даже если еще не полноценен.

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

Пропуск шагов

Еще одна специфическая проблема понимания — пропуск какого-то шага в правильной последовательности разработки. Например, наш объект Велосипед зависит от объектов Колеса, Педали и Рама. Если вы попытаетесь написать весь объект Велосипед без написания объектов Колеса, Педали и Рама, вам придется много обдумывать эти несуществующие классы. С другой стороны, если вы напишете класс Колеса, пока вообще не существует класс Велосипед, вам предстоит много размышлений о том, как класс Колеса будет использоваться классом Велосипед.

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

Не перепрыгивайте шаги при разработке своей системы — и это позволит вам быть продуктивным.

Физические проблемы

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

Отвлекающие факторы

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

Неуверенность в себе

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

Ложные представления

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

Бездействие

Все перечисленное выше — ключ к тому, как быть быстрым программистом, когда вы сидите и пишете код. Если же вы весь день читаете почту и ходите по встречам, а программировать вам некогда — это другая проблема. Некоторые ее аспекты схожи (это как если бы организации пришлось «не задумываться»), но это не то же самое.

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

Как вам такой подход?

О переводчике
Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Источник

Удвойте скорость написания кода на React с помощью этих простых трюков

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

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

С повторно используемыми компонентами и хуками легко создать что-то потрясающее. Это похоже на сборку частей Lego.

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

В этой статье будет много кода на React. Не бойтесь кода. Не торопитесь, прочтите и поймите его.

Это большая статья. Содержание всеобъемлющее. Не стесняйтесь сохранить эту статью в своих вкладках и прочитать её несколько раз.

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

Исходный компонент, который мы будем рефакторить

Простой компонент, написанный таким же разработчиком, как вы. Что он делает:

Получает список браузеров с сервера.

Показывает состояние «загрузки» на экране.

Показывает загруженный список в виде списка карточек.

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

Этот код похож на ваш?

Чем хорош этот компонент:

Он корректно работает: список будет загружен и показан пользователю со всеми описанным выше функционалом.

Он использует React Hooks.

Что плохого в этом компоненте

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

Запомните эту мантру:

Искусство быстрого разработчика – это искусство писать повторно используемые строительные блоки.

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

Вы тратите меньше времени на написание кода. Повторно используемые компоненты/функции могут скрывать тонны кода внутри себя и могут использоваться сотни раз. А реализовать их нужно будет только один раз. Представьте, что каждый раз, когда вам нужно обратиться к API, вы используете «fetch(URL)», а это замедляет вашу работу.

Вы тратите еще меньше времени на написание кода. Гораздо быстрее добавлять новые функции в одно место, чем добавлять их в 10 разных мест. Если вы повторно используете свои строительные блоки, у вас будет только одно место для добавления ваших функций. Реализуйте функцию в одном месте, а результаты получайте везде.

Вы тратите меньше времени на поиск ошибок. Вы будете использовать уже проверенные строительные блоки. Новый код нужно тестировать, но старому можно доверять.

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

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

Разработчик обычно тратит больше времени на выяснение того, что делает код, а не на его написание. – Alexis Mangin. Почему разработчики React должны разбивать свои приложения на модули?

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

Монолит = медленное написание кода.

Многоразовые строительные блоки = быстрое написание кода.

Как сделать эти 100 строк кода более пригодными для повторного использования

Давайте сначала попробуем что-нибудь действительно базовое и простое, а затем перейдём к более сложным вещам. Как мы можем распределить эти 100 строк в разные места?

Перенести константы в пропсы вашего компонента

Мы переместили константу URL-адреса в пропсы и уже можем повторно использовать компонент Browser с другим URL-адресом. Несомненно, небольшое влияние на повторное использование, но это очень легко реализовать.

Разогрелись? Тогда давай попробуем что-нибудь действительно крутое.

Разделите бизнес-логику и интерфейс

Жизнь проще, когда компоненты пользовательского интерфейса не знают о сети, бизнес-логике или состоянии приложения. Передавая одни и те же пропсы, всегда отображайте одни и те же данные. – Eric Elliott, Недостающее введение в React

Это самая важная часть статьи. Если вы можете выучить только одну вещь, пусть ею будет она:

Искусство быть быстрым React-разработчиком – это искусство отделения бизнес-логики от интерфейса.

Ух ты, какой всплеск сложности! Не бойтесь, я научу вас.

Бизнес-логика: логика, которая принимает решения и сохраняет состояние, например: всё, что находится в
выше ключевого слова return.

Интерфейс: всё, что отображает состояние на экране и считывает ввод пользователя: всё, что находится внутри return(…)

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

Что мы будем делать:

Создадим кастомный хук useBrowsers() для нашей бизнес-логики.

Создадим компонент
с множеством пропсов для нашего интерфейса.

Хорошо, наш код далёк от совершенства, но стал более пригодным для повторного использования:

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

Мы можем использовать useBrowsers() с другим экраном или даже без экрана. Например, мы можем использовать useBrowsers() в другом приложении с другим дизайном.

Но наш разделённый код далёк от совершенства! Мы всё ещё можем сделать этот код более пригодным для повторного использования.

Повторно используемые строительные блоки = быстрое написание кода.

Разделите свой код на множество небольших файлов

Перво-наперво. Разделение монолита на 2 части открыло новые возможности для рефакторинга. Мы можем сделать нашу программу более читаемой (а вас – быстрее), если разделим наш код на разные файлы/модули. Это позволит нам думать о каждом модуле изолированно,а также сделать каждый модуль более читабельным и многоразовым.

Типичная структура проекта на React

index.js экспортирует
с Browsers.jsx.

В папках «components» и «hooks» хранятся строительные блоки, относящиеся к компоненту
.

BrowsersList.jsx также может превратиться в папку со связанными «хуками», «компонентами» и индексом.

Файловая структура проекта React представляет собой рекурсивное дерево.

Возможная рекурсивная структура проекта

Давайте посмотрим на наш BrowsersList.jsx.

Стало гораздо меньше кода. Он стал гораздо менее загромождённым. Теперь мы можем сосредоточиться на рефакторинге этой части кода.

Меньше беспорядка на экране = быстрое написание кода

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

Большая проблема с множеством небольших повторно используемых файлов

Посмотрите на наш компонент
:

если мы переименуем некоторые пропсы, например changeDescription в setSelectedBrowser или description в browser,

или мы удалим некоторые пропсы,

или добавим некоторые пропсы,

В каждом месте, где используется
, будет ошибка!

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

Ваша IDE не может переименовывать пропсы с помощью автоматического рефакторинга. Вам нужно будет сделать это вручную. Вручную проверить каждое место использования. Это замедлит вашу работу.

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

вручную перейти к сломанному компоненту и

прочитать текст ошибки;

исправить ошибку и попробовать ещё раз.

Это медленная и утомительная задача. Вот так неприятные баги попадают в продакшн. А такое бывает очень часто.

Проверьте, работает ли наш Browsers.jsx?

Кто знает! Для уверенности нам нужно открыть BrowsersList.jsx и useBrowsers.js и вручную сравнить входные данные.

Этот код не работает?

Да. У «descripton» в useBrowsers.js отсутствует «i», это опечатка.

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

Перестаньте медленно писать код на JavaScript, ускорьте себя с помощью TypeScript!

Наступил 2021 год, и каждый разработчик React/React Native должен использовать TypeScript. Фактически нет причин не использовать его.

Он может выглядеть страшно.

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

Наиболее очевидное решение этой проблемы – просто включите TypeScript, не меняя код, добавьте несколько простых объявлений типов. В конце концов, наш опыт показывает, что при простейшем использовании TypeScript можно получить много преимуществ. – Felix Rieseberg, TypeScript в Slack.

Классные фичи TypeScript

Меньше ошибок = более быстрое написание кода.

TypeScript избавляет от ошибок.

Мы бы сразу нашли опечатку с буквой «i»:

TypeScript выделяет ошибки

Ваша IDE получит функцию автозаполнения для пропсов в React. Это особенно экономит ваше время, когда вы используете сторонние компоненты с неизвестными пропсами:

TypeScript автоматически предлагает варианты

Ваша IDE получит функцию «рефакторинга». Это сэкономит вам время на переименование пропсов. Все использования пропса будут автоматически переименованы одним щелчком мыши.

Вы никогда больше не забудете добавить проверку на null/undefined.

? означает, что параметр может быть неопределённым.

И, конечно же, мы получим сообщение об ошибке, если попытаемся поместить недопустимые данные в наш пропс:

TypeScript проверяет правильность пропсов.

TypeScript легко сэкономит вам массу часов и избавит от стресса, связанного с отладкой кода.

JavaScript = медленное написание кода.

TypeScript = быстрое написание кода.

Первый шаг к быстрому проектированию системы: определите свои типы.

Это неполное руководство по TypeScript. Если вы чувствуете, что застряли, перейдите на typescriptlang.org, а затем вернитесь к статье.

И обновите сигнатуру хука useBrowsers():

Теперь TypeScript проверит, что useBrowsers() и BrowsersList совместимы. Если мы когда-нибудь изменим входные данные для BrowsersList, мы получим ошибку. Один этот факт гарантирует гораздо меньше ошибок в продакшне.

Меньше ошибок = более быстрое написание кода.

Быстрая системная архитектура

BrowsersListProps в настоящее время выглядит беспорядочно:

Компонент должен показывать состояние загрузки. Используется 1 строка в определении типа.

Должен отобразиться список Browser[]. Используется 1 строка в определении типа.

Должно появиться модальное окно с подробным описанием браузера. Используются 4 строки в определении типа. Эти строки ограничивают нас отображением поля «description» в нашем модальном окне. И кажется, что есть вероятность, что нам понадобится отобразить больше полей браузера в этом модальном окне. Помните, очень дорого менять сигнатуру компонента.

Мы можем сделать предположение и сократить определение типа и реорганизовать функцию «модального окна», чтобы использовать тип браузера.

Это снизит сложность пропсов:

TypeScript проверяет правильность сигнатуры.

Это небольшое упражнение по рефакторингу должно продемонстрировать вам еще одну замечательную особенность TypeScript – быстрое проектирование системы.

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

Первый шаг в проектировании любой системы: определение ваших типов.

Архитектура и планирование с типами TypeScript = быстрое написание кода.

После того как вы определили свои типы, вы можете начать писать логику компонента

Давайте исправим
, так как он будет обрабатывать новую сигнатуру BrowsersListProps. Мы можем провести рефакторинг
, так чтобы потребовалось бы только 2 пропса вместо множества. Это сделает код более читаемым, а нас – быстрее.

Если у вашего компонента много пропсов, это хороший намёк на возможный рефакторинг.

Этот компонент уже выглядит более читабельным и менее пугающим.

Меньше беспорядка на экране = быстрое написание кода.

Извлечение повторно используемоей логики от

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

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

Как всегда, мы начинаем с определения некоторых типов:

«T» – это аргумент типа. Типы с аргументами называются Дженерик. «T» для «UIFriendlyList » – то же самое, что «arg» для функции «foo (arg)». Если вы хотите построить свой тип из другого типа, используйте Generic. Для получения дополнительной информации ознакомьтесь с этой статьёй Ross Bulat.

«&» – это пересечение. «Type X = A & B» означает, что X будет содержать A и B.

Посмотрите на это крутое решение:

Мы определяем типы для наших пропсов UIFriendlyListProps.

Мы определяем универсальный тип: список может содержать элементы любого типа.

UIFriendlyListProps расширяет FlatListProps из библиотеки React Native с помощью нашей функции «индикатора загрузки».

Итак, мы определяем тип UIFriendlyListProps как пересечение типов из FlatListProps и

Насколько это круто?

Я доволен этим дизайном, давайте напишем тело этого компонента и переместим его в другой файл UIFriendlyList.jsx

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

– это компонент, который можно использовать повторно, и он наверняка сэкономит нам время в будущем. С этим компонентом мы стали более быстрым React-разработчиком.

Теперь давайте проверим наш
:

Этот процесс «извлечения повторно используемых частей» бесконечен и требует времени. Вам следует остановиться, если вы чувствуете, что можете провести время более продуктивно в другом месте.

Мы, люди, склонны писать код как форму прокрастинации, откладывая решение сложных проблем, которые у нас есть сейчас, путём решения гипотетических проблем будущего. – Justin Travis Waith-Mair. Прекратите писать повторно используемые компоненты React.

Мы закончили с интерфейсом, пора проверить бизнес-логику в хуке useBrowsers().

Рефакторинг бизнес-логики в хуке useBrowsers()

Как и компоненты, мы можем создавать настраиваемые повторно используемые хуки. Это делает код более читаемым, потому что кодовая база разделена на более мелкие, многоразовые блоки. – Bikash Paneru. Как лучше писать функциональные компоненты в React.

Давайте проведем рефакторинг useBrowsers(), чтобы вернуть валидный объект BrowsersListProps. Я также отрефакторил «loading»: теперь пропс будет установлен в «true» перед запросом и на «false» – после.

Выглядит неплохо, но мы можем пойти дальше и сделать многоразовый строительный блок. Функционал «запросить данные и сохранить результат в стейт, пока отображается загрузка» выглядит как крутой многоразовый строительный блок. Мы хотим отделить его от useBrowsers().

Как всегда, давайте начнём с определения некоторых типов. Мы хотим сделать хук useFetch(), который сможет хранить полученные данные в стейте, а также включать индикатор загрузки. Мы также хотим определить форму данных, которые мы получаем от API, как FetchBrowsersResults:

Неплохо выглядит, теперь давайте определим тело useFetch() и переместим его в специальный файл useFetch.ts:

Я также добавил нотификации на случай ошибки запроса. Таким образом, пользователь увидит описание ошибки.

useFetch() – это многоразовая функция, которая наверняка сэкономит нам время в будущем. С помощью этой функции мы стали более быстрым React-разработчиком.

Теперь займёмся рефакторингом хука useBrowsers():

Сравните с изначальным useBrowsers(), он намного меньше по размеру и прост для понимания.

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

4 простых совета, как стать более быстрым React-разработчиком.

С основной частью мы закончили, давайте немного расслабимся. Я дам вам 4 простых совета.

1. Никогда не форматируйте код вручную.

Функция автоматического рефакторинга

2. Никогда не импортируйте модули вручную.

Ваша IDE должна предоставлять вам функцию «автоматического импорта». Никогда не вводите «../../../» вручную и не тратьте время на ввод/удаление импорта вручную.

Попробуйте функцию «автоматического импорта» в действии:

Добавление всеъ отсутствующих импортов.

3. Перемещайтесь по проекту как профессионал

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

Посмотрите на эту огромную файловую структуру крошечного мобильного приложения:

Огромная файловая структура приложения

Знаете ли вы, как мучительно пытаться найти нужный файл во вкладках?

Открыто 10 вкладок. Где файл, который я ищу?

Ваша IDE должна предоставлять вам следующие полезные инструменты:

перейти к файлу с помощью строки поиска;

перейти к компоненту с помощью строки поиска;

перейти к ранее открытому файлу;

перейти к определению компонента с помощью курсора;

перейти к использованию компонента.

Изучите горячие клавиши своей IDE. Это сделает вашу работу гладкой, как масло.

4. Используйте линтинг ESLint

Каждый React-разработчик знает о боли неправильной зависимости хуков useEffect/Memo/Callback. В них всегда сложно найти ошибки:

Найти эти ошибки без линтинга очень сложно

ESLint позволяет без труда кешировать эти ошибки.

Инструменты разработки, такие как eslint и typescript, помогают поддерживать кодовую базу в большой команде. Хороший разработчик умеет программировать. Хороший разработчик умеет работать в команде. – Roman Nguyen. Создание архитектуры вашего React приложения. Перспективы разработки и бизнеса, о чём следует знать.

Все эти функции доступны в IDE Webstorm. Я рекомендую вам использовать Webstorm для разработки на TypeScript с React.

Заключение: искусство разработки повторно используемых строительных блоков

Искусство быстрого разработчика – это искусство писать повторно используемые строительные блоки.

Чтобы быть быстрым, вам необходимо:

Отделить бизнес-логику от интерфейса.

Использовать TypeScript, чтобы получать меньше ошибок.

Использовать TypeScript для включения мощных функций IDE: линтинга, рефакторинга имен, автозаполнения.

Определять типы перед написанием кода для быстрого проектирования архитектуры.

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

С помощью IDE форматировать код и импортировать модули.

Переходить по файлам с помощью горячих клавиш.

Мы успешно отрефакторили компонент
. Посмотрите на исходный компонент: это огромный, сложный для понимания монолит. Такой код кажется тяжёлым и замедляет нас.

Взгляните на эту лёгкую, как пёрышко, красоту:

Мы сделали простой для понимания компонент + извлекли 2 очень удобные многоразовые детали:

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

Поэкспериментируйте с кодом из статьи

Посмотрите итоговый результат в Codesandbox, чтобы поэкспериментировать и узнать больше. Этот код написан на React, он немного отличается от кода React Native в статье.

Что дальше?

Задавать вопросы. Особенно под этой статьёй в разделе комментариев.

И последнее, но самое важное:

Автоматически тестируйте компоненты React.

Начать тестировать ваш код сложно, но это сделает вашу жизнь сладкой, как леденец. Посмотрите статью Ian Wilson «Как создавать надёжные приложения React с TDD и библиотекой тестирования React», это хорошая точка для начала изучения тестирования. Ежедневно тренируйте свое ремесло и со временем вы станете мастером. А также не забывайте осваивать новое (например с нашей помощью) — только так можно сохранять свою актуальность в стремительно изменяющемся мире технологий. А наши менторы и чуткая поддержка в этом помогут.

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

Источник