больше всего понравилось про "раздаем советы, но не даем приказы", по моему опыту за 5 лет, именно 90% выдает приказы. спасибо за видео, много полезного

Очень хотелось бы видео о работе драйвера изнутри, и о его написании, видео на эту тему в русском сегменте очень мало, буду очень благодарен !!!)))

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

Спасибо соеру за ролик, часть с кодом выглядит очень интересно. Вот может это можно было б сделать отдельной рубрикой. В моменте, где ты обьяснял про «принцып единственной ответственности» Есть такие короткие видосы в вкладочке «short”. Рубрика типа «теория и практика» . Я бы с удовольствием смотрел бы. Типа кусок кода и сразу там какой то принцып. А этих принцыпов очень много. И можно точно по 2-3 на каждый с разной переодичностю делать. В общес в заключение скажу, что очень понравился момент с кодом и обьясненем почему жто хорошо или плохо согласно какому-то принцыпу. Спасибо за ролик!

Супер! Очень важная тема и было интересно послушать

Спасибо за классные советы "как проводить"

Спасибо за хорошие темы! Продолжай дальше!

Хорошее видео, тут где-то перекликаются советы с тем, что говорил Егор Бугаенко. Я думаю это здорово, если такие люди как вы рассказывают и доносят внятно такую информацию, значит можно внести это в команду

вот это чоткое видео! благодарочка вам от вебмастера и сеошника со стажем СЕООНЛИ

спасибо понравилось все очень круто !

Спасибо за интересное видео. А что, если у нас команда из 5 фронтендщиков, но каждый работает в отдельном репозитории на своём проекте в одиночку, и верстает и если надо прикручивает React/Vue? У нас типа digital agency. Есть ли смысл делать код ревью проектов, в которых ты ничего знать не должен и за которые ты не отвечаешь перед менеджером? Как просить на это время?

Спасибо за видео, Евгений! Все-таки я не стал внедрять кросс-ревью в больших командах, например, 10+ разработчиков))

Оч крутая тема и описание ) спасибо ) беда в том что многие этого всего не понимают ) и код ревью превращается в холивары ) без смысла )

В коде, где ничего не надо менять, я бы фор на вайл тру поменял, последняя конструкция лучше в глаза бросается. Но это так, вкусовщина.

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

Вопрос: какое минимальное кол-во ревьюеров у вас стоит на PR?

Звук вроде поменялся?

Допускаешь ли ты дописывание/переписывание/исправление/улучшайзинг/рефакторинг кода ревьювером в отдельных случаях? Если да то в каких, и в каком обьеме ( как это вообще измерить или формализовать )

Спросите у Сакутина, он об этом все знает 😂 Ну а вообще, видос топ, а code review абсолютно любому программисту на все стадиях обучения полезен

Жаль нет важной для меня информации - как распределять мерж реквесты на апруверов. Есть ли какие-то примеры автоматического назначения или кто-то должен вручную выбирать.

да, хорошее ревью не должно быть долгим :-)

like!

Добрый день. Вопрос про "Ревью - это советы а не приказы". Что делать если коллега или подчиненный вообще не старается расти в профессиональном плане? Например за год человек по уровню кода не вырос вообще, зачастую забивает на корпоративные стандарты и так далее. Изначально это было в форме советов. Но через какое-то время перешло на прямые приказы. Понятно, что частично проблема кроется в стиле управления и наставничества и возможно стоит что-то поменять) Но и люди тоже не всегда хотят развиваться - для кого то это просто работа, выполнение функции.

Когда-то работал в конторе, никакого кодревью. Работа в темпе «херак херак и в продакшн». Начальник заходил в офис со стандартной фразой «ну чо там, когда готово будет?». Деньги от государства, уже выделены, результат лишь бы был.

Пересматриваю контент и понимаю, что основы программирования следовало бы начинать преподавать как можно раньше.. Последовательность и логичность у людей стали бы чаще встречаться 😄😅 если бы программисты пришли к власти, мир бы разительно изменился 🤔

