Комментарии 26
Разбейте пул-реквест на более мелкие куски, которые имеют смысл отдельно друг от друга. Так вы поможете рассмотреть их должным образом и быстро.
Огромныей пулл-реквест — как кашель, побочный эффект, а не самостоятельная проблема.
Почему он большой? Потому что или задача большая, или задач несколько, но из-за долгого процесса выкладки копятся они (задачи/пуллреквесты), а для текущего небольшого PR нужны изменения из другого, вот и принимается решение в одном и написать, иначе потом при рефакторинге корневого все превращается в какую-то бойню. Еще и конфликты с другими.
Рецептом вижу — мелкие PR с минимальным инкрементом, которые могут долетать до прода «сегодня». А это довольно интересный и часто сложный вопрос для организации разработки/QA.
…
Вообще кайф, когда мелкие PR доходят до прода. Дофамин и вот это все ощущение удовлетворенности
мелкие PR с минимальным инкрементом, которые могут долетать до прода «сегодня»
Пример из жизни. Предприятие занимается одним видом деятельности. Торгует сникерсами. Торгует сникерсами 15 лет, и делает это довольно успешно. И тут решили торговать не только сникерсами, но и мороженым. А ещё через пять лет — рыбой. И ещё через пару лет решили запустить собственный супермаркет, все как у больших.
Как тут бить на мелкие икременты, которые могут долетать до прода?
Пример жизненный, сроки реальные, чуть-чуть изменена отрасль.
Я вот тоже слабо понимаю, как эту сову на глобус в реальном мире натягивать.
PR не означает, что новая функциональность доступна. Можно, например, включать через feature flags.
PR не означает, что сразу пойдет в релиз. Например, есть один большой PR — разбили на небольшие, они прошли все процессы в рамках одного релиза.
А про мелкие инкременты — это как раз реальность. Как в софте, так и в реальном мире. Например, сначала провели маркетинговый анализ, потом нашли поставщиков, заключили договора, добавили товар в кассу, изменили инструкции работы персонала, заказали новые маркетинговые материалы, закупили морозильные лари для мороженного — много-много разных этапов как в оффлайн, так и в софте. Понятно, что ценность начинается с момента начала продаж мороженного, но как до, так и после начала есть множество этапов, которые имеет смысл постепенно поставлять.
Хорошая аналогия малых PR в магазине: выложить новые рекламные таблички, переставить товар и т.п.: их много, они нужны практически каждый день, они немного улучшают продажи. Это не отменяет и большие, но они обычно так же вполне реально постепенно добавляются, хоть и не (особо) заметно для пользователя, пока выключены.
PR не означает, что сразу пойдет в релиз. Например, есть один большой PR — разбили на небольшие, они прошли все процессы в рамках одного релиза.
А про мелкие инкременты — это как раз реальность. Как в софте, так и в реальном мире. Например, сначала провели маркетинговый анализ, потом нашли поставщиков, заключили договора, добавили товар в кассу, изменили инструкции работы персонала, заказали новые маркетинговые материалы, закупили морозильные лари для мороженного — много-много разных этапов как в оффлайн, так и в софте. Понятно, что ценность начинается с момента начала продаж мороженного, но как до, так и после начала есть множество этапов, которые имеет смысл постепенно поставлять.
Хорошая аналогия малых PR в магазине: выложить новые рекламные таблички, переставить товар и т.п.: их много, они нужны практически каждый день, они немного улучшают продажи. Это не отменяет и большие, но они обычно так же вполне реально постепенно добавляются, хоть и не (особо) заметно для пользователя, пока выключены.
> сначала провели маркетинговый анализ, потом нашли поставщиков, заключили договора, добавили товар в кассу, изменили инструкции работы персонала, заказали новые маркетинговые материалы, закупили морозильные лари для мороженного
А потом до IT доводят, что через две недели запускается новая продукция, и срочно нужна поддержка в информационной системе.
А потом до IT доводят, что через две недели запускается новая продукция, и срочно нужна поддержка в информационной системе.
НЛО прилетело и опубликовало эту надпись здесь
Всё это отлично, но, что делать, когда ну не бьется PR: надо у БД поменять один вид дерева на другой, вот прямо то, как мы индексы храним, или алгоритм консенсуса. Не получится это разбить.
Исключения всегда есть, но это исключения (5%/95%).
Плюс, если я правильно понял пример, то мы вводим другой вид дерева параллельно за фиче-флагом. И постепенно разрабатываем отдельными PR пока не будет достаточно для релиза. А уж при релизе можем старое удалить сразу (хотя странно), а можем вводить новый функционал через настройку.
Плюс, если я правильно понял пример, то мы вводим другой вид дерева параллельно за фиче-флагом. И постепенно разрабатываем отдельными PR пока не будет достаточно для релиза. А уж при релизе можем старое удалить сразу (хотя странно), а можем вводить новый функционал через настройку.
Фича- флаг не сильно поможет, каждый pr будет нефункциональным, если вообще компилироваться.
Ну или классика — подтягивание апстрима при работе в форке, обновление фреймворка или версии ЯП. Все это порождает большие pr, которые можно бить на маленькие только искусственно, жертвуя осмысленностью pr
Ну, все-таки, чтобы собиралось нужно стараться. А вот не все тесты прошли и не все функционально готово — да, иногда этим придется пожертвовать. Альтернатива — PR с багами, который особо не смотрели.
Не все имеет смысл делить (особенно обновление из upstream), вопрос же не в 100%/0%, а общем правиле (95/5).
Не все имеет смысл делить (особенно обновление из upstream), вопрос же не в 100%/0%, а общем правиле (95/5).
Или пачка PR, в каждом из которых валится пачка тестов и неясно, что же там проверять, если тесты валятся. И вновь будет один финальный "а теперь чиним всё и половину переписываем". Что мы выиграли?
Про 95/5, я думаю, это от области работы зависит. У нас это, скорее, 30/70 — RnD.
Что проверять всегда ясно — соблюдение соглашений разработки, best practices, опечатки, логические ошибки. Новый код покрыт тестами и не падает, но не весь старый функционал может работать. Никаких «финальных» PR.
> Про 95/5, я думаю, это от области работы зависит. У нас это, скорее, 30/70 — RnD.
Не верю. Просто не выработан навык разбивать большие задачи на задачи на 1-2 дня (1 задача — 1 PR и при таких временных рамках он редко большой).
Нужно это или не нужно в вашем случае — отдельный вопрос. Может вам PR вообще не нужны, если вы только прототипы делаете, а не production-код.
> Про 95/5, я думаю, это от области работы зависит. У нас это, скорее, 30/70 — RnD.
Не верю. Просто не выработан навык разбивать большие задачи на задачи на 1-2 дня (1 задача — 1 PR и при таких временных рамках он редко большой).
Нужно это или не нужно в вашем случае — отдельный вопрос. Может вам PR вообще не нужны, если вы только прототипы делаете, а не production-код.
Ну давайте, расскажите, как в RnD задачки делать за 1-2 дня.
К продуктовой разработке весь мир не сводится.
Не, вы передергиваете. Есть задача как некая ценность для заказчика, а есть задача как квант работы для исполнителя. И можно выстроить много уровней между ними (эпик, стори, сабтаск — если в терминах Jira, например). Так вот нижний уровень всегда может быть достаточно маленьким.
Например, вы отводите ветку и начинаете разрабатывать новый офигенный алгоритм. Недели 3 по предварительной оценке на первый этап. Но в каждый конкретный день вы делаете вполне определенные вещи — их и можно класть в PR. Например, несколько вспомогательных функций для работы с многопоточностью.
И вовсе не обязательно, чтобы в первый же день были детально расписаны задачи на все 3 недели: достаточно описания общего плана, а конкретные работы создаются на ближайшие дни — на горизонт видимости. Или даже закрывать задачи по факту: отработали день, посмотрели что получилось в PR, описали.
Опять же, может задачка и не заканчивается PR — что-то попробовали, приложили к задачке отчет о неудачной гипотезе и пошли дальше.
А вот чтобы закончилось 100+ измененных файлов — это просто явное или не явное нежелание делать работу постепенно.
Другими словами PR — это процессный (менеджерский) инструмент. У него есть ограниченная применимость, как и у любого инструмента. Например, меньше 100 файлов в PR, а то отдача от процесса PR будет низкая. Для хорошей стыковки это накладывает ограничения на размер задач исполнителей. Можно ли их сделать небольшими? Да. Нужно ли? Отдельный вопрос, тут нужно смотреть на всю систему управления, но обычно это так же считается best practice. Искусство тут не в специфике задач, а в процессе разбиения задач на подзадачи: если кратко постфактум можно описать что исполнитель делал, то и задачу такую можно поставить и такой PR сформировать. Истории из серии «сегодня продолжаю работать и завтра над этим работаю» — просто нежелание по той или иной причине описать что реально делалось.
PS. Ладно, что-то много уже написал. Надеюсь, точка зрения понятна.
Например, вы отводите ветку и начинаете разрабатывать новый офигенный алгоритм. Недели 3 по предварительной оценке на первый этап. Но в каждый конкретный день вы делаете вполне определенные вещи — их и можно класть в PR. Например, несколько вспомогательных функций для работы с многопоточностью.
И вовсе не обязательно, чтобы в первый же день были детально расписаны задачи на все 3 недели: достаточно описания общего плана, а конкретные работы создаются на ближайшие дни — на горизонт видимости. Или даже закрывать задачи по факту: отработали день, посмотрели что получилось в PR, описали.
Опять же, может задачка и не заканчивается PR — что-то попробовали, приложили к задачке отчет о неудачной гипотезе и пошли дальше.
А вот чтобы закончилось 100+ измененных файлов — это просто явное или не явное нежелание делать работу постепенно.
Другими словами PR — это процессный (менеджерский) инструмент. У него есть ограниченная применимость, как и у любого инструмента. Например, меньше 100 файлов в PR, а то отдача от процесса PR будет низкая. Для хорошей стыковки это накладывает ограничения на размер задач исполнителей. Можно ли их сделать небольшими? Да. Нужно ли? Отдельный вопрос, тут нужно смотреть на всю систему управления, но обычно это так же считается best practice. Искусство тут не в специфике задач, а в процессе разбиения задач на подзадачи: если кратко постфактум можно описать что исполнитель делал, то и задачу такую можно поставить и такой PR сформировать. Истории из серии «сегодня продолжаю работать и завтра над этим работаю» — просто нежелание по той или иной причине описать что реально делалось.
PS. Ладно, что-то много уже написал. Надеюсь, точка зрения понятна.
Вы в RnD работали?
Это будет скорее не «настоящий» пр, а лог ведения экспериментов. Штука интересная, но не совсем то, о чем говорится в статье.
«Настоящий» PR — как «настоящий» мужчина или «настоящая» женщина — понятие ускользающее… PR — это PR, вполне осязаемая вещь в гите и процесс вокруг этой вещи. Где противоречие с описанным в статье — непонятно.
Вы описываете журнал исследований. Попробовал что-то, получил результат, какой бы он не был, закоммитил на будущее, с понятным комментом. Скорее всего даже в отдельном репозитории, специально сделанным под эту задачу.
«Настоящий» пр, в смысле разработки софта — это когда коммитят только то, в чем уверены. Сделал часть — запушил, сделал еще одну — запушил. А если непонятно как делать — создается отдельный репозиторий, там проверяются разные подходы, выбирается лучший, потом этот лучший реализуется непосредственно в репозитории проекта и пушится.
«Настоящий» пр, в смысле разработки софта — это когда коммитят только то, в чем уверены. Сделал часть — запушил, сделал еще одну — запушил. А если непонятно как делать — создается отдельный репозиторий, там проверяются разные подходы, выбирается лучший, потом этот лучший реализуется непосредственно в репозитории проекта и пушится.
Интересно вообще в скольки процентах компаний код ревью поставлено грамотно?
Один из лучших способов ускорить код-ревью – избавиться от него
Это сарказм, надеюсь?
Смотря как посмотреть. Я очень редко получаю полезные комментарии, но трачу гигантское количество времени на оформление, на какие-то бесполезные споры о том, как «красивее», «лучше», «понятнее», «правильнее» (а скорее о том, как кто привык). Лично у меня процесс ревью отнимает кучу сил и нервов, а полезного сигнала я получаю крайне мало. Я мог бы сделать в 10 раз больше полезных дел, если бы не тратил время на обсуждение моего кода с теми, чьё мнение мне не очень-то интересно. Безусловно, есть коллеги, с которыми работать одно удовольствие, и от которых я с благодарностью принимаю любого рода критику и предложения, но в основном же ревью проводят «все подряд» во имя мифического «шаринга знаний», и от этого процесса лично у меня одни расстройства :)
Расскажите о своём опыте и своей точке зрения.
Расскажите о своём опыте и своей точке зрения.
У меня опыт скорее положительный, чем отрицательный.
Ну, это опыт с моей текущей колокольни: аутсорс в энтерпрайзе, команды по 6-25 человек разработчиков на проект.
Недавно был опыт фриланса, где код-ревью ограничивалось принципом «оно работает — вливай в девелоп». Качество кода было плавающим, очень много вещей разработчики изобретали заново в проекте, размером в 5-7 тысяч строк кода.
- Код-ревью позволяет шарить знания («а что происходит в другом куске кода большого проекта»).
- Код-ревью позволяет подтягивать общий уровень разработчиков. Если сениор ревьюит джуниора/миддла — он подскажет, как сделать лучше или направит в нужное русло. Если джуниор ревьюит сениора — он подмечает лучшие практики. Иногда он видит сильно усложненный код — и просит его упростить/снабдить комментариями. И в таком случае надо идти навстречу — код ведь чаще читают, чем пишут.
- Код-ревью позволяет выработать общий стандарт кодирования не на бумаге. А если он есть на бумаге — закрепить его практикой.
- В конце концов, код-ревью отлавливает баги, когда кто-то по незнанию меняет участок кода, который может что-то поломать, и это не покрыто тестами и комментариями по ряду причин.
- Код-ревью держит качество кода и позволяет не скатываться до уровня «ну тут все понятно, комментарии не нужны, а тут можно и бизнес-валидацию прямо в контроллере сделать».
- Код-ревью (а точнее мерж-реквесты) прекрасно сочетаются с всякими прогонами тестов, статическим анализом и прочими фишками.
Ну, это опыт с моей текущей колокольни: аутсорс в энтерпрайзе, команды по 6-25 человек разработчиков на проект.
Недавно был опыт фриланса, где код-ревью ограничивалось принципом «оно работает — вливай в девелоп». Качество кода было плавающим, очень много вещей разработчики изобретали заново в проекте, размером в 5-7 тысяч строк кода.
… и сам я тоже не очень-то люблю кому-то что-то ревьюить. С теми людьми, с кем ты не «на одной волне» постоянно будут расходиться мнения, и к сожалению всегда есть возможность просто забить на твои комментарии. «Спасибо за фидбек, но оставлю-ка я так как есть», «Может быть потом, в следующих ревизиях» – и естественно никто ничего никогда не переделывает. Когда видишь просто кучу макарон, то возникает чувство бессилия и бесполезности этого процесса, потому что с одной стороны хочется этот код просто сжечь или хотя бы забыть, с другой – вырабатываешь какую-то терпимость и равнодушие чтоли. Пишешь «Looks Good To Me», выдыхаешь, и хвалишь коллегу за impact. Но лично у меня на душе возникает какая-то тоска от происходящего.
Невозможно помочь тем, или научить тех, кто не хочет. А тех, кто хочет, имхо палкой в код-ревью загонять не надо.
Невозможно помочь тем, или научить тех, кто не хочет. А тех, кто хочет, имхо палкой в код-ревью загонять не надо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как ускорить код-ревью