Спасибо за то, что Вы отметили, что можно посылать ревьюера, если его замечания являются вкусовщиной. Например, замечание "переименуй прокси в адаптер" и то и другое суть одно, но на этой почве возникают конфликты. Часто такие замечания можно получить от неопытных коллег, сам был таким, сейчас понимаю на сколько глупы такие замечания. Недавно открыл для себя замечательный инструмент под названием SonarQube, при правильной настройке все замечания автоматически репортятся прямо в пулл-реквесты. Время ревью у нас снизилось в десятки раз при этом возрасло качество.

Я конспектирую слово в слово Ваше изложение для дальнейшего использования в нашем ентерпрайз проекте. У меня сейчас такой таск - сделать исследование как следует проводить Code Review. Ваше видео покроет польшую часть "не технической" части этого исследования. Спасибо вам большое.

Подытожим… Организация работы: 1. Выделенное время у оцениваемых и оценщиков. 2. Правила по которым оценивается код: логика, производительность, стиль, “дальновидность”. (хорошо бы собрать примеры) 3. Правила по которым принимается решения по спорному моменту. 4. Собирания типичных ошибок и способы их решения. Инфраструктура должна отвечать требованиям: 1. Автоматическая сборка. 2. Прогон юнит тестов до оценки. 3. Прогон интеграционных тестов после сборки (при необходимости). Практики: 1. Отправка на оценку только при “happy path”. Исключения должны быть объяснены. 2. Критикуешь. Предлагай. Пример лучшей реализации со стороны оценщика. 3. Открытие нового задания на какое-то более масштабные изменения (при необходимости).

Делаем ревью вдвоём, тот кто писал и наблюдающий, т.е. тот кто писал как бы презентует свой код и объясняет что и зачем. Очень часто случается что выпиливается лишний код, т.к. в процессе ревью выясняется что он избыточен. Хорошая практика.

Где первая часть? Ходить по коментам вдруг кто-то уже спрашивал и ответили? Фейл.

Спасибо, интересно и полезно

Нужно больше годного контента!

Дедушка вернууулся!

Оч крутое видео, крутые мысли, спасибо за то что поделился. Не думал выпустить это в тектовом формате где то на medium и хабре?

thanks a lot, sir

спасибо!

Я считаю важным упоминание (как в первой, так и во второй части) об использовании статических анализаторов кода. Иногда ограничиваются только чем-то типа CppCheck, но на самом деле надо идти дальше, если большой проект, и анализировать на предмет дублирования кода. А уж потом, да, без траты времени на вкусовщиину (которая должна быть более-менее описана в code guidelines), переходить к существенным моментам, их нельзя формализовать, иначе бы это можно было отдать тому же статическому анализатору.

ревью очень полезная вещь, CI может и пропусить проблемные места, а знающий человек поймет и откоментит.

Вроде вчера подписался, а уже полгода прошло

Все очень по делу. Едиственное не сказал бы что ревью безсмысленны без рефакторинга. Чаще всего вполне достаточно и оптимально ограничиться оценкой непосредстевнных изменений в мердж риквесте. Очень часто при расширении функционала появляется желание что-то зарефачить, но это не всегда оправдано, в первую очередь с точки зрения времени. Из моей личной практики могу сказать что лучше рефакторинг (если он реально имеет смысл) выносить в отдельные такски которые так же отдельно будут ревьюиться. Их же можно и более гибко приоритизировать когда они сами по себе. Иначне работа над тасками, а именно peer review пинг-понг, может сильно затянуться.

Когда мы в компании столкнулись с проблемами при проведении code review (долго, споры), просто собрались всем направлением и составили регламент где четко описаны требования к проведению ревью. Есть четкий регламент - нет проблем.

*Хороший канал,с меня подписка + лайк. Автор молодец,хороший контент делает,а главное качественный,сегодня редко можно найти толкового человека с подобным контентом. Вот пришлось продать свой канал,и новый создавать развивать по новой. Ладно,успеха автору канала*

добро

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

Я думаю, что код нужно изначально так писать, как будто скоро будет код ревью (если конечно самому знать все правила чистого кода, что в идеале и должно быть). Тогда и ревьюверу не много работы останется. Я вот, например, пишу проект в одиночку. Вот и приходится очень часто проводить рефакторинг. Чуть ли не каждый день. Самому ведь придётся в этом "бардаке" разбираться.

Объясните пожалуйста про негерметичные абстракции и про архитектуру ПО в целом

Соер подскажи, что лучше использовать в Java if-else или switch?

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

а как найти первую часть? конечно ревью кода имеет смысл. с одной стороны пишешь и решаешь задачу, с другой не всё можешь уследить и получаешь опыт.

Боже, как же Soer крут

Привет. Скажи пожалуйста, почему приглашение в дискорд недействительно?

Согласен, что код ревью надо, но я не встречал пока, чтобы все описанные пункты выполнялись, особенно про вкусовщину. Как на практике обойти нашу обезьянью природу, я не знаю. Особенно когда был младшим сотрудником часто сталкивался с тем, что ведущего разраба хлебом не корми, но дай покритиковать, а когда спрашиваешь: какие у тебя аргументы в пользу твоего решения, начинается - ну вот с высоты своего опыта... хотя дельных советов было 50 на 50.

А мой последний ревью, закончился переходом с нативного яаваскрит на вью 🤔

расскажи про rest и solid

Что-то я за свой небольшой 6 летний опыт коммерческой разработки и прохождение под полсотни интервью ни разу не слышал, что code review - это плохая практика. Скорее наоборот И я сам считаю это важной частью работы 1. человек сам учится у других когда ревьит чужой код; 2. разработчик всегда вкурсе куда движется какая-то часть проекта, особенно когда он сосредоточен на другой. Иногда это позволяет предотвратить ошибки, недопонимания или дублирования работы; 3. код новичка в команде обязан быть проревьен, т.к. он не знает какие вообще классы и подходы существуют на данном проекте; 4. в процессе ревью происходит коммуникация членов команды, соответственно их притирка, которая в будущем может помочь как команде так и проекту в целом. я бы выделил следующие моменты: 1. стараться делать пулл реквесты как можно меньше (с учетом разумности, конечно); 2. в команде/руководстве должно быть понимание, что ревью - это не чайку попить между тасками, а полноценная работа.

Это на самом деле очень тонкий момент на сколько грубоко погружаться в код... как нащупать эту грань? Иногда чтоб понять логику и оценить ее правильность приходится потратить достаточно много времени, нужно ли это делать вообще или оставить тестировщикам?

Нужно кодреью #коронавирус провести

Первую часть не нашел

Бывают ли у вас такие дни, когда голова например вообще не работает и даже думать о программировании не хочется ? Из за плохого сна возможно, либо просто вот день такой и всё.

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

Код ревью должен делать лид, чтобы джуны и мидлы не засрали проект. Есть практики когда код-ревью делает рэндомный кодер, но это имхо бред.

Hotelos bi uslishatj pro instrumenti i podhodi dlja odinokih volkov. Nu tjipo... kak samomu svoi kod vremjo za vremenjem peresmotretj. Stoit lji eto voobshe videljatj otdelno pri solo razrabotke.

Неправильно ты дядя Федор ревью делаешь - надо чужой код засирать, а свои курсы нахваливать. Сакутину привет ;)