artiom -> debian-russian@lists.debian.org @ Sat, 31 Mar 2018 14:18:00 +0300:
>> >> >> >> За коммитами джуниоров просто присматривают вручную. Недолго, >> человек >> >> >> >> либо обучается, либо идет искать работу в другом месте. >> >> >> >> >> >> >> > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, >> код >> >> >> > сложный, хотелось бы видеть, что уйдёт в репозиторий. >> >> >> >> >> >> В одной из контор у нас были любители почитать код, уходящий в >> >> >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать >> коммиты >> >> >> желающим. По почте. Тем же способом присматривали за джуниорами. >> >> >> >> >> > Примерно так и есть, но почта заменяется ccollab (или, в общем >> случае, >> >> > любым web интерфейсом), и код не проходит в репозиторий без >> одобрения. >> >> >> >> Тут важный момент - не веб или почта "код не проходит в репозиторий без >> >> одобрения". У нас проходил. Мой point в том, что проблем от этого не >> >> происходит. >> >> >> > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой >> > практики. >> >> Собственно, системы управления версиями придуманы ровно для этой >> ситуации. Чтобы заменить трехслойную бюрократию ревью, которая работает >> месяц, но тоже пропускает баги, возможностью найти и откатить изменение, >> если оно оказалось неудачным. >> >> А чтобы неудачное изменение не долетело до заказчика, существует >> релизный цикл. И ревью его необходимости не отменяет. >> > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из > репозитория, на которую уже понакоммитили и заложили функционал. Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую очень не сразу удалось обнаружить, не брали никакие разумные тесты, и трудоемко было потом починить. Так и не починили, кстати. Причем по крайней мере два первых ревью (два разных человека, входивших в разное время в проект, внимательно читали этот код) она тоже успешно проскочила. Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки находится тысяча первый ревьюер, который таки замечает багу и делает эксплойт. А обычно бага либо легко правится, либо быстро замечается. В идеале и то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе реализации фичи, но так бывает не всегда :) >> >> >> Практика показывает, что читать код _до_ попадания в репозиторий - >> не >> >> >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить. >> >> >> >> >> > Но сборки уже будут собраны и отправлены на тестирование, так не >> лучше >> >> > ли - не допустить? >> >> > Какая практика? >> >> > В чём нехорошесть данной идеи? >> >> >> >> Тормозной путь. Между моментом изменения кода и моментом, когда код >> >> будет изменен, проходит время. >> > Как минус, так и плюс. >> >> В течение этого времени в системе присутствуют и старые, и новые баги. >> Где плюс? >> > Нет, присутствуют только старые баги, которые уже известны, проверены и > одеты в пиджак, так что стали напоминать фичи. В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И поверх них уже идет работа. И не факт, кстати, что старые баги известны. Мы можем говорить о ревью, например, фикса свеженаступленной грабли. Она, может, в коде и пару лет уже, но важный заказчик наступил на нее только сегодня, а до него просто никому не приходило в голову проделать именно эту последовательность действий. > А тут новые баги, которые успеют сломать тестирование, например, в > результате чего могут не пройти другие тесты и т.п.. > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты, > однако есть факты на практике). На практике тесты для того и существуют, чтобы баги их ломали. Один фиг, если тест сломался, то багу надо чинить. Если бага сломала сразу много тестов, починка приоритетна, и все дела. >> > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и >> > ждать ответов автора (который в этом время уже над другим работает), к >> > тому же, ревьюверов бывает несколько. >> >> Я про прерывания не процесса ревью, а про прерывания процесса своей >> работы необходимостью ревью. Для ревью надо загрузить в голову контекст >> той задачи, к которой относится просматриваемый код. Он там неизбежно >> заменит контекст своей задачи. После ревью придется снова грузить свой. >> Это время, и в случае сложной задачи весьма изрядное. От 15 минут до >> часа каждая перегрузка, а их тут две. > Ну час - это явный перебор. Это значит, у тебя все задачи простые. > А отрыв на 15 минут - не критично: вы же не соревновательным > программированием занимаетесь, надеюсь? Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст. > Иногда вообще полезно от задачи оторваться, бывает. В моем опыте оторваться от задачи полезно, а вот заменять в голове ее контекст контекстом другой задачи как раз вредно. Ну да люди разные, задачи тоже. > Другое дело, если ревью много. Тогда да, на них забивают. И это, кстати, тоже. Не написанный тест ловится хотя бы coverage, а забитое ревью от выполненного без претензий к коду не отличить никак. >> Вот тут уже сомнения. Если сжатые сроки, то потеря в среднем получаса >> на каждое ревью... Это какие же должны быть разработчики, чтобы оно >> окупалось? >> > Запаренные. Я не видел, чтоб окупалось. Ревьюеры-то при этом - те же разработчики, и точно так же запаренные. Да еще надо ревью делать, что еще больше запаривает... В вышепоскипанном примере с байкой про Боинг как раз запаренности-то и нет. Там регламент устроен так, чтобы затормозить именно запарку. >> >> Менталитет программиста тоже интернационален. С менталитетом "кодера по >> >> обезьяньей работе" хуже, но extreme programming - технология для >> >> программистов. >> >> >> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет >> > несколько сложно, и не для всех эта техника подходит. >> >> А никто не утверждал, что для всех. А вот русский с китайцем, скорее >> всего, в паре как раз неплохо уживутся. Только роли будут не >> переменные, а ближе к постоянным. Китаец кодит, русский следит и >> корректирует. Характерного китайца не надо подгонять, зато надо >> своевременно тормозить и/или поворачивать. Тогда он будет выдавать >> качественный продукт, а быстро он его и так будет выдавать. >> > Что-то динамика развития Китая по отношению к РФ показывает: роли > меняются. :-/ Ой, да ладно... Может, лет через несколько русский тут просто станет лишним, но заменить китайца как работник... >> >> >> > В любом случае, если я такое (чисто теоретически) предложу >> менеджеру, >> >> >> > он только у виска покрутит. Это же получается, что каждый >> программист >> >> >> > работает, условно половину времени, а половину сидит "и что-то >> там >> >> >> > смотрит". >> >> >> >> >> А если тебе не результат а имитацию бурной деятельности для >> менеджера, >> >> >> то да, подход ровно обратный. >> >> > В конкретном случае мне нужно сделать для себя: имитировать там не >> для кого. >> >> > Над своими проектами я не за деньги работаю. >> >> > И те, кто со мной работает, понимают, что если ты не сделаешь, >> ничего не >> >> > будет сделано. >> >> >> >> А если для себя, то предлагать вы будете не менеджеру, а себе. >> >> Совершенно другая задача. >> >> >> > У меня так-то оба варианта сейчас есть. >> >> Ну и рассматривать их надо как две разных задачи, а не как одну общую. >> И решать по-разному. >> > Согласен. > Пока остановлюсь на том, что для себя. > В любом случае, в механизмах большой компании "снизу" особо ничего не > изменишь. Кстати, тоже есть варианты. Если помнить, что у нас нет цели поменять компанию, нам достаточно поменять условия лично своей работы. Но это совсем уже оффтопик. >> >> >> И кстати, code review более чем подходит под определение "что-то там >> >> >> смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во >> время >> >> >> code review? >> >> >> >> >> > А у нас на ревью время специально выделяется (похоже, что были >> >> > менеджеры, которые не понимали, что это "за ревью такое", и в правила >> >> > записали официально). >> >> > На парное программирование же времени не выделяют. >> >> > Код пишут не вместе, хотя иногда вместе раздирают. >> >> >> >> А у нас выделяют время на работу, а не процедуры определенного >> >> вида. Надо поработать в паре - попросил коллегу, сели, поработали в >> >> паре. Надо попросить коллегу посмотреть код - попросил коллегу >> >> посмотреть код. И т.д. >> >> >> > Так тоже возможно, но постоянную "работу в паре" не одобрят точно. >> >> "Тут ведь как"... С одной стороны, она переменная. XP настаивает на >> постоянной, но в нашей практике она в основном используется в случаях, >> где одна голова хорошо, а две лучше. С другой, "вам шашечки или ехать?" >> В смысле, результат или квартальный отчет? > Видимо, мне стоит задуматься над этим вопросом? Более прямым текстом мы договорились выше. Две разных задачи, два разных решения. >> Если нужен результат, и >> работа в паре его дает, то с хрена ли ее не одобрять? Вы полагаете, что >> поодиночке будет лучше? Ну, давайте сравним на интервале в пару лет, >> чтобы в статистику затрат еще и саппорт попал. А вот про саппорт в статистике затрат как раз задуматься стоит. О нем очень часто забывают и когда делают для себя, любимого.
