В то время как космические корабли бороздят просторы вселенной, а для разработчика код-ревью – обыденное явление, системные администраторы, инженеры эксплуатации и даже прокачанные DevOps-инженеры чуть ли не впервые с этим сталкиваются, будучи уже опытными специалистами.
В этом году команда Слёрма внедрила код-ревью практических заданий на курсах. В статье разбираем, кто делает ревью, и сравниваем это с настоящим код-ревью на работе.
Код-ревью на платформе
Кроме нашей платформы edu.slurm.io, для обучения активно используется GitLab.
Практические задачи курса выполняются в форке курсового репозитория по инструкции.
Затем участник курса копирует ссылку Gitlab с выполненной практикой и добавляет её на образовательной платформе в поле для ответа под практическим заданием.
Образец работы на платфоме. Делай раз Образец работы на платформе. Делай два
Кто делает код-ревью
Процессы совершенствуются: на первом потоке курса за ревью отвечал спикер, стали не справляться и взяли одного ревьюера. На второй поток мы масштабировались и собрали команду ревьюеров под количество студентов. Это позволило перейти на новый уровень проработки ревью и в третьем потоке курса сохраним команду ревуьюеров, внедряя улучшения уже в детали взаимодействия и платформу.
Большинство ревьюеров – разработчики, несмотря на то что практики курса ориентированы под задачи и инструменты эксплуатации, итог работы – код, пока что гораздо проще найти разработчиков с хорошим опытом для проверки кода. В Слёрме сохраняется поиск людей через профессиональные связи, знакомства. Так мы находим более заинтересованных людей в развитии курсов.
Количество ревьюеров на курсе непостоянное, команда ориентируется на количество участников потока. При этом мы не делаем привязки студентов к конкретному ревьюеру. С нашей стороны это проще в масштабировании, замене, подмене, для участника курса - больше разнообразного опыта. Ближе к жизни. На работе мы также с разными людьми взаимодействуем, у каждого свой опыт. Один человек обращает внимание на алгоритмы, второй – на оформление кода, третий на типизацию.
При этом на курсе минусы разного опыта ревьюеров нивелируются. В первую очередь они ориентируются на материал курса, а по возможности дополняют своим опытом, тем, что будет полезно на текущем этапе обучения.
Сроки код-ревью
С момента старта курса каждую неделю открывается одна тема. В первом потоке на выполнение практики давали две недели, со второго потока это изменили и теперь даётся три недели. Пока что это золотая середина между комфортом участников курса и методической целью – довести максимально всех до окончания курса. Либо по данному заданию ревью уже не будет. Но есть два исключения: индивидуальные жизненные ситуации, что бывает редко и повторное ревью. Повторное ревью – это когда после первой проверки работа возвращена на доработку, участник курса вносит правки и повторно отправляет работу, тогда мы проверяем, даже если срок прошёл.
Так поступаем, потому что из трёх недель надо изучить материал, выполнить задание, затем у нас есть срок проверки – пять дней. Это стандартный срок. Но перед нами стоит методическая задача укладываться в наименьшие сроки, сейчас проверка занимает два дня. При возвращении на доработку успеть в трёхнедельный срок можно, но не всегда.
При этом и с нашей стороны были форс-мажоры со сроками ревью. На втором потоке в какой-то момент, по всем законам факапов, именно перед выходными сломался бот, выходные – домашки не присылают, вроде всё хорошо. К понедельнику проблема и много отправленных работ были обнаружены, в итоге по одной теме часть работ проверяли чуть больше пяти дней.
Статусы и принципы код-ревью
У нас есть четыре статуса по ревью :
Черновик – вы сохранили черновик ответа, задание не отправлено.
Ожидает ответа – решение принято и скоро вы получите ревью.
Нужна доработка – доработайте код с учётом рекомендаций от ревьюеров.
Решение зачтено – вы просто великолепны!
В настройках вашего личного кабинета участник курса можете настроить уведомления и получать сообщения на электронную почту или в Telegram о том, что задание проверено и получен отзыв от ревьюера.
На доработку отправляется, если, что-то сделано неправильно в соответствии с заданием. То есть было какое-то условие – оно сделано либо неверно, либо вообще не сделано. Иногда бывает, что без доработок принимается задание: человек всё нормально сделал, у него мелочи какие-то по замечаниям. Можно написать примерно по такой структуре: «В целом сделано хорошо. Есть такие-то плюсы. Есть такие-то минусы. Задание принято».
Отправной точкой и надёжной опорой для ревьюеров является материал курса. Паттерны, которым учат спикеры, те best practices, которые они рассказывают – это проверяется в первую очередь. Если студент успешно применил на практике - значит материал усвоен. Но также ревьюеры обмениваются своими наработками, например, какие ошибки чаще встречаются.
У нас задания объёмные, строятся от проблемы, практически максимально приближенных к реалистичным задачам. Это не значит, что не может быть альтернативных решений. Способов решения может быть очень много и код может быть менее оптимизированным, чем нужно. Но насколько это действительно влияет? Например, в одном из уроков по словарям спикер рассказывал о методе dict.setdefault(), но в практике его мало кто использовал правильно. А если его применить, тогда кода становилось раза в 2-3 меньше, и он становился более читаемым.
Менее серьёзным являются ошибки в синтаксисе, в таком случае работа может быть принята с комментариями, а не отправлена на полноценную доработку. Нюанс нашего код-ревью – индивидуальный подход к участнику курса. Ревьюеры могут дать дополнительные комментарии, расширить таким образом материал урока. Но не все одинаково усваивают материал. Одним более чем достаточно подчеркнуть более базовые моменты и пользы для человека будет больше, если он разберётся лучше в базовых вещах. Другим ревьюер может дать более глубокий фидбек, уйти в детали, в оптимизацию кода. Например, по PEP 8 импорты сортируются на 3 группы. Каждая группа внутри сортируется по алфавиту, между ними добавляется пробел.
Не менее важным, чем подчеркнуть недостатки мы считаем отметить достоинства. Когда учишься, многие вещи можно сделать и не быть до конца уверенным, что это самый правильный вариант. Поэтому важно сказать «Ты сделал круто, здесь – правильно», человек понимает – окей, я здесь всё хорошо усвоил, можно идти дальше.
Общение с участниками курса
Взаимодействие участников курса и ревьюеров не заканчивается на обмене заданием и проверкой. Бывают ситуации, когда есть потребность в дополнительном обсуждении. Например, участник курса не понял комментария и уточняет ответ или не согласен с ревьюером, причины тому могут быть разные.
Выполненные проекты сдаются в GitLab, поэтому там и продолжается обсуждение в комментариях к конкретному проекту. Также есть чат в телеграм, где участники курса общаются друг с другом, куратором и ревьюерами. Никто не остаётся наедине с проблемой.
Код-ревью итогового проекта
В завершении курса есть итоговый проект, участникам курса самим нужно выбрать тему и путь решения. Это может быть абсолютно любая автоматизация: оператор для Kubernetes, свой модуль или плагин для Ansible, это может быть расширение любой другой системы вне изученных в рамках курса модулей и технологий. Также часто применяются линтеры кастомных описаний ресурсов IaC.
Ревью обычного задания направлено на проверку усвоения текущего блока, плюс смотрим базовые вещи, которые рассказывались в первых модулях иногда. Итоговый проект – он более масштабный. Там уже можно ревьюировать архитектуру, если это какая-нибудь работа такая посложнее, больше посмотреть в сторону оптимизации кода. Более комплексной работе – более комплексное ревью.
Итоговый проект, как и его ревью максимально отражает усвоение материала курса, поэтому номерные сертификаты дополнительного образования можно получить, только успешно выполнив этот проект.
Код-ревью на курсе и в работе
На работе обычно не всегда пишут подробно, разжёвывая детали. Указывают направление, а дальше человек сам додумает. Но если для разработчиков код-ревью обычное дело, то для команд эксплуатации может быть так, что ни TeamLead, никто из товарищей не пишет. Можно найти коллегу и из другой команды, который хорошо умеет в программирование, которого можно попросить тебя поменторить. Если разработчик понимает нюансы и какие-то инженерные – это идеально. Главное: понимать предметную область и видеть, насколько хорошо написан код.
Решает ли человек разработческую задачу или инженерную, – он пишет программу. С ней будут работать другие люди, поэтому она должна быть написана хорошо, чтобы её проще было поддерживать в дальнейшем, дорабатывать. Человек, который решает задачу с помощью кода, он в какой-то мере разработчик всегда.