Поговорим про Pull Request, они должны помогать сделать код лучше
HTML-код
- Опубликовано: 26 дек 2021
- В этом видео я решил поговорить про запросы на изменения кода, которые должны помогать улучшать код, а не критиковать. Я расскажу, как познакомился с запросами и о моем отношении к ним.
Канал програмысли видеоуроки:
/ @dev-lessons
Семейный канал:
/ @migpoedem
Поддержать меня: boosty.to/mflenov
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.info
Мой просто блог blo.moe
Twitter: / flenov
Инстаграм: / mflenov
Телеграм: t.me/mflenov
Находил иногда интересные комментарии в коде типа "Этот клиент жмот, может и не заплатить!". Сразу просил предоплату )) Такие комментарии делают код лучше
С наступающим, Михаил! Спасибо за видео)
Спасибо, вас тоже с Новым годом
По своему опыту скажу что пулл реквесты + кодревью это очень и очень. Во первых: можно на этапе кодревью отсеять потенциальные ошибки. Во вторых: кодревью - для джунов и даже мидлов это дополнительная причина следить на чистотой кода. Ревьювер может и по шарке надавать )))
"Переделаю потом" в большинстве случаев означает "переделаю никогда" :) Так растет технический долг. Сам таким грешу.
Ну если что-то серьёзное, то я заблокирую запрос. «Исправить потом» это что-то маленькое, что подправить можно за пять секунд
Привет. Если честно, забыл когда был первый пул реквест, но очень давно, как только появилось. У меня уже 16 лет в общем опыта программирования. Я очень сильно смотрю за своей командой и всеми ПРами, бывает рефакторю за ребятами, если они не понимают, что имею ввиду. А так не представляю себе жизнь без этого на работе, было бы очень сложно.
Со string.Empty всё просто, это способ указать явно, что строка должна быть пустой, что это не программист оставил пустые кавычки по ошибке и не было лишних вопросов.
Ну мне понравилось объяснение, что в пустых кавычках могут быть невидимые Unicode символы. В String.empty точно не будет невидимости. Это да, это может быть хорошей причиной для изменения
Пуллреки еще и для обмена опытом. А то у нас всегда "чукча писатель, а не читатель". И пока люди не начнут читать чужой код на пуллреках, они не поймут как сложно иногда их собственный код читать. Когда они начнут читать код, то они как бы увидят себя со стороны. Поймут, что и имена переменных очень важны. А до тех пор так и будут называть все переменные x, потому что "тут же все итак понятно". А с учетом текучки программистов читабельность кода встает на передний план. Человек написал ему одному понятную фигню, уволился, а потом все заново переписывать приходится, потому что никто понять не может почему тут 5-ая вложенность циклов и что такое за переменная value
Я не представляю, как мы жили без пул реквестов до их появления. Никто не знал, что делают другие
Нужная штука, щас как раз сборкой релизов занимаюсь. Для Pull Request где нужна не критичная доработка, то аппрувится и создается новый task на доработку.
если есть незначительные замечания по оформлению - одобряю и пишу в слак чтобы не забивать PR комментариями
Если программисты потом реально исправляют, то такой подход ускорит разработку.
@@programisli как правило, правят в этом же PR. После approve можно дослать коммиты типа cleanup или doc до слияния в dev
Вы в целом смотрите PR или по комитам?
Что вы делали когда было 10 пулреквестов и нужно все ревьювить?
Как избавлялись от накопления?
Вы ревьювели код или бизнес логику тоже?
Если большой запрос, то смотрю по коммитам. Что делать, чтобы не накапливалось - выделять время, иначе никак
Здравствуйте, когда-то давно у Вас выходило видео, где рассказывалось про книги для программистов. Не могли бы Вы подсказать, что именно необходимо читать тому человеку, который собирается идти в iOS разработку?(На языке программирования Swift, разумеется)
Если знаешь английский, то рекомендую m.ruclips.net/p/PL3d_SFOiG7_8ofjyKzX6Nl1wZehbdiZC_
Очень интересно, и в тоже самое время очень страшно вас слушать, т.к у меня 10+ лет опыта в программировании Delphi C++ PHP в 2 проектах. Но знаний намного меньше, это очень пугает. Буду смотреть вас и дальше при возможности. Спасибо!
Ну у меня уже 25 лет опыта, так что накопилось историй, которые можно рассказать
@@programisliМихаил, не думали ли выпустить видеокурс по разработке для передачи знаний и опыта, накопленных за столь долгую плодотворную карьеру? 😊
Пропустить ПР для того, чтобы быстрее что-то начать тестировать или закрыть какую-то дыру - для меня крайне редкий случай. Обычно все-таки добиваюсь того, чтобы все было по фен-шую. Логика здесь простая - в истории в мастере не должно быть кривых коммитов с говнокодом или плохим код-стайлом. Тогда при необходимости можно откатываться на любой коммит в мастере и точно знать, что "вот это зааппрувлено как годное изменение". К тому же, пару раз бывали случаи, что программист при внесении каких-то исправлений по код-стайлу на самом деле ломал работу фичи и это не было замечено, никто не рецензировал такой ПР нормально потому что "ну че там смотреть, просто порядок навел". Другая проблема с отложенными исправлениями - необходимость создавать таски, еще один ПР, снова кого-то отвлекать, ждать пока посмотрят - короче, лишние накладные расходы.
Да и таски на рефакторинг, если они не выполнены сразу, потом так и висят в бэклоге потому что "надо фичи пилить".
Ну тебе в любом случае придётся возвращаться и смотреть, что изменено, чтобы убедится - исправили твой комментарий или не, так что с этой точки зрения экономии не вижу
@@programisli От конкретного случая зависит. Если исправление небольшое и было сделано сразу, мне как рецензенту скорее всего не придется "переключаться между задачами", я пойду чаю налью пока там коммит с исправлениями подвезут. А если в ПР много чего нужно переделать, то да, для рецензента большой разницы нет в рамках какой таски это будет сделано.
еще ни разу не видел PR :)
А как вы относитесь к кросс код ревью в командах различных размеров?
Никогда не сталкивался, но такое может проверить стиль. Без знания логики работы приложения баги выловить будет сложно
Видео очень интересное, но как программист начинающий, я не до конца понимаю принцип и причину создания пул реквестов. Он всегда виден всем? Нужен только для ревью? Как он должен делаться правильно?
Видимость в каждой компании по своему настраивается. Часто виден всем. Нужен для ревью кода, чтобы найти ошибки
константа равная пустой строке нужна для решения проблемы с «невидимыми» символами юникода, визуально в коде сравнение с пустой строкой, а по факту редактор просто не отображает этот символ. а в константе гарантировано ничего нет
Вот это может быть хорошим аргументом, а не просто - ну MS же придумали
Ответ конечно из ряда. Но вот как вам аргумент, что code style на проекте такой?
Если есть стиль, то это аргумент, его нужно придерживаться
Может string.empty как бы более понятный чем "". Можно подумать что в "" просто забыли добавить символы, а string.empty явно прям указывает что программист хотел записать пустую строку.
Но это не делает код читабельнее. Если нет политики компании писать именно String.Empty, то зачем это делать?
Если в компании не обязательно так писать можно и не писать. Просто мне кажется что так лучше.
пустая строка "" - это по сути антипаттерн "Магическое число". строковые литералы в коде методов смотрятся стремно.
как по мне empty читабильнее
А source код могли посмотреть?
Тогда .net кажется ещё не был открыт. А мне «» удобнее. Тут нужно или стиль корпоративный иметь или как-то договариваться
как самому учиться кодингу высоконагруженных систем, больших проектов, энтерпрайз? это и в плане архитектурных решений и структуры кода, и разных технических нюансов. книжек по этой теме практически нет.. только если по решениям, которые предполагают энтерпрайз, вроде Java EE..
Информации не так много, я учился на своих ошибках. Сейчас много видео а RUclips, я выкладываю немного на канале Програмысли видеоуроки.
@@programisli а самому для себя как создать "песочницу энтерпрайз"?) некое подобие большого проекта с искусственно созданной нагрузкой итд?)
В чем разница между "сделать код лучше" и "критиковать"? Если критика конструктивная, то это сделает код лучше. А критика должна быть конструктивная, иначе это не критика, а холивар. Вот холивара на пулреках быть не должно
Первый)
Обогнал :)
@@IgorGallemar что то позиции сдаешь)
а что ты еще умеешь?)
@@codingfox много чего, СУБД наше всё
Мне нравится подход Square к пулл реквестам - они сначала мерджат всё, а ревью делается постфактум. Но это, конечно, подходит для команды, где у всех достаточно высокий уровень.
Боюсь это будет расслаблять и мало кто будет смотреть потом код. Сначала же нужно своё закончить
@@programisli ну, я не знаю, как там устроены процессы, но подозреваю, что решается примерно так же, как и с ревью перед мерджем. Например, назначается обязательный ревьюер. Зато меньше задержек при разработке.
не совсем понял чего удалили мой комент ну ладно ) - вроде все по теме было !
Я ничего не удаляю, но иногда слышу о том, что комментарии пропадают и в спаме их нет. Сейчас проверю, может в спаме что появилось
Я ничего не удаляю, но иногда слышу о том, что комментарии пропадают и в спаме их нет. Сейчас проверю, может в спаме что появилось