В данном посте хотелось бы поговорить о прекрасном слове “Code-review” и рассказать как он построен в команде YOTA.
Немного лирики
В моем понимании, code-review - это прежде всего инструмент. Инструмент, который нам помогает следить за качеством кода. Можно долго говорить о том, что такое “качество кода” и каким оно должно быть в идеальном мире, но поговорим об этом в следующий раз. Могу посоветовать прочесть замечательную книгу “Clean Code” написанную дядюшкой Бобом. По моему мнению, code-review должен существовать в любом проекте, который пишут несколько людей и важно понимать зачем он нам нужен, понимать при этом - правильно. Я встречал достаточно людей, которые пренебрежительно относятся к ревью кода, а иногда и совсем неадекватно, потому что во время ревью, ревьювер задевает его чувства и словно придирается к каждой строчке.
На что следует обращать внимание
При проведении code-review, по моему собственному опыту, я прежде всего обращаю внимание на следующие вещи:
- Code-style, который прописан в нашей команде
- Вразумительное наименование методов и переменных
- Так же, у меня есть небольшой принцип по количеству строк в методе - размер метода не должен быть больше 50 строк кода
- Следование SOLID принципам (ну как минимум - SRP)
- Консистентность логики
- Многопоточность (дэдлоки, рейс кондишены, фриз main thread’а)
- Архитектурные особенности проекта (в нашем случае - MVVM)
- Retain cycle’s и управление памятью
Как построен процесс code-review в YOTA
- Во первых, наша команда следует следующему Git-flow принципу:
- Для каждого релиза существует своя ветка, к примеру dev-3.0
- При разработке новой фичи, разработчик бранчуется от ветки текущего релиза со следующим именованием - “3.0/feature/(JIRA-Ticket)-name-of-task” - данное именование ветки нашей новой фичи помогает нам видеть созданные папочки в SourceTree по релизам, что упрощает навигацию.
- Примерно два-три раза в день делается rebase ветки с веткой релиза
- По завершению разработки фичи, создается code-review в UpSource на ревьювера
- Ревьюверу приходит нотификация о том, что на него создано code-review:
- Если в ходе ревью кода возникают замечания, ревьювер в праве нажать кнопочку с пальцем вниз (“все херня, Вася”) и пинает разработчика фичи.
- После того, как разработчик исправит замечания, ревизия добавляется к существующему code-review и ревьюверу снова приходит об этом нотификация.
- В случае успешного прохождения code-review, ревьювер жмет кнопочку палец вверх (“Accept”), об этом информируется разработчик фичи, и это значит, что можно делать merge в ветку релиза. Происходит merge и закрывается сразу же созданное ревью в Upsource.
Собственно, это весь процесс.
Если в команде находится человек небольшого профессионального опыта или только что появился на проекте, то ревью создается на каждый коммит.
В конце концов
В конце концов, при данном процессе и взаимопонимании, в результате мы получаем на выходе качественный код, на который не так страшно и стыдно смотреть.