есть конечно

Покрытие покажет 61% вместо необходимого 66%… отличишь? это задача ревьювера, поздравляю, у вас бестолковый ревью

указываешь просто список файлов и профит

Покрытие покажет 61% вместо необходимого 66%… отличишь? это задача ревьювера, поздравляю, у вас бестолковый ревью

в твоей картине мира, пожалуй. Но т.к. на неё насрать, никто не в обиде :)

отличу, если что

Я вот хотел про насрать написать давно, но я вежливый… не могу просто так написать все, что о тебе думаю

или еще кейс, написал кривой запрос в базу, написал неоптимальный индекс, прод упал… нагрузочное тестирование? Это так, еще один миф…

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

отличу, если что

и как же? Новая задача, по сути 90% новых файлов. Какое покрытие должно быть для автоматического срабатывания проблемы? 80% 70% 66.6%? Как это оценить в новой задаче, которую видел только разработчик?

о срачик, у каждого свой огород и закопаны свои мины в нем

и как же? Новая задача, по сути 90% новых файлов. Какое покрытие должно быть для автоматического срабатывания проблемы? 80% 70% 66.6%? Как это оценить в новой задаче, которую видел только разработчик?

чё?)

да я пытаюсь про идеальный мир говорить… его не существует, но многие разработчики любят раздувать щеки и представлять себя в нем и рассуждать о нем… если я расскажу реальность, сделают вид, что “так бывает только у мудаков… а мы вот все на Скалу переписываем” ?

Давайте жить дружно

Вот и усе

да я пытаюсь про идеальный мир говорить… его не существует, но многие разработчики любят раздувать щеки и представлять себя в нем и рассуждать о нем… если я расскажу реальность, сделают вид, что “так бывает только у мудаков… а мы вот все на Скалу переписываем” ?

в жопу идеальный мир. Построй простую цепочку: 1. Есть реквест 2. по нему прогнались всякие фиксеры и анализаторы. Все недочёты соскладировались, ушли в репорты 3. по нему прошли все тесты, сгенерирось покрытие. Тестов нет/упали - ушло в репорты. когда дело дошло до ревьювера, он смотрит на список факапов, смотрит что было покрыто (можно на 80% класс геттерами и сеттерами, минуя логику). Посмотрел где, что и как тестилось - со спокойной душой пошёл искать, как ты выразился, тяжёлые запросы. Или не пошёл, а вернул на доработку. Профит

Мы вроде как говорили, что ревью после деплоя только и никак иначе, да?

Мы вроде как говорили, что ревью после деплоя только и никак иначе, да?

нет, о таком мы не говорили

Мы вроде как говорили, что ревью после деплоя только и никак иначе, да?

по факту = в момент создания пр.

ревью после деплоя аще нахер не нужно

так это что же получается такое, товарищи?! // Убежал менять название резюме на PHP-бог и приписывать к зп пару нулей

так это что же получается такое, товарищи?! // Убежал менять название резюме на PHP-бог и приписывать к зп пару нулей

с одним нулём-то разобрался?)

“Ревьювить перед деплоем - странная затея” (с) Максим

“Ревьювить перед деплоем - странная затея” (с) Максим

следует перевести, как "ревьювить в момент завершения задачи" - ок затея.

а непосредственно перед деплоем - уг.

вот кстати любопытно как люди любят интерпретировать неоднозначные высказывания, наверное это какое-то когнитивное искажение

pr - автотест - ревью - деплой… как бы перед деплоем, не?

да не обязательно. Ну вот прям совсем не обязательно

ну ок

pr может быть сделан в любой момент времени. Он к деплою аще никакого отношения не имеет

с одним нулём-то разобрался?)

нет =(

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

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

по факту = в момент создания пр.

у нас сборки автоматом после коммита

а не только после создания pr

у нас сборки автоматом после коммита

ну этот момент уже специфичен и идёт по договорённости. Общий смысл не меняется

при обновление pr (ветки) тоже происходит

ну да

надо осилить собрать весь материал на эту тему ото у всех кто в лес кто по дрова кто в докеры кто в хардкодинг)

