Re: Системы управления сервером?
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 настаивает на
>> постоянной, но в нашей практике она в основном используется в случаях,
>> где одна голова хорошо, а две лучше. С другой, "вам шашечки или ехать?"
>> В смысле, результат или квартальный отчет?
> Видимо, мне стоит задуматься над этим вопросом?
Более прямым текстом мы договорились выше. Две разных задачи, два
разных решения.
>> Если нужен результат, и
>> работа в паре его дает, то с хрена ли ее не одобрять? Вы полагаете, что
>> поодиночке будет лучше? Ну, давайте сравним на интервале в пару лет,
>> чтобы в статистику затрат еще и саппорт попал.
А вот про саппорт в статистике затрат как раз задуматься стоит. О нем
очень часто забывают и когда делают для себя, любимого.
Reply to: