Здравствуйте, уважаемые подписчики и гости канала!
Любое мнение субъективно, но у кого-то опыта больше, а у кого-то меньше. Меня зовут Артур Геращенко и я пишу, как специалист, проработавший 12 лет программистом, в разных командах на разных языках. Занимался много чем от сайтоделанья до сложных нагруженных сервисов.
Так вот, качество кода очень важно, но бывает, что не важнее вовремя сделанной фичи для продукта. Все будет зависеть от того, как долго надо поддерживать фичу, много ли известного в неё надо будет всего натолкать после. Короче, все от конкретной фичи конкретного проекта зависит, но суть, я думаю, вы уловили.
Постоянные читатели возможно уже устали от этого, но я должен написать ещё раз - вам не за код деньги платят, а за работающие для клиентов в продакшене фичи. Конечно, код не должен быть отъявленным куском сами знаете чего и, как обычно, есть разные фичи и разные куски кода, отношение к которым просто должно быть разным. К примеру, что-то, что связано с деньгами напрямую и что-то не на столько же значительное типа вывода новостного блока. Новости, безусловно очень важно, но деньги это деньги. Хотя, если у вас новостной сайт, то все сильно меняется)))
Так вот мой рецепт по поводу pull requests и code review на них:
1. Всё, что можно автоматизировать, нужно автоматизировать. Используйте для этого ci/cd , кстати, у нас мы сделали свое решение и позже я напишу почему. В ci/cd обязательно добавляем линтер, прогон тестов, и пр. прочие проверки типа code smells, которые призваны НЕ тратить время других участников команды на то, что компьютер сделает быстрее и тщательнее.
2. Убирайте споры о стиле кода из code review. Делайте это не в рамках задачи, а на общих встречах за отведенное на это время. К слову сказать, на одном из проектов за 10 лет стиль кода меняли три раза и все просто продолжали работать и по сути, я лично не заметил, что что-то стало лучше из-за новых договоренностей. Думаю человек привыкает к любому стилю и удобно привычное, вот и всё. Добавляйте что-то в линтер и поехали. Перебарщивать тоже не надо, ваш код никогда не будет такой же как у другого члена команды. Свой код всегда понятнее, делайте на это скидку и не запихивайте абсолютно все в линтер. Лучше вообще взять любой готовый и ничего не менять.
3. Всегда помните, что никто из вашей команды не хочет сделать код хуже. Поэтому никогда не спорьте на повышенных тонах, давайте рекомендации не по стилю кода, а по его понятности с пояснениями, почему вы рекомендуете что-то поменять или добавить.
4. Я лично против обязательных комментариев в понятных методах. Лучше назвать метод качественее, а вот писать комментарий у метода getUserId(), что он "return user id from object property", это я считаю - ухудшать код. Кода становится больше и он по сути не нужен, "шумит" и мешает видеть реально полезные комментарии.
5. Просите больше полезных комментариев. Но не "что делает метод" - есть же название метода, а "почему это делает метод". Какую проблему решает и, в сложных случаях, просите писать - почему именно так. Зачем добавляли код в целом можно узнать из коммита или прикрепленной к нему задачи.
6. Старайтесь понять что именно должен делать код и как изменения влияют на функциональность. Например не нарушит ли оно что-то важное, что не покрыто пока тестами.
7. Не делайте громадных pull requests. Ревью такого рода никогда не делаются нормально. Начните с необходимого рефакторинга, если надо, пройдите ревью, заливайте в прод. Потом уже дальше небольшими итерациями. Коллеги оценят понятность и нужность.
Кто должен принимать участие в code review?
Думаю также все сильно зависит от команды и от продукта. По хорошему у любого компонента продукта должен быть owner, он точно должен стоять в каждом review по компоненту. Желательно ещё одного человека для обучения и подстраховки. Не надо толкать больше 2 на ревью - и толку не и их работу никто не будет за них делать. Ревью это такой же инструмент разработки как и прочие вещи, не нужно использовать его больше чем надо. Тут шутка про стопроцентное покрытие тестами. ))
А на этом всё, спасибо за внимание!
Подписывайтесь на канал, ставьте лайки, оставляйте комментарии - это помогает продвижению в Дзене.