Кросс-тим код-ревью. Часть 1. Первые ощущения, первый опыт в рамках новой компании
Всем привет. Меня зовут Дмитрий. Я имею 15-летний стаж в .Net. И к данному моменту работаю уже пятый месяц в команде Цифровой Профиль в компании Ак Барс Цифровые Технологии в роли Старший .Net разработчик серверной логики. Команда хорошая, работа мне очень нравится. В компании более 100 разработчиков .Net и много команд разработки.
На прошлом месте работы я был негласным тех.лидером. Одна из моих обязанностей была ревью кода. В команде было более семи разработчиков и МР-ов(мёрдж-реквестов) на проверку было достаточно. Здесь только двое бэкенд-разработчиков в нашей команде. Помимо ревью в своей команде, я начал делать ревью кода еще в еще двух соседних командах. Не хотелось потерять опыт, который был приобретен на прошлой работе.
Я узнал соседние команды, и нашел тех, кто был не против, чтобы я смотрел их код. Получил соответствующие доступы и начал делать периодчичеси код-ревью.
Предыстория такая: никогда будучи джуном не любил код-ревью, да и в пору бытия миддлом тоже не рвался. Да вообщем, уже 15 лет в программинге, а понял зачем нужно код-ревью совсем недавно, около двух лет назад. Когда раньше скидывали в общий чат МР-ы, считал, что это ненужное-непонятное дело. Ну сделал человек изменения и что? Что там проверять? Помню вообще никаких мыслей не было, ассоциаций с чем-то важным.
Сейчас мнение изменилось. Код-ревью - теперь для меня одна из самых главных особенностей разработки, особенно если в команде много участников и разного уровня.
В целом преимущества и недостатки так же одинаково относятся как к кросс-тим ревью, так и к ревью внутри команды.
Преимущества код-ревью:
- Одна голова хорошо, а две - лучше. Не всегда бывает, что программист все сделал и просмотрев еще раз код увидит, что что-то не так. Глаз замылен или еще какие причины. Нужен свежий взгляд на код.
- Кодер делает код лучше, зная, что код будет проходить проверку коллег. Это как некое повышение ответственности за код, за то, что ты делаешь и осознание будущей проверки дает мотивацию делать код лучше.
- Делимся опытом в комментариях - живой опыт программинга. Опыт - сын ошибок трудных. И как раз его накоплением мы и занимаемся. Не прекрасно ли это?
- Ты можешь учиться и учить в комментариях на реальных примерах кода, это больше, чем чтение книги с примерами как надо делать код. Ты можешь узнать новые тенденции в коде и сам научить коллегу новым фишкам и в(о)время их использовать.
- Недопуск багов вверх по пищевой цепочке разработки фичи. Это одна из самых больших болей, которую хочется избежать всем. Еще Роберт Мартин пишет об этом в своей книге Идеальный Программист. Он очень трепетно относится к этому моменту и считает, что нужно отдавать код максимально правильным для последующей проверки тестировщиками и т.д.
- Восприятие код-ревью как помощь коллеге. Это внимание к работе и понимание, что вы работаете в команде, а не каждый сам за себя.
- В ходе код-ревью, можно приходить к единому мнению и стилю программирования, который будет устраивать всех и гармонично откликаться в душе работающих над кодом. Не всегда, конечно, получается достигать единения, но попытаться стоит.
Недостатки
- Давление ревьювера, если он агрессивно пишет комментарии.
- Споры и негатив от разногласий в кодировании по поводу стиля и примененных решений. Это омрачает порой и разрушает настрой на рабочий лад.
- Дискомфорт работы в случае, если к тебе придираются жестко и неоправданно и постоянно.
После нескольких месяцев код-ревью решил подвести небольшой итог по своему эксперименту.
Попросил написать обратную связь одного из руководителей команды разработки. Мне было интересно узнать, удачный ли эксперимент с таким кросс-тим код-ревью .
Вот что мне ответили:
В целом думаю норм. Плюсы - взгляд со стороны, что-то могут подсветить, о чем не задумывался. Минусы - без погружения в проект в основном можно увидеть только недостатки связанные со стилем кода, опечатки, может криво написанную функцию.
…. конец ответа…..
Я очень был рад, что опыт оказался неплохим. И считаю, что нужно продолжать такую практику и для других проектов.
Помните, что код-ревью - это место единения, обсуждения, конструктива, доказательного обсуждения, а не место выяснения отношений и раздача лишь указаний и агрессивных директив.
Мы все люди, мы все ошибаемся и в работе должна быть гармония и стремление сделать работу четче и лучше. Каждый имеет свои плюсы и минусы, кто-то силен в одном, кто-то в другом направлении программирования. Когда вы научитесь мыслить командно - у вас не будет проблем с код-ревью.
Вводите практику код-ревью. И делитесь своим опытом.
PS: В планах - провести ревью еще в нескольких командах, и есть более амбициозный план - сделать ревью во всех командах. Шаг за шагом.