frontend-разработчик. Фотографирую в инстаграме, готовлю и пишу тексты. Всё написанное не отражает мнения работодателя. 18+

3 заметки с тегом

html

6 причин, почему вам не стоит идти в код-ревьюеры

Каждый из разработчиков хоть раз в жизни сталкивался с проверкой своего кода. Это мог быть быстрый просмотр работы кем-то из коллег, к которым вы обратились с вопросом или проблемой. Мог быть разбор задачи со стороны начальства перед выпуском работы в production. Даже вы сами могли отложить работу, а потом окинуть ее свежим взглядом через некоторое время. А иногда это было полноценное код-ревью специалиста, который проверит код по строгим параметрам: от банальной работоспособности до стандартов, описанных в Style Guide компании.

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

Да, круто, но далеко не для всех. Я прошел тестовое задание, начал работать, набил шишки и сейчас делюсь почему вам не стоит становиться ревьюером кода.

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

Это не та творческая работа, что вы ищете

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

Код-ревьюер — не музыкант. Он — дирижёр.

Даже если вы видите очевидное решение, вы не можете, как говорили большинство учителей в школе: «приставить свою голову» — вы должны сделать всё, чтобы автор кода не просто самостоятельно пришёл к нужному решению, но и понял, почему такое решение является правильным.

С каждой итерацией вам нужно направлять человека, давать необходимые источники, чтобы в конце-концов сказать: «Ты молодец! Так держать!»

И тут мы переходим к следующей причине:

Код пишет человек

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

Когда вы создаёте веб-сайт, у вас есть миллион и один способ решить задачу бизнеса. Даже, если ваш работодатель работает с чётким списком технологий и имеет чёткие инструкции по стилям, для решения тривиальной задачи можно выбрать разные пути. Нравится вам Grid, а не Flex? Можете закрыть разницу в поддержке браузерами любимым костылём? Отлично. А что, если код-ревьюер на дух не переносит иного мнения?

Людям, которые не терпят альтернативных решений, не место в команде ревьюеров.

И ревьюер, и разработчик должны работать над проектом в команде. Только вместе можно создать отличный продукт.

Важно понимать: ревьюер — это не полицейский с палкой, который будет очень недоволен, если увидит некачественный код.

Код-ревьюер — это разработчик с чуть большим опытом, и он тоже может совершать ошибки или не замечать недочёты.

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

Правила, много правил

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

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

Помните «несправедливость» в школе, когда кому-то из одноклассников ставили оценку выше, а другому её занижали? (Если нет, то у вас были идеальные учителя.) Код-ревьюер не должен ставить кого-то из авторов в больший приоритет. Все равны, а код-ревьюер просто не имеет морального права на ошибку.

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

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

Разработчик использовал новый вариант и отправил работу на проверку.

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

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

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

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

Работы будет много, очень много

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

Я уже сравнивал эту работу с трудом учителя. Могу сказать профессионально (высшее образование получал как преподаватель иностранных языков): у современных учителей работа не ограничивается парой часов, проведённой с учениками. Большая часть работы — проверка домашних заданий, и это может забирать 8-12 часов чистого времени.

Код-ревьюер не ведёт лекции и семинары, он только проверяет «домашние работы». Множество работ.

Скажете: «Так именно за это ему и платят!» — и окажетесь не совсем правы. Код-ревьюер получает свои деньги за результат, которого добились авторы, и который ушёл в production. То, что мотивация может зависеть от количества работ, итераций или времени — это попытка менеджеров, которые редко когда писали код сами, оценить труд своего сотрудника.

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

Большие проблемы код-ревьюеров: рутина и время.

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

Я уже писал, что это не то творчество, когда результат зависит только от вас. А если автор присылает новую итерацию уже в третий раз? А если он такой не один? А если вы только сейчас заметили, что что-то упустили в прошлый раз?

Общение с людьми

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

Код-ревьюер — это всегда работа с людьми.

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

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

При этом вам с каждой проверкой надо будет общаться с людьми. С новыми людьми в больших проектах, или с одной и той же командой. Но общаться придётся. Это можно сравнить с письмами: вам написали, вы написали. Пинг-понг. Шар на вашей стороне, на стороне вашего партнёра, снова у вас. Раз за разом. День изо дня.

Это часть работы, и от этого никуда не деться.

Опыт, достаточный опыт

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

Достаточным — это не просто большим.

