1 + 1 = 11, это каждый фронтенщик знает вообще-то

Из моего опыта мало кто делает реальное ревью кода, обычно это способ потратить время на кофе и просто нажать кнопку Approve.

Когда видос "отвечаю на комментарии к видео, где я отвечаю на комментарии к видео про код ревью"?)

Интересное видео получилось. Спасибо!

Уважаемый Soer, было бы интересно увидеть выпуск про легаси код: каким будет Ваше видение того, как справляться с большими массами устаревшего, трудноподдерживаемого кода, не покрытого тестами и документацией и т.д. Например, писать заново или работать с тем, что есть (и если всё же разгребать, то как наиболее эффективно привести всё в порядок). Спасибо)

14:28 «то как работают другие калеки» 😆

Очень нравится картинка. Скажите, пожалуйста, на какую камеру снимаете и как у вас получается это небольшое размытие, дымка(?)

Could you please talk a bit about git flow. How to make big feature in git better? Should we squash commits or not. When do we need to do this (squash) Maybe some example? Thanks!

Я вот только не могу понять, почему на футболке лого нутаку...

Можно узнать название темы для KDE, которую Вы используете?

Т.е. code-style придумали просто так

Пора, наверное, code review относить к разряду "темы, вызывающие бесконечное количество споров".

недисциплинарный код должен быть осужден

Абсолютно не согласен с автором канала. Здесь работает правило единственности ответственности: прогер пишет код, чтоб он работал и прошел ревью; ревьюер читает и апрувит код, берет на себя полную ответственность этот код. Поэтому все, что требует ревьюер, кодер обязан поправить, т.к. дальше ответственность ревьюера. Простые, понятные всем правила, не имеющие двоякого толкования. Я, например, ревьюер, какая у меня мотивация делать работу, если она ни на что не влияет (это же просто совет) ? На сколько часто именно ревьюер находит баг, особенно в ситуации со сниженной мотивацией ? Являюсь приверженцем как раз Бугаенко, у него вообще 2 ревью: первое - кросс-ревью, выполняется другим членом команды, на этом этапе отсеивается большинство багов, несоответствий архитектуры, проблемм с производительностью и.т.д.; второе - когда таска прошла первое ревью, код смотрит и апрувит архитектор на соответствие феншую и всему такому, чем о5ть берет на себя ответственность, что этот код будет смерджен в основную ветку. Еще раз подчеркиваю: основной принцип не быть добреньким, поддерживать атмосферу быть лояльным и т.д., это ни разу не гарантирует выполнение задачи качественно и в срок, а сохранять четкие и понятные правила для всех.

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