вообще много где видел выкладка релиза это целое приключение и геморой

почти не видел тех у кого это было бы легко и гарантированно без факапов

минимум 1 факап в пол года (империческая оценка)

тот же coveralls + psalm с бОльшей долей вероятности покажут, что кто-то зафакапил, чем человек. Люди - существа ненадёжные. а цифра в покрытии - аще мусор, на неё не завяжешься (ну если только цели не стоит). Его можно нагнать синтетически, минуя бизнесс-логику.

но в общем меня интересовал вопрос раздачи на ревью и соблюдение равномерной загрузки ревьюверов, особо если команда 10-15 человек, а не что ревьювер делает… что именно он делает - зависит от особенностей проекта и обсуждать не итнересно

кто бы что не практиковал, сине-зеленые выливки, автоматизация и тд

тот же coveralls + psalm с бОльшей долей вероятности покажут, что кто-то зафакапил, чем человек. Люди - существа ненадёжные. а цифра в покрытии - аще мусор, на неё не завяжешься (ну если только цели не стоит). Его можно нагнать синтетически, минуя бизнесс-логику.

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

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

он такой +\- у всех)

но в общем меня интересовал вопрос раздачи на ревью и соблюдение равномерной загрузки ревьюверов, особо если команда 10-15 человек, а не что ревьювер делает… что именно он делает - зависит от особенностей проекта и обсуждать не итнересно

мое имхо заключается в том что таску вешаешь на ревью

и у кого есть желание смотрит и ставит апрув если согласен

типо добровольно и пожеланию

ну такой расклад не на ревью похож, а на перекладывание ответсвенности

тоесть создаются pr и человек по желанию их ревьют

любит ревьюить смотрит чаще

если тебе важно чье то мнение, просишь его в пм

нет аппрувов нет оконченной таски

не оконченна таска не ушла на тестирование

тоесть создаются pr и человек по желанию их ревьют

просто по желанию никто грех на душу брать не будет) зачем им это)

не протестированна не ушла в релиз нет в проекте

чем дольше нет в проекте тем больше фиксить конфликтов

поэтому ты заинтересован чтобы это проходило получше

имхо все выше сказанное

ну по идее зависшее должно решаться на ежедневном стендапе

мне кажется автор может написать кому то из коллег с просьбой типо посмотри

ERROR: S client not available

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

ну, имхо, “кто угодно” равноценно “никому”…. ну если только не попадется кто-то органически получающий удовольствие от ревью… но, имхо, такие люди изначально конфликтные, а ревью - это сильный компромис часто…

а разница от назначения по указке ?

можно написать сервис who review today xD

или дежурного назначать)))

если в процессе вписано, то это уже твоя работа

какие еще извращенные варианты можно придумать

о сразу нанимать человека с компетенцией review

если в процессе вписано, то это уже твоя работа

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

и от того если что то куда то вписать это не значит что оно будет выполняться

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

Добровольно точно ничего не будет

компромисы, да это ревью

Добровольно точно ничего не будет

будет что то из разряда, давай я твою таску посмотрю а ты мою ?

См. п. про надежность людей)

будет что то из разряда, давай я твою таску посмотрю а ты мою ?

Это нормально, но это не поток же

программист должен решение передать на тестирование

пока оно не прошло ревью это вина программиста

чужое совершенство никого не интересует, только свое ;)

хуевый там код или никто его не хочет ревьюить

или ведет он себя как гондон

какая то токсичная обстановка получается, все работают из под указки

каждому менеджера чтобы следил

пока оно не прошло ревью это вина программиста

это да, вот только не в компетенции программиста что то указывать другим... если все заняты своими задачами

дело не в указание а в просьбе

и комуникации между (горизонтальные связи)

имхо конечно же

но если в команде никто ничего не хочет делать а вся работа только из под палки

то люди начнут еще больше охуевать

имхо