Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-19

1 В то время как космические корабли бороздят просторы вселенной, а для разработчика код-ревью - обыденное явление, системные администраторы, инженеры эксплуатации и даже прокачанные DevOps-инженеры чуть ли не впервые с этим сталкиваются, будучи уже опытными специалистами.<p> В этом году команда Слёрма внедрила код-ревью практических заданий на курсах. В статье разбираем, кто делает ревью, и сравниваем это с настоящим код-ревью на работе.</p>

2 <h2>Код-ревью на платформе</h2>

3 Кроме нашей платформы edu.slurm.io, для обучения активно используется GitLab.<p>Практические задачи курса выполняются в форке курсового репозитория по инструкции.</p>

4 <p>Затем участник курса копирует ссылку Gitlab с выполненной практикой и добавляет её на образовательной платформе в поле для ответа под практическим заданием.</p>

5 Образец работы на платфоме. Делай разОбразец работы на платформе. Делай два<h2>Кто делает код-ревью</h2>

6 Процессы совершенствуются: на первом потоке курса за ревью отвечал спикер, стали не справляться и взяли одного ревьюера. На второй поток мы масштабировались и собрали команду ревьюеров под количество студентов. Это позволило перейти на новый уровень проработки ревью и в третьем потоке курса сохраним команду ревуьюеров, внедряя улучшения уже в детали взаимодействия и платформу.<p> Большинство ревьюеров - разработчики, несмотря на то что практики курса ориентированы под задачи и инструменты эксплуатации, итог работы - код, пока что гораздо проще найти разработчиков с хорошим опытом для проверки кода. В Слёрме сохраняется поиск людей через профессиональные связи, знакомства. Так мы находим более заинтересованных людей в развитии курсов.</p>

7 <p>Количество ревьюеров на курсе непостоянное, команда ориентируется на количество участников потока. При этом мы не делаем привязки студентов к конкретному ревьюеру. С нашей стороны это проще в масштабировании, замене, подмене, для участника курса - больше разнообразного опыта. Ближе к жизни. На работе мы также с разными людьми взаимодействуем, у каждого свой опыт. Один человек обращает внимание на алгоритмы, второй - на оформление кода, третий на типизацию.</p>

8 <p>При этом на курсе минусы разного опыта ревьюеров нивелируются. В первую очередь они ориентируются на материал курса, а по возможности дополняют своим опытом, тем, что будет полезно на текущем этапе обучения.</p>

9 <h2>Сроки код-ревью</h2>

10 С момента старта курса каждую неделю открывается одна тема. В первом потоке на выполнение практики давали две недели, со второго потока это изменили и теперь даётся три недели. Пока что это золотая середина между комфортом участников курса и методической целью - довести максимально всех до окончания курса. Либо по данному заданию ревью уже не будет. Но есть два исключения: индивидуальные жизненные ситуации, что бывает редко и повторное ревью. Повторное ревью - это когда после первой проверки работа возвращена на доработку, участник курса вносит правки и повторно отправляет работу, тогда мы проверяем, даже если срок прошёл.<p> Так поступаем, потому что из трёх недель надо изучить материал, выполнить задание, затем у нас есть срок проверки - пять дней. Это стандартный срок. Но перед нами стоит методическая задача укладываться в наименьшие сроки, сейчас проверка занимает два дня. При возвращении на доработку успеть в трёхнедельный срок можно, но не всегда.</p>

11 <p>При этом и с нашей стороны были форс-мажоры со сроками ревью. На втором потоке в какой-то момент, по всем законам факапов, именно перед выходными сломался бот, выходные - домашки не присылают, вроде всё хорошо. К понедельнику проблема и много отправленных работ были обнаружены, в итоге по одной теме часть работ проверяли чуть больше пяти дней.</p>

12 <h2>Статусы и принципы код-ревью</h2>

13 У нас есть четыре статуса по ревью: <ul><li><strong>Черновик</strong> - вы сохранили черновик ответа, задание не отправлено.</li>

14 <li><strong>Ожидает ответа</strong> - решение принято и скоро вы получите ревью.</li>

15 <li><strong>Нужна доработка</strong> - доработайте код с учётом рекомендаций от ревьюеров.</li>

16 <li><strong>Решение зачтено</strong> - вы просто великолепны!</li>

17 </ul>В настройках вашего личного кабинета участник курса можете настроить уведомления и получать сообщения на электронную почту или в Telegram о том, что задание проверено и получен отзыв от ревьюера.<p>На доработку отправляется, если, что-то сделано неправильно в соответствии с заданием. То есть было какое-то условие - оно сделано либо неверно, либо вообще не сделано. Иногда бывает, что без доработок принимается задание: человек всё нормально сделал, у него мелочи какие-то по замечаниям. Можно написать примерно по такой структуре: "В целом сделано хорошо. Есть такие-то плюсы. Есть такие-то минусы. Задание принято".</p>

