{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Code Review

Приветствую! :)

Сегодня я хотел бы поговорить с вами про Code Review, а именно рассказать о фишках его проведения на простом и понятном языке. Как безболезненно организовать процесс и прийти к эффективному результату.

Имея достаточно серьезный опыт в Java разработке и проведении ревью кода, я выделил несколько важных пунктов на что стоит обращать внимание при организации самого процесса. Для начала я дам простое определение понятию Code Review. Это процесс, когда разработчики оценивают и отслеживают ошибки или недочеты в коде другого разработчика. В нем принимают участие автор, который написал код, и рецензент, который анализирует код и принимает решение, когда тот готов для добавления в общую кодовую базу проекта.

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

Code Review- не про критику, это про возможность обмениваться знаниями и принимать осмысленные решения. Качественный процесс проведения и разбора помогает выстроить благоприятный микроклимат в коллективе, ведь в команде встречаются люди с разными характерами и амбициями. Я нечасто сталкивался с ситуациями, когда специалист воспринимал в штыки правки или даже малейшие комментарии, но все же многое зависит от темперамента человека и мы не всегда можем предугадать реакцию. Здесь важно правильно формулировать свое сообщение с разбором кода, текстом мы не всегда можем передать эмоциональный окрас сообщения, поэтому максимально скорректированное описание требований к изменению кода поможет избежать недопониманий или вовсе конфликтных ситуаций.

Мой совет будет удобен в применении. Стараюсь обходить личные обращения, которые читаются как указания. Местоимение “мы” дает понять о том, что в данном процессе происходит совместная работа, а не критика и указания с моей стороны. Ни для кого не секрет, что схема “показать недочет, но похвалить за другой момент” достаточно рабочая.

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

Не могу так просто оставить вас без полезной литературы. Три книги, которые я бы посоветовал Java разработчикам:

«Чистая архитектура. Искусство разработки программного обеспечения». | Роберт Мартин

«Как пасти котов». | Дж. Ханк Рейнвотер

«Spring 5 для профессионалов» | Козмина Юлиана, Харроп Роб

До связи :)

0
Комментарии
-3 комментариев
Раскрывать всегда