Отвечаю на комментарии к видео про ревью кода
HTML-код
- Опубликовано: 8 сен 2024
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...
1 + 1 = 11, это каждый фронтенщик знает вообще-то
Я не знаю, наверное, надо меньше в бакенд залезать. 😀
А 11 - это три )
@@S0ERDEVS Его идеи будут актуальны всегда
Из моего опыта мало кто делает реальное ревью кода, обычно это способ потратить время на кофе и просто нажать кнопку 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!
Очень нравится картинка. Скажите, пожалуйста, на какую камеру снимаете и как у вас получается это небольшое размытие, дымка(?)
Sony 7s 28mm/3.5
Размытие за счёт фокуса объектива.
Дымка за счёт вытягивания тёмных мест в серый цвет.
Можно узнать название темы для KDE, которую Вы используете?
Пора, наверное, code review относить к разряду "темы, вызывающие бесконечное количество споров".
недисциплинарный код должен быть осужден
Т.е. code-style придумали просто так
Абсолютно не согласен с автором канала. Здесь работает правило единственности ответственности: прогер пишет код, чтоб он работал и прошел ревью; ревьюер читает и апрувит код, берет на себя полную ответственность этот код. Поэтому все, что требует ревьюер, кодер обязан поправить, т.к. дальше ответственность ревьюера. Простые, понятные всем правила, не имеющие двоякого толкования. Я, например, ревьюер, какая у меня мотивация делать работу, если она ни на что не влияет (это же просто совет) ? На сколько часто именно ревьюер находит баг, особенно в ситуации со сниженной мотивацией ? Являюсь приверженцем как раз Бугаенко, у него вообще 2 ревью: первое - кросс-ревью, выполняется другим членом команды, на этом этапе отсеивается большинство багов, несоответствий архитектуры, проблемм с производительностью и.т.д.; второе - когда таска прошла первое ревью, код смотрит и апрувит архитектор на соответствие феншую и всему такому, чем о5ть берет на себя ответственность, что этот код будет смерджен в основную ветку. Еще раз подчеркиваю: основной принцип не быть добреньким, поддерживать атмосферу быть лояльным и т.д., это ни разу не гарантирует выполнение задачи качественно и в срок, а сохранять четкие и понятные правила для всех.
Ага, только а задаче "код работал и прошёл ревью" две отаетсвенности. SRP как раз работает в моем варианте - программист отвечает за работу кода, ревьюер проверяет понятность кода. )
@@S0ERDEVS Не стоит передергивать. Вы прекрасно понимаете, что кроется под формулировкой "принцип единой ответственности". Если вам угодно, то программист отвечает за пропихивание всеми правдами и неправдами своего коммита в мэйн-ветку, а уж через какие фильтры он вынужден пробиваться - это дело десятое. И ревью, наряду с юнит тестами, линтерами и прочими CI/CD пайплайнами имеет только одну цель - отфильтровать неподходящий код. Но тут вопрос, в основном, не в технических тонкостях и понятийных неточностях, а в одном простом вопросе: готов ли "менеджер" (например техлид) брать ответственность за то, что его команда творит. Способен ли человек, управляющий процессом разработки, сконструировать адекватную систему этой самой разработки. Или он, не зная что делать, покупает смузи и биллиардный стол в офис (цитата Бугаенко, близкая к оригинальной =D ) ? Каждый управленец отвечает на этот вопрос сам.
@@kselnaag2482 я то прекрасно понимаю srp, только не понимаю зачем вы его вспомнили. Он тут не к месту.
Что касается идей Егора, применительно к практике управления, то лучше чем он сам никто и не скажет - ruclips.net/video/y64Zdf4OI9I/видео.html
Стараюсь не работать в таких командах. Мне больше всего нравится неформальная власть. Для команды очень опасна ситуация, когда техлид некомпетентен (я не говорю про вас, но такое бывает) и навязывает свою точку зрения, потому что он здесь власть и он ответственный и швец и жнец и на всех ЯП игрец.
Субъективно мое мнение, что в либеральной атмосфере просто легче работать всем. Может сиюминутно продуктивность ниже, но на долгой дистанции проект выигрывает. Мой техлид на прошлом проекте не брал отпуск несколько лет просто потому что не уставал, работал размеренно. И бизнес сыт и программисты целы
Ты все равно меня не убедил: если у человека есть цель стать лучше, то нет разницы приказываешь ты ему или советуешь, он так или иначе будет воспринимать это как направление для развития. Так было у меня, когда я был джуном, так и у моих джунов, когда я стал тимлидом. Самое главное - аргументировать замечания, чтобы человек понимал почему нужно делать так, а не иначе, и к чему то или иное решение может привести. А так, с остальными тейками, в целом, согласен.
Имеешь полное право, мои видео это просто совет )