18 <p>Отправной точкой и надёжной опорой для ревьюеров является материал курса. Паттерны, которым учат спикеры, те best practices, которые они рассказывают - это проверяется в первую очередь. Если студент успешно применил на практике - значит материал усвоен. Но также ревьюеры обмениваются своими наработками, например, какие ошибки чаще встречаются.</p>

19 <p>У нас задания объёмные, строятся от проблемы, практически максимально приближенных к реалистичным задачам. Это не значит, что не может быть альтернативных решений. Способов решения может быть очень много и код может быть менее оптимизированным, чем нужно. Но насколько это действительно влияет? Например, в одном из уроков по словарям спикер рассказывал о методе dict.setdefault(), но в практике его мало кто использовал правильно. А если его применить, тогда кода становилось раза в 2-3 меньше, и он становился более читаемым.</p>

20 <p>Менее серьёзным являются ошибки в синтаксисе, в таком случае работа может быть принята с комментариями, а не отправлена на полноценную доработку.Нюанс нашего код-ревью - индивидуальный подход к участнику курса. Ревьюеры могут дать дополнительные комментарии, расширить таким образом материал урока. Но не все одинаково усваивают материал. Одним более чем достаточно подчеркнуть более базовые моменты и пользы для человека будет больше, если он разберётся лучше в базовых вещах. Другим ревьюер может дать более глубокий фидбек, уйти в детали, в оптимизацию кода. Например, по PEP 8 импорты сортируются на 3 группы. Каждая группа внутри сортируется по алфавиту, между ними добавляется пробел.</p>

21 <p>Не менее важным, чем подчеркнуть недостатки мы считаем отметить достоинства. Когда учишься, многие вещи можно сделать и не быть до конца уверенным, что это самый правильный вариант. Поэтому важно сказать "Ты сделал круто, здесь - правильно", человек понимает - окей, я здесь всё хорошо усвоил, можно идти дальше.</p>

22 <h2>Общение с участниками курса</h2>

23 Взаимодействие участников курса и ревьюеров не заканчивается на обмене заданием и проверкой. Бывают ситуации, когда есть потребность в дополнительном обсуждении. Например, участник курса не понял комментария и уточняет ответ или не согласен с ревьюером, причины тому могут быть разные.<p>Выполненные проекты сдаются в GitLab, поэтому там и продолжается обсуждение в комментариях к конкретному проекту. Также есть чат в телеграм, где участники курса общаются друг с другом, куратором и ревьюерами. Никто не остаётся наедине с проблемой.</p>

24 <h2>Код-ревью итогового проекта</h2>

25 В завершении курса есть итоговый проект, участникам курса самим нужно выбрать тему и путь решения. Это может быть абсолютно любая автоматизация: оператор для Kubernetes, свой модуль или плагин для Ansible, это может быть расширение любой другой системы вне изученных в рамках курса модулей и технологий. Также часто применяются линтеры кастомных описаний ресурсов IaC.<p> Ревью обычного задания направлено на проверку усвоения текущего блока, плюс смотрим базовые вещи, которые рассказывались в первых модулях иногда. Итоговый проект - он более масштабный. Там уже можно ревьюировать архитектуру, если это какая-нибудь работа такая посложнее, больше посмотреть в сторону оптимизации кода. Более комплексной работе - более комплексное ревью.</p>

26 <p>Итоговый проект, как и его ревью максимально отражает усвоение материала курса, поэтому номерные сертификаты дополнительного образования можно получить, только успешно выполнив этот проект.</p>

27 <h2>Код-ревью на курсе и в работе</h2>

28 На работе обычно не всегда пишут подробно, разжёвывая детали. Указывают направление, а дальше человек сам додумает. Но если для разработчиков код-ревью обычное дело, то для команд эксплуатации может быть так, что ни TeamLead, никто из товарищей не пишет. Можно найти коллегу и из другой команды, который хорошо умеет в программирование, которого можно попросить тебя поменторить. Если разработчик понимает нюансы и какие-то инженерные - это идеально. Главное: понимать предметную область и видеть, насколько хорошо написан код.<p> Решает ли человек разработческую задачу или инженерную, - он пишет программу. С ней будут работать другие люди, поэтому она должна быть написана хорошо, чтобы её проще было поддерживать в дальнейшем, дорабатывать. Человек, который решает задачу с помощью кода, он в какой-то мере разработчик всегда.</p>