Например: «Я делаю landing pages уже 3 года, могу я быть отличным код-ревьюером в команде frontend-разработки?» — нет, если ваши страницы вы делали на Tilda, а вся работа заключалась в выборе шаблона из списка, и добавления текста, присланного заказчиком.

Код-ревьюер обязан разбираться в той технологии, с которой он работает.

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

Искренне считаю, что в большинстве случаев ревьюер должен быть ментором.

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

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

Во-первых, знать абсолютно всё невозможно, а потому быть разработчиком значит учиться на протяжении всей своей карьеры. Часто случается так, что долго работая над одним (не обязательно даже legacy-) продуктом, специалист замыкается в технологии. Он видит проторенные решения, и следует им на автомате. При этом языки программирования не стоят на месте, и там, где раньше изобретали велосипед, сейчас работает framework. Стоит ли об этом написать автору кода? Да! Ведь это сэкономит время и разработки, и проверки, а ещё деньги на выпуск проекта конечному пользователю.

Во-вторых, и это тоже важная причина: вакансий для разработчиков больше, чем специалистов, которые готовы на них откликнуться. Это значит, что многие компании готовы принимать на работу «джунов», которые ещё не знакомы с более узким «стэком» в компании. Нужно ли их доучивать? Да! И лучше всего делать это без отрыва от процесса разработки.

Ну и, наконец, в-третьих, код-ревьюер не просто «подгоняет» работы специалистов под некий, принятый в компании Code Style Guide. Если разработчик не привык ставить так необходимые всем точки с запятой в конце каждой строки в JavaScript, ему поможет Pretier, но если он не может писать код по принятым стандартам (например ООП) — работа код-ревьюера донести необходимость их соблюдать.

Вместо заключения

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

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

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

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

При этом я убеждён, что эта работа подходит далеко не для всех.

Не все игроки в футбол или баскетбол становятся классными тренерами. Но при этом они могут стать отличными игроками.

Если вы уверены в своих силах, вам стоит попробовать.

Если вам понравится, значит это ваше. Останется только совершенствоваться, потому что разработчик учится всю свою карьеру. А прочитать про код-ревьюеров конкретно в Яндексе можно в статье на Яндекс.Академии.

Табуляция vs. пробелы

До конца 2019 года я был ярым сторонником табуляции и никогда не использовал пробелы для отступов в коде. Причина была простая — я никогда не могу запомнить сколько пробелов стоит ставить, а нажать на Tab — это проще простого.

В 2020-м я считаю, что два пробела — это лучшее решение, которое может быть: во-первых, с двумя пробелами код становится сильно компактнее (а это критически важно, если вы пользуетесь ноутбуком, или решили заглянуть на свой github с мобильного телефона, чтобы дать ответ собеседнику); во-вторых, пробел всегда имеет одну и ту же ширину, а табуляция может зависеть от настроек (посмотрите в своей IDE параметр indentation) — это значит, что компактный код у вас может оказаться совершенно нечитабельным у тех, с кем вы работаете.

В 2020-м году я всё ещё нажимаю Tab для создания отступов или пользуюсь умной табуляцией в моём VSCode. Перевод из одного параметра в другой делает за меня editorconfig. Добавьте файл .editorconfig или добавьте плагин в свой редактор. Почитайте документацию на русском языке и настройте файл под себя, и забудьте забудьте о «табах», не меняя привычек.

Разумеется, это не относится к тем случаям, когда в вашей компании есть другой Style Guide и вам приходится использовать его (тогда просто настройте свой Editorconfig так, как вам будет удобно и просто пишите код так, как вам удобно).

1 мес   css   html   vscode   код

Модифицировать и положить на место

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

Чтобы этого избежать, стоит определить общие правила и их придерживаться.

В Яндексе продвигают методологию БЭМ, но ей пользуются не только там.

Я попробовал, разобрался и мне понравилось.

По БЭМ весь ваш код делится на три части: блок элемент и модификатор.

Приведу аналогию:

  • у вас есть полка. Полку можно поставить в любое место и она всегда останется полкой.
  • у вас есть книга. Книга останется книгой и на полке и у вас в руках. Это тоже блок.
  • если вы поставите книгу на полку, то книга станет элементом полки с книгами.
  • а если вы поместите книгу в суперобложку, то она будет выделяться, и станет блоком с модификатором.

