Я правильно понимаю, что при запуске через go run ... отдельной утилиты с микроскопическим go.mod, лежащей в монорепе с гигантскими go.mod, всё равно скачаются все-все-все зависимости всех go.mod, которые есть в воркспейсе?
Предлагаю ещё не забывать про статический анализ. <...>
Да, согласен. Всё, что можно доверить роботам, стоит отдать роботам. Дополню только, что помимо стандартного инструментария любой крупный проект должен обрасти своим, чтобы автоматически проверять принятые в проекте специфические правила и ограничения. На масштабе такое очень хорошо окупается.
Если это вы меня процитировали, то я не вижу, чтобы я такое писал. Когда коммит разбивается на несколько, то изначально они в одной ветке находятся. Потом можно растащить по разным.
Разные пулл-реквесты должны быть из разных веток.
Вы абсолютно правы и я, вроде бы, нигде не писал обратного.
Только если это ваш личный проект и вы там один участник.
Ну не только, конечно. Есть и другие кейсы. Например, стартап в фазе PoC. Например, проект с ограниченным сроком жизни, вроде программного обеспечения к какому-нибудь уникальному ивенту или промосайта. Уверен, этими примерами список не исчерпывается. Загоняя себя в такие категоричные рамки, вы отбираете у себя возможность гибко регулировать баланс скорость-качество.
Критерия "нужно ли создавать пулл-реквест" тут быть не может. Тут должно быть железное правило: никаких коммитов в мастер, все изменения — только через пулл-реквесты, всегда, без исключений.
Вы чересчур категоричны :)
Это зависит от требуемого баланса скорости разработки и стабильности продукта. Иногда бывает норм вообще не ревьюить, сразу в прод фигачить. А иногда — через три комиссии любое, сколь угодно тривиальное, изменение проводить.
Вы описали разбиение на коммиты, но разбиение на коммиты не имеет никакого смысла.
Ревьювятся не коммиты, а результирующий дифф между веткой и мастером.
Как это, никакого смысла? Если всё в одном коммите, то как сделать разные Pull Request'ы для ревью?
Разбиение на коммиты является обязательным шагом перед выделением отдельных бранчей на ревью. Основная сложность связана именно с этим шагом. А когда отдельные изменения уже лежат по разным коммитам, нет никакой сложности из отдельных коммитов сделать отдельные бранчи.
По-моему начинать давать плохие пулл-реквесты "потому что ты такой сам читал"-вообще порочная практика. Это будет замкнутый круг. Лиды должны слать максимально хорошие пулл реквесты, чтобы с них брали пример.
+100
Но просто говорить что так плохо -тоже нелучший вариант-очень многие люди не делят пулл реквесты просто потому что не понимают зачем нужны маленькие пулл реквесты.
Если автора три раза попросили поделить большой PR, то в четвёртый раз он его уже поделит сам. Даже если он и не проникся, зачем это нужно. Но я тут не спорю с вашей точкой зрения. Гораздо лучше если автор проникся. И если он сам иногда также является ревьюером, то ему, однозначно, проникнуться будет проще.
Честно говоря не могу сказать что сталкиваюсь часто с таким отношением.
Редко кто в таком признаётся, конечно. Но по факту видно же, где ревьюер вчитался, а где шёл по диагонали.
Причем видел такое в ситуациях только когда код ревью проводится для "галочки"-на любые замечания у автора есть тысяча аругментов почему это надо было сделать именно так и по итогу споров просто ничего не правится.
Такое тоже видел. Если с автором невозможно нормально спорить, то нужно, чтобы с ним поговорил руководитель и объяснил, что это плохо. Ну а если не сработает, мы все знаем, что с таким автором нужно сделать :)
У меня хорошо работал вариант когда я кого-либо назначал "главным" по код-ревью, и это были все люди на проекте по очерди-тогда этот человек начинает ревьюить проект вычитавая полностью.
Интересный подход. Подумаю, можно ли у нас такое применить.
дает не очень хорошие результаты(т.е. нет реджектов кода или их мало)
Ревью даёт прекрасные результаты! Малое количество реджектов это следствие наличия процесса ревью. Если бы ревью не было, то качество кода было бы ниже.
Это можно сравнить с ограничениями скорости на дорогах. Если нет камер и риски водителя ограничиваются редким взаимодействием с гаишником, которого относительно легко заметить, то много водителей будут ездить 120 по городу. Когда появляются автоматические камеры, то их эффективность оценивается не в руб./с, а в том, что водители начинают нарушать гораздо реже.
В нашей компании тоже стараемся задействовать всех коллег в качестве ревьюеров. Но только эта мера не делает из людей хороших авторов, к сожалению. Я регулярно сталкиваюсь, например, с таким отношением к ревью, когда ревьюер говорит "ну мне тут очень сложный код отдали на ревью, поэтому я только нейминг по диагонали проверил". Культуру ревьюеров сформировать, пожалуй, ещё сложнее, чем культуру авторов. Слишком велик соблазн просто подождать два часа и нажать на кнопку "Approved", сделав вид, что ревью проведено. Если коллега ревью делает именно таким способом, то это никак не сделает его хорошим автором.
Я не утверждаю, что метод совсем не работает. Он ограниченно работает. Но более действенной нахожу обратную связь от ревьюеров. Когда ревьюер раз за разом терпеливо и спокойно объясняет автору, почему нужно разделить большой PR на несколько. Это на масштабе работает лучше, чем "раз ты дал мне PR на 5 тысяч строк, то на, почитай на 6".
Мы внутренние семинары ещё проводим. Как для авторов, так и для ревьюеров.
ну т.е. кто-нибудь занимается оптимизацией процесса(чтобы сделать быстрее\дешевле чем конкуренты) или просто есть внутренний бюджет и вы его расходуете?
Мы стараемся оптимизировать процессы, чтобы внесение изменений обходилось дешевле. Проект у нас "бесконечный", мы его будем развивать столько времени, сколько позволит бизнес. Поэтому, мы заинтересованы мыслить стратегически, заглядывая и на год, и на два, и на пять лет вперёд.
Не очень понял про "внутренний бюджет", т. к., очевидно, он у нас, в широком смысле, есть. Как и у всех.
Есть ли у вас какие-то формальные критерии, по которым определяете, нужно ли создавать Pull Request или можно коммитить и так?
Есть неформальный критерий, что тривиальные изменения можно мёржить без ревью. Определение "тривиальности" остаётся в качестве самостоятельного упражнения автору. Если что-то нехорошее всплывёт, что было занесено без ревью таким вот "тривиальным" изменением, с автором будет серьёзный разговор с внушением.
По-моему, имеет смысл делать это перед каждым коммитом
Если автор так делает, то автор — молодец! Не шучу. Я так не умею и всегда все хвосты подчищаю в самом конце. Я слышал также, что существуют люди, которые заранее всё правильно нарезают на коммиты. И без багов пишут!
У нас, обычно, ревью проходят либо без запросов на изменения, либо с косметическими запросами. В редких случаях требуются значительные переработки. Но это те случаи, ради которых ревью и существует. Такие ревью фильтруют решения с существенными недостатками.
Плюс, ревью формируют определённую культуру, когда авторы, зная требования ревьюеров, заранее делают всё по этим требованиям. В условиях отсутствия ревью авторы могут и не знать всех нюансов, даже если они где-то описаны в документации. Ревью распространяет единую корпоративную культуру разработки в команде.
Вопрос "как убедить менеджмент" справедлив и для, например, написания автотестов. И автотесты, и ревью кода не добавляют стоимости продукту напрямую. Однако, я себе не представляю адекватного менеджмента, который был бы против автотестов и ревью. Видел в жизни обратное, когда автотесты и ревью внедряются менеджментом, а разработчики сопротивляются.
Я применяю два способа, в зависимости от сложности ситуации. Если изменения практически независимы, то их можно отделить так:
"Скинуть" изменения из истории через git reset HEAD~. Если ваши изменения распределены по нескольким коммитам, то вместо HEAD~ должен быть хэш коммита, предшествующего вашим изменениям.
С помощью git add -i или пофайловым git add или любыми аналогами, которые у вас под рукой, добавить изменения в коммит. Закоммитить.
Повторить пункт 2 для каждого отдельного изменения.
Второй способ позволяет отделять изменения, которые тесно связаны:
Сохранить на всякий случай исходные коммиты в каком-нибудь отдельном бранче. Можно, в принципе, и просто где-то хэш коммита записать. Если что-то пойдёт не так, всегда можно будет начать сначала.
"Скинуть" изменения так же, как в пункте 1 из предыдущего способа.
Идём от обратного, удаляем изменения, которые не должны попасть в первую порцию изменений. Делаем это любым подходящим для вас способом. Часто это будет ваша любимая IDE.
Получили первую порцию изменений без остального. Делаем git add ... и git commit.
Возвращаем исходные изменения в рабочую копию через git checkout <хэш-из-п1> ..
Можем повторить шаги, начиная с 3, чтобы отделить ещё изменения.
Разумеется, это всё не какие-то волшебные способы, которые за вас могут отделить изменения за 10 секунд. Потребуется провести дополнительную работу. Обычно, это не занимает много времени, относительно времени, затраченного на написание исходных изменений. Но и удивляться не стоит, что на распутывание клубка из 3K+ строк и 10 связанных изменений нужно 2 часа. Это время окупается при ревью как временем ревьюера, так и качеством ревью.
О каких вариантах речь? Я перечислил, зачем нужно игроку привязывать основное мыло к игровому аккаунту.
Всё, что хочет пользователь — ввести свою почту
Здравомыслящий пользователь, как раз таки, не должен хотеть такого. Здравомыслящий пользователь свою основную почту бережёт. Его, обычно заставляют ввести почту, требуя её подтверждения при регистрации.
для удаления учётной записи требует явиться в офис с паспортом
Услышали какие-то сказки. Мало того, что сами ведётесь, так ещё и тиражируете. Вот информация из первоисточника: help.mail.ru/mail-help/faq/delete. На всякий случай попробовал, создал аккаунт, удалил аккаунт. Никто меня никуда с паспортом не попросил приходить.
тем более у компании, которая ему не нравится
Т. е. если ящик регистрировать требует компания, которая нравится, то это OK?
офисные правила запрещают думать иначе, чем сказало начальство?
Ну а такой фразой вообще можно крыть любые аргументы. Нет, уважаемый, всё, что я пишу является моей точкой зрения и не выражает точку зрения компании в целом. Переход на личности не позволяет мне продолжить с вами дискуссию, извините.
Я понимаю, о чём вы. Давайте рассуждать, зачем нужна привязка почты к игровому аккаунту:
1. Для получения внутриигровых уведомлений. Тут вы правы, получать внутриигровые уведомления удобно на свою основную почту. Но, многие, кстати, с вами не согласятся, т. к. не хотят «палить» своё основное мыло (или twitter/facebook/github, если аутентификация идёт через них) ради игры и используют треш-мыло для регистрации. На почте mail.ru есть переадресация, но это дополнительные телодвижения, как ни крути.
2. Для восстановления доступа к игровому аккаунту. Тут для вас никакой разницы нет, т. к. при регистрации аккаунта на mail.ru можно указать резервный адрес почты для восстановления доступа.
Riot'ы не заставляли меня создавать почту на @leagueoflegends.com
Посмотрел leagueoflegends.com. Там тоже требуют создавать аккаунт на leagueoflegends.com. Чем аккаунт на leagueoflegends.com отличается от аккаунта на mail.ru? Наличием почты? Ну так вас никто не заставляет ей пользоваться, опять же. Если бы при регистрации на leagueoflegends.com вам автоматически создали бы мыло suvitruf @leagueoflegends.com, это бы что-то изменило для вас?
Почему тогда не сделали?
Потому же, почему этого не сделал Steam, Google Play и др. Мы ориентируемся на лидеров :)
Почта на mail.ru — это просто аккаунт, с которого доступны сервисы компании. Более того, вас никто не заставляет пользоваться другими сервисами mail.ru, если вы хотите просто поиграть в Skyforge. Технически, разрешить вход через facebook/twitter/яндекс/github не является большой проблемой. Но, в этом случае мы всё равно будем регистрировать для вас внутриигровой аккаунт (и этот аккаунт будет находиться, как нетрудно догадаться, на серверах компании mail.ru). И любой другой сервис любой другой компании выполнит аналогичную процедуру.
Почему, конкретно для вас, регистрация аккаунта на mail.ru неприемлема для игры в конкретно Skyforge?
А есть какой-то способ сказать, что "вот этот конкретный
go.modне относится к воркспейсу"?Я правильно понимаю, что при запуске через
go run ...отдельной утилиты с микроскопическимgo.mod, лежащей в монорепе с гигантскимиgo.mod, всё равно скачаются все-все-все зависимости всехgo.mod, которые есть в воркспейсе?Спасибо!
Да, согласен. Всё, что можно доверить роботам, стоит отдать роботам. Дополню только, что помимо стандартного инструментария любой крупный проект должен обрасти своим, чтобы автоматически проверять принятые в проекте специфические правила и ограничения. На масштабе такое очень хорошо окупается.
Если это вы меня процитировали, то я не вижу, чтобы я такое писал. Когда коммит разбивается на несколько, то изначально они в одной ветке находятся. Потом можно растащить по разным.
Вы абсолютно правы и я, вроде бы, нигде не писал обратного.
Ну не только, конечно. Есть и другие кейсы. Например, стартап в фазе PoC. Например, проект с ограниченным сроком жизни, вроде программного обеспечения к какому-нибудь уникальному ивенту или промосайта. Уверен, этими примерами список не исчерпывается. Загоняя себя в такие категоричные рамки, вы отбираете у себя возможность гибко регулировать баланс скорость-качество.
Вы чересчур категоричны :)
Это зависит от требуемого баланса скорости разработки и стабильности продукта. Иногда бывает норм вообще не ревьюить, сразу в прод фигачить. А иногда — через три комиссии любое, сколь угодно тривиальное, изменение проводить.
Как это, никакого смысла? Если всё в одном коммите, то как сделать разные Pull Request'ы для ревью?
Разбиение на коммиты является обязательным шагом перед выделением отдельных бранчей на ревью. Основная сложность связана именно с этим шагом. А когда отдельные изменения уже лежат по разным коммитам, нет никакой сложности из отдельных коммитов сделать отдельные бранчи.
+100
Если автора три раза попросили поделить большой PR, то в четвёртый раз он его уже поделит сам. Даже если он и не проникся, зачем это нужно. Но я тут не спорю с вашей точкой зрения. Гораздо лучше если автор проникся. И если он сам иногда также является ревьюером, то ему, однозначно, проникнуться будет проще.
Редко кто в таком признаётся, конечно. Но по факту видно же, где ревьюер вчитался, а где шёл по диагонали.
Такое тоже видел. Если с автором невозможно нормально спорить, то нужно, чтобы с ним поговорил руководитель и объяснил, что это плохо. Ну а если не сработает, мы все знаем, что с таким автором нужно сделать :)
Интересный подход. Подумаю, можно ли у нас такое применить.
Ревью даёт прекрасные результаты! Малое количество реджектов это следствие наличия процесса ревью. Если бы ревью не было, то качество кода было бы ниже.
Это можно сравнить с ограничениями скорости на дорогах. Если нет камер и риски водителя ограничиваются редким взаимодействием с гаишником, которого относительно легко заметить, то много водителей будут ездить 120 по городу. Когда появляются автоматические камеры, то их эффективность оценивается не в руб./с, а в том, что водители начинают нарушать гораздо реже.
В нашей компании тоже стараемся задействовать всех коллег в качестве ревьюеров. Но только эта мера не делает из людей хороших авторов, к сожалению. Я регулярно сталкиваюсь, например, с таким отношением к ревью, когда ревьюер говорит "ну мне тут очень сложный код отдали на ревью, поэтому я только нейминг по диагонали проверил". Культуру ревьюеров сформировать, пожалуй, ещё сложнее, чем культуру авторов. Слишком велик соблазн просто подождать два часа и нажать на кнопку "Approved", сделав вид, что ревью проведено. Если коллега ревью делает именно таким способом, то это никак не сделает его хорошим автором.
Я не утверждаю, что метод совсем не работает. Он ограниченно работает. Но более действенной нахожу обратную связь от ревьюеров. Когда ревьюер раз за разом терпеливо и спокойно объясняет автору, почему нужно разделить большой PR на несколько. Это на масштабе работает лучше, чем "раз ты дал мне PR на 5 тысяч строк, то на, почитай на 6".
Мы внутренние семинары ещё проводим. Как для авторов, так и для ревьюеров.
Мы стараемся оптимизировать процессы, чтобы внесение изменений обходилось дешевле. Проект у нас "бесконечный", мы его будем развивать столько времени, сколько позволит бизнес. Поэтому, мы заинтересованы мыслить стратегически, заглядывая и на год, и на два, и на пять лет вперёд.
Не очень понял про "внутренний бюджет", т. к., очевидно, он у нас, в широком смысле, есть. Как и у всех.
Спасибо!
Есть неформальный критерий, что тривиальные изменения можно мёржить без ревью. Определение "тривиальности" остаётся в качестве самостоятельного упражнения автору. Если что-то нехорошее всплывёт, что было занесено без ревью таким вот "тривиальным" изменением, с автором будет серьёзный разговор с внушением.
Если автор так делает, то автор — молодец! Не шучу. Я так не умею и всегда все хвосты подчищаю в самом конце. Я слышал также, что существуют люди, которые заранее всё правильно нарезают на коммиты. И без багов пишут!
У нас, обычно, ревью проходят либо без запросов на изменения, либо с косметическими запросами. В редких случаях требуются значительные переработки. Но это те случаи, ради которых ревью и существует. Такие ревью фильтруют решения с существенными недостатками.
Плюс, ревью формируют определённую культуру, когда авторы, зная требования ревьюеров, заранее делают всё по этим требованиям. В условиях отсутствия ревью авторы могут и не знать всех нюансов, даже если они где-то описаны в документации. Ревью распространяет единую корпоративную культуру разработки в команде.
Вопрос "как убедить менеджмент" справедлив и для, например, написания автотестов. И автотесты, и ревью кода не добавляют стоимости продукту напрямую. Однако, я себе не представляю адекватного менеджмента, который был бы против автотестов и ревью. Видел в жизни обратное, когда автотесты и ревью внедряются менеджментом, а разработчики сопротивляются.
Я применяю два способа, в зависимости от сложности ситуации. Если изменения практически независимы, то их можно отделить так:
git reset HEAD~. Если ваши изменения распределены по нескольким коммитам, то вместоHEAD~должен быть хэш коммита, предшествующего вашим изменениям.git add -iили пофайловымgit addили любыми аналогами, которые у вас под рукой, добавить изменения в коммит. Закоммитить.Второй способ позволяет отделять изменения, которые тесно связаны:
git add ...иgit commit.git checkout <хэш-из-п1> ..Разумеется, это всё не какие-то волшебные способы, которые за вас могут отделить изменения за 10 секунд. Потребуется провести дополнительную работу. Обычно, это не занимает много времени, относительно времени, затраченного на написание исходных изменений. Но и удивляться не стоит, что на распутывание клубка из 3K+ строк и 10 связанных изменений нужно 2 часа. Это время окупается при ревью как временем ревьюера, так и качеством ревью.
Здравомыслящий пользователь, как раз таки, не должен хотеть такого. Здравомыслящий пользователь свою основную почту бережёт. Его, обычно заставляют ввести почту, требуя её подтверждения при регистрации.
Услышали какие-то сказки. Мало того, что сами ведётесь, так ещё и тиражируете. Вот информация из первоисточника: help.mail.ru/mail-help/faq/delete. На всякий случай попробовал, создал аккаунт, удалил аккаунт. Никто меня никуда с паспортом не попросил приходить.
Т. е. если ящик регистрировать требует компания, которая нравится, то это OK?
Ну а такой фразой вообще можно крыть любые аргументы. Нет, уважаемый, всё, что я пишу является моей точкой зрения и не выражает точку зрения компании в целом. Переход на личности не позволяет мне продолжить с вами дискуссию, извините.
1. Для получения внутриигровых уведомлений. Тут вы правы, получать внутриигровые уведомления удобно на свою основную почту. Но, многие, кстати, с вами не согласятся, т. к. не хотят «палить» своё основное мыло (или twitter/facebook/github, если аутентификация идёт через них) ради игры и используют треш-мыло для регистрации. На почте mail.ru есть переадресация, но это дополнительные телодвижения, как ни крути.
2. Для восстановления доступа к игровому аккаунту. Тут для вас никакой разницы нет, т. к. при регистрации аккаунта на mail.ru можно указать резервный адрес почты для восстановления доступа.
Посмотрел leagueoflegends.com. Там тоже требуют создавать аккаунт на leagueoflegends.com. Чем аккаунт на leagueoflegends.com отличается от аккаунта на mail.ru? Наличием почты? Ну так вас никто не заставляет ей пользоваться, опять же. Если бы при регистрации на leagueoflegends.com вам автоматически создали бы мыло suvitruf @leagueoflegends.com, это бы что-то изменило для вас?
Потому же, почему этого не сделал Steam, Google Play и др. Мы ориентируемся на лидеров :)
Почему, конкретно для вас, регистрация аккаунта на mail.ru неприемлема для игры в конкретно Skyforge?