Для меня странно звучат 3 момента: 1. кодревью - это совет. 2. кодревью - это оценка кода, а не автора. 3. хороший код не обязательно понятен человеку с улицы. Первый звучит странно потому, что если ты несёшь ответственность за проект и в твоей команде есть человек, который пишет плохой код и отказывается его исправлять, то оставить этот код в ответственности этого человека означает взять на себя риск. Этот человек через год, когда наделает кучу гадостей в коде, может свалить в другую компанию, оставив своих коллег, а главное тебя самого, ведь ответственность несёшь ты, это всё разгребать (и да, у меня такое было один раз). А главное ты это можешь узнать ещё через полгода после того, как он уйдёт, а тебе прилетит задача, связанная с написанным им кодом, и ты поймёшь, что его поддерживать невозможно. Второй звучит странно потому, что когда человек из раза в раз совершает одни и те же ошибки, особенно если они очевидны, то говорить ему "и тут поправь тоже" становится слегка бессмысленно. В этот момент надо переходить именно к оценке автора кода, узнавать его мотивацию так писать код, попытаться понять не является ли эта ошибка результатом пробела в знаниях, который надо заполнить и т.д. То есть код, однажды написанный плохо - это плохой код, а код, который систематически пишется плохо - это уже свидетельствует о плохом авторе кода. Третий пункт я считаю странным потому, что это как сказать "речь сотрудников компании не обязана быть понятной человеку с улицы". То есть представьте себе ситуацию, когда в русскоговорящую компанию берут русскоговорящего человека, он выходит в первый день на работу и обнаруживает, что речь его коллег звучит как "правти! Ям сидня зончу задачу вобедень". Я не думаю что тут было бы уместно говорить "а, так это нормально, у нас так принято в компании, через месяцок-другой освоишься" :) Так почему же это нормально в отношении кода тогда? И да, в этом отношении второй код из примера лучше первого, потому что хоть в нём и есть некоторые упущения, но его может легко прочитать человек с улицы, типа меня (инициализируются переменные, парсится переданное состояние таймера с получением значений старта и интервала таймера, эти значения из миллисекунд переводятся в секунды+наносекунды, они в свою очередь собираются в объект "спецификация таймера", после чего эта спецификация применяется к таймеру). Первый код я скорее всего прочитать бы смог, если бы погрузился в тему и язык, который знаю посредственно, но в том то и дело, что второй код легко понимается при беглом просмотре, а первый можно понять только погрузившись, а значит он по определению сложнее читается :)) Есть предположение, что в первом коде не хватает уровня абстракции, скрывающей ненужные детали низкого уровня, но это не точно...

Что делать в ситуации, когда ревьювер - опытный разработчик, который не хочет пропускать плохой код? Имеет ли смысл все таки настаивать на хорошем решении на ревью, чтобы плохие решения не просачивались в кодовую базу?

тот момент, когда ты несколько недель просил поревьюить свой код, а в итоге теперь им нужно "ревьюить" фичу в которой изменено 6000 строк =)

8:25 но по какой-то причине люди до сих пор не используют linter'ы и прочие штуки для стандартизации форматирования кода на проекте =\

А если есть Code Style Guideline и код ему не соответствует, при этом автор на указание об этом в комментах отвечает отказом что-то менять, тут надо оставить право принятия решения за автором? А если код не выполняет (или выполняет с ошибкой) требуемой функциональности? Тоже решает автор? Мне правда интересно, это не попытка обидеть. Про право Вета не упомянуто, странно. Хотя в сервисах code review такое есть.

Похоже что описана ситуация команды из примерно равных по скилу людей. Но если у вас команда джунов, наверное все же скидывать на джуна 100% ответственность за функциональность или делать ревью в виде советов, как то не очень сработает?

@SOER я не совсем понял вашу мысль относительно ответственночти за код. Кроме программиста над кодом работвют тестировщики, тим лид, другие члены команды. Если код утверждается ими всеми и попадает в продакшен, то, по моему, за него должен отвечать не только программист его написавший. Разве не так ?

Моя практика показывает что все код ревью приводят к срачам и обидам, но код не особенно то и улучшают. Мне кажется что если человек привык к бардаку по жизни, то есть дома бардак, вещи раскиданы, куча хлама везде валяется, то код он будет писать точно так же и его не переделаешь, к сожалению. Заставить на время можно, но переделать его не получится все равно. Но это так, наблюдения из жизни. )))

Всегда делаю ревью собственного кода через пару-тройку дней после написание! И всегда возмущаюсь какой же идиот это писал!