Больше всего вопросов вызывают следующие вещи:

  • у вас есть несколько блоков, как их расположить относительно друг друга, если описывать положение в стилях блока нельзя?
  • как сделать файловую структуру?
  • модификатор не изменяет значение родительского блока, если создать правильную файловую структуру!!!

Разберёмся по очереди.

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

Блок действительно не должен влиять на своё положение в пространстве.

Согласитесь, если бы ваша полка говорила: «я стою у окна» — то вы не смогли бы поставить её в другое место, и блок потерял бы главное свойство блока в методологии БЭМ: свою универсальность.

Поэтому блок управляет только внутренними элементами и своими размерами. А если вы привезли в квартиру полку, которая не помещается: надо было думать при покупке.

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

Посмотрим на код на примере полки на книге.


<div class="shelf">
     <div class="shelf__book book"></div>
</div>

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

Как сделать файловую структуру

Если вы делаете проект по БЭМ и хотите получить один стиль, вы всегда можете взять кусок кода из одной страницы или с одного своего сайта и вставить в другой. Ничего не сломается.

Чтобы вы не искали код в длинном CSS-файле, frontend-разработчики, которые выбрали БЭМ, помещают каждое описание классов: блоков, элементов, модификаторов — в отдельные файлы и папки.

Выглядеть ваш сайт будет следующим образом:



src
 blocks
  shelf
   __book
    shelf__book.css
   _library
    shelf_library.css
   _kitchen
    shelf_kitchen.css
  shelf.css
  book
   _red
    book_red.css
   book.css
 pages
  index
   index.html
   index.css
   index.js

Внутри всё это дело подключается через @import url();, поэтому файл index.css выглядел бы так:


@import url(../../blocks/shelf.css);
@import url(../../blocks/book.css);

/* тут можно указать какие-то глобальные стили, но по правилам БЭМ. Например, задать шрифт странице */

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

Поэтому модификаторы элементов подключаются в корневых *.css-файлах элементов.

Создать подобную структуру, конечно, занимает время, но задачу можно легко решить при помощи терминала. Если у вас macOS или Linux, устанавливать ничего не надо: Git Bash уже установлен в системе, а если вы работаете под Windows, стоит зайти по ссылке и скачать файл.

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


$ mkdir src #создали папки
$ mkdir src/blocks src/pages
$ touch src/pages/index.html src/pages/index.css src/pages/index.js #создали файлы
$ cd src/blocks #зашли в папку
$ mkdir shelf book
$ mkdir shelf/_library shelf/_kitchen shelf/__book book/_red
$ touch shelf/_library/shelf_library.css shelf/_kitchen/shelf_kitchen.css shelf/__book/shelf__book.css shelf/shelf.css book/_red/bookd_red.css book/book.css

Повторять команду можно переходя по стрелочке вверх. А после того, как вся структура будет собрана, останется только добавить подключения дочерних файлов и всё заработает.

Модификатор не изменяет значения родительского блока

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

Исправить эту вещь можно двумя способами:

Добавить «вес»

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

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


/* файл book_red.css*/
.book.book_red {
    color: red;
}


/* файл book.css*/
@import url(_red/book_red.css);
.book {
    color: blue;
}

То же самое будет справедливо, если вы хотите «усилить» элемент блока. Ведь элемент не может использоваться в отрыве от блока.


/* файл shelf__book.css*/
.shelf .shelf__book {
    margin-right: 10px;
}


/* файл shelf.css*/
@import url(__book/shelf__book.css);
.shelf {
    margin: 0;
}

Тут стоит быть внимательным и «усиливать» элементы только родительским блоком. С чужим блоком такой фокус не пройдет.

На самом деле, этот способ не совсем корректный и применяется только в виде исключения из правил. Правильно делать так:

Не указывайте свойства, которые могут измениться

Вернёмся к книгам. У нас есть книги одинакового размера и формы, но разного цвета. Все синие и одна красная. Правильная запись в таком случае будет выглядеть так:


/* файл book_red.css*/
.book_red {
    color: red;
}


/* файл book_blue.css*/
.book_blue {
    color: blue;
}


/* файл book.css*/
@import url(_red/book_red.css);
@import url(_blue/book_blue.css);
.book {
    width: 200px;
    height: 400px;
}


/* файл index.html*/
<div class="shelf">
    <div class="book book_blue"></div>
    <div class="book book_red"></div>
    <div class="book book_blue"></div>
</div>

Немного более загруженный *.html-файл, но всё работает так, как нужно.

1 мес   bash   css   html   БЭМ   код   учебник