28+((0x3BBEECC>>2*month)&3) 16-тиричное число не верно указано, и эта формула не работает для високосного года можно сделать как 28+((( 0x3BBEECC+( 0x10* (1>>(year%4)) ) )>>2*i)&3) Скобки я сделал для приоритетности верной, тк не помню точно у каких операторов приоритет выше Возможно это можно лучше оптимизировать, код я писал для js Вот полный код для проверки: let day = 0; let year = 2005; for(let month=1;i>(year%4))))>>2*month)&3); console.log(month, day); }

Представляю выразительность кода в моих коммитах - например, в методах пересчета меша с костями и зависимостями - для ревьювера скорей всего выглядит так: какие-то матрицы переписывается с непонятной математикой и накладываются матрицы неясно чего с непонятно какими векторами 😁 и увы это байда будет на добрые пару сотен строк. Насчет устоявшиеся алгоритмы - на практике уже сколько раз было, эти устоявшиеся может и выглядят красиво, но на деле совершенно не подходят в данном случае по скорости.

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

Хорошее видео, но, на мой взгляд, остался непокрытым вопрос о том, насколько ревьювер кода должен пытаться вникнуть именно в правильность выполнения бизнес требований по конкретной задаче, а не только оценки качества кода и выявления потенциально проблемных мест - это сродни запуску кода и тестированию, или всё-таки имеет смысл уделять этому особое внимание. Бизнес требования могут иметь достаточно высокую сложность, было бы интересно мнение автора исходя из его опыта, ведь в таком случае ревью уже может выйти за рамки быстрого 5-10-минутного просмотра.

"Коды не пахнут" - А. Капоне

сколько ж разрабов пересралось на этой почве…. Но вещь обязательная, хоть и может приносить боль, как на текущем проекте. Лид ревьют код в лучшем случае раз в неделю и он полностью солидарен с автором в вопросах типа ‘Why do we need this, what will be if, pls investigate etc” и так под каждой строкой, по факту имеем трудозатраты на такие ревью как 50% фичи. Сегодня было ревью пула который висел 4ю неделю и на очередную порция таких вопросов я понял что я просто банально не помню! Благо после брейншторма вспомнил что так заказчик на одном из дейли сказал, повезло. Касательно не запускать тесты и руками тыкать - согласен, но бывают исключения как опять таки на этом проекте - разраб делает фиксы не проверяя, то есть код написал и в пул, открываешь страницу а там 500, новый опыт для меня короче . А так в принципе всё описано как должно быть в идеальном мире, только вот есть ли он……,,

Спасибо за интересное видео. Не согласен, что не надо запускать код. Если проект сложный (например, компилятор на миллионы строк), то баги не всегда очевидны. Лучше дебагать и проверять перед тем, как писать замечание, иначе будет много неверных замечаний.

У меня на проекте постоянно брали джунов. Никаких анализаторов кода не стояло и код ревью никто не делал. Каждый был загружен своими задачами и писал как хотел. После того как у меня появлялось время на код ревью я хватался за голову от увиденного. Человека увольняли, а я всё переписывал. Другие приходили такие же. Все мои советы по написанию кода в большинстве случаев игнорировались, а у меня опускались руки. В итоге проект превратился в кучу сложно поддерживаемого говнокода. Если бы изначально был style guide, статические анализаторы и код ревью, то этого всего можно было избежать. Если сейчас на код ревью я будут просто что-то советовать, а не требовать то джуны просто напросто будут продолжать плодить говнокод. p.s. к сожалению при найме разработчиков моё мнение не учитывалось. Даже когда я лично собеседовал человека и говорил начальнику, что кандидат очень слабый, то он его всё равно брал в команду.

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

на счёта кол-ва нулей, то вместо 1000000 можно было просто 1e6 написать.

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

На мой взгляд, тим лид все таки несет ответственен за то, что написал программист в его команде. Если происходит апрув, то ответственность также разделяется с лидом. В этом есть смысл, так как нельзя просто апрувить пул реквест для галочки и думать, что потом программист если что разберется. Каждая итерация с багом (или его возвращение) увеличивает время разработки. Лид должен препятствовать таким решениям, если нужно даже созвониться и обсудить пул, сделать checkout ветки и тд.

Камера что-ли новая? Картинка ярче стала

Так, вот что я не понял. Допустим, разработчик у другого разработчика видит не замечание по чему-то, а ошибку, явную. И говорит об этом. У автора кода все еще есть возможность это игнорировать? Не рассматриваю причины, но если он продолжает настаивать, что ошибки нет - то где и как в процессе код ревью подключается арбитр? Например, это могут быть - тимлид, архитектор, или старший разработчик. Кажется, эти люди имею право сказать "надо переделать" и не подавать это в виде совета

В свое время так и не решили задачу на проекте - код вроде хороший, ревью проходит, а бизнес кейсы не проходит. Баг на баге. Начинаем фиксить - получаются костыли, зато бизнес проходит. на повторное ревью нет времени, выходит замкнутый круг

Я инженер программного обеспечения, но я не хочу быть Соером) Аббревиатура звучит так себе. Одного Соера хватит)

да, вот столкнулся впервые, коллеги поляки на проекте просто продавливают свое мнение в ревю

Извините, а что делает жопа с глазками? Я про for (;;)

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

Интересно что в видео такой подход к код ревью предполагается как единственно правильный, хотя это вообще не так. Отедельно порадовало "ревью это как совет в курилке, а не отдельный этап в задаче" и "ревью должно включать всю команду". Кто-то без опыта в код ревью может посмотреть и принять за чистую монету, но это вообще не так. Более того из опыта это ещё и не самый оптимальный вариант имхо. Все пункты перечисленные в самом начале, работают на 100% только если ревьювер полностью погружается в задачу и понимает каждую новую строчку кода (зачем она, почему так и т.д.). В таком подходе невозможно вовлечение всей команды, потому что это слишком затратно по времени, и не даёт большого преимущества (код вряд ли станет сильно лучше и знаний у автора не сильно прибавится от лишних ревьюверов). Здесь скорее всего получается противоречение из-за того, что пункты в начале расставлены не в правильном порядке. Основные плюсы ревью это именно улучшение кодовой базы и взаимное обучение коллег. "Эффект наблюдателя" вообще говоря довольно спорный, потому что он имеет минусы. Например порой когда автор знает, что его код проверят, теряется часть ответственности за свой код. Ты знаешь что его посмотрят и потенциальные баги найдут, поэтому сам можешь что-то недосмотреть. Нужно понимать что процесс код ревью довольно сильно зависит от специфики задач. Если каждая таска разбита на 5 модулей и включает кучу бизнес логики, то поверхностный просмотр ревью вообще невозможен, он просто ничего не даст из-за того, что будет абсолютно не понятно что происходит, пока ты не поймёшь задачу и решение. В то же время если обычно задачи в команде это минорные баги, то подход может полностью изменится

что за колдунство после 18ой минуты?

На 20 минуте, услышав про макросы, выключил видео

Зачем давать советы в ревью, если их можно игнорировать? Решение аппрувнуть мр/пр в любом случае принимает ревьювер, а не автор кода

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

Жалкие потуги оправдать напрасную трату времени в команде. Что ж у вас за разработчики такие, что без эффекта наблюдателя они не в состоянии создавать чистый код. Работаю в Airbus-е пятый год, ничего подобного и близко нет, но при этом качество кода, на порядок выше чем в любых других проектах, включая опенсорсные. Особенно порадовало выражение “улучшение кодовой базы”. Здесь как бы подразумевается что ваша команда настолько плоха априори, и ее код требует постоянного улучшения из коробки. Мое мнение очень простое. Код ревью обычно вводят команды у которых один или несколько ресурсов из триады неограничен (время, люди, деньги). Если работает профессиональная команда, то как правило, такие практики не нужны и даже вредны. Если вам требуется код ревью в команде, значить у вас в проекте что то пошло не так. Постарайтесь это локализовать и исправить, вместо того чтобы заниматься такой ерундой. Я участвовал в нескольких проектах с кодом ревью, и качество такого “ревью” и особенно самого ревьювера было просто слезы. Возможно в неких очень специализированных проектах код ревью и можно использовать для расшаривание неких практик или компетенции, но как правило в коммерческих проектах, такой необходимости нет. У автора же наблюдается явный избыток времени, что как правило является упущением менеджмента компании. И не стоит чрезмерно увлекаться творчеством Роберта Мартина, возводя его в абсолют.

Как будь-то я говорил.