Re: Системы управления сервером?
> >> >> >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
> >> >> >> либо обучается, либо идет искать работу в другом месте.
> >> >> >>
> >> >> > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
> >> >> > сложный, хотелось бы видеть, что уйдёт в репозиторий.
> >> >>
> >> >> В одной из контор у нас были любители почитать код, уходящий в
> >> >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
> >> >> желающим. По почте. Тем же способом присматривали за джуниорами.
> >> >>
> >> > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
> >> > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
> >>
> >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
> >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
> >> происходит.
> >>
> > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
> > практики.
>
> Собственно, системы управления версиями придуманы ровно для этой
> ситуации. Чтобы заменить трехслойную бюрократию ревью, которая работает
> месяц, но тоже пропускает баги, возможностью найти и откатить изменение,
> если оно оказалось неудачным.
>
> А чтобы неудачное изменение не долетело до заказчика, существует
> релизный цикл. И ревью его необходимости не отменяет.
>
Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
репозитория, на которую уже понакоммитили и заложили функционал.
> >> >> Практика показывает, что читать код _до_ попадания в репозиторий - не
> >> >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
> >> >>
> >> > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
> >> > ли - не допустить?
> >> > Какая практика?
> >> > В чём нехорошесть данной идеи?
> >>
> >> Тормозной путь. Между моментом изменения кода и моментом, когда код
> >> будет изменен, проходит время.
> > Как минус, так и плюс.
>
> В течение этого времени в системе присутствуют и старые, и новые баги.
> Где плюс?
>
Нет, присутствуют только старые баги, которые уже известны, проверены и
одеты в пиджак, так что стали напоминать фичи.
А тут новые баги, которые успеют сломать тестирование, например, в
результате чего могут не пройти другие тесты и т.п..
На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
однако есть факты на практике).
> > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
> > ждать ответов автора (который в этом время уже над другим работает), к
> > тому же, ревьюверов бывает несколько.
>
> Я про прерывания не процесса ревью, а про прерывания процесса своей
> работы необходимостью ревью. Для ревью надо загрузить в голову контекст
> той задачи, к которой относится просматриваемый код. Он там неизбежно
> заменит контекст своей задачи. После ревью придется снова грузить свой.
> Это время, и в случае сложной задачи весьма изрядное. От 15 минут до
> часа каждая перегрузка, а их тут две.
Ну час - это явный перебор. А отрыв на 15 минут - не критично: вы же не
соревновательным программированием занимаетесь, надеюсь?
Иногда вообще полезно от задачи оторваться, бывает.
Другое дело, если ревью много. Тогда да, на них забивают.
>
> >> >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
> >> >> там такова, что оно окупается.
> >> >>
> >> > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
> >> > привязана задача, после чего проверяются (перед репозиторием).
> >>
> >> А "в случае того, что есть сейчас" непонятно, окупается ли этот
> >> тормозной путь.
> >>
> > Продукт окупается.
> > "Тормозной путь", скорее всего, да.
> > Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.
>
> Вот тут уже сомнения. Если сжатые сроки, то потеря в среднем получаса
> на каждое ревью... Это какие же должны быть разработчики, чтобы оно
> окупалось?
>
Запаренные.
> >> Менталитет программиста тоже интернационален. С менталитетом "кодера по
> >> обезьяньей работе" хуже, но extreme programming - технология для
> >> программистов.
> >>
> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет
> > несколько сложно, и не для всех эта техника подходит.
>
> А никто не утверждал, что для всех. А вот русский с китайцем, скорее
> всего, в паре как раз неплохо уживутся. Только роли будут не
> переменные, а ближе к постоянным. Китаец кодит, русский следит и
> корректирует. Характерного китайца не надо подгонять, зато надо
> своевременно тормозить и/или поворачивать. Тогда он будет выдавать
> качественный продукт, а быстро он его и так будет выдавать.
>
Что-то динамика развития Китая по отношению к РФ показывает: роли
меняются. :-/
> >> >> > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
> >> >> > он только у виска покрутит. Это же получается, что каждый программист
> >> >> > работает, условно половину времени, а половину сидит "и что-то там
> >> >> > смотрит".
> >>
> >> >> А если тебе не результат а имитацию бурной деятельности для менеджера,
> >> >> то да, подход ровно обратный.
> >> > В конкретном случае мне нужно сделать для себя: имитировать там не для кого.
> >> > Над своими проектами я не за деньги работаю.
> >> > И те, кто со мной работает, понимают, что если ты не сделаешь, ничего не
> >> > будет сделано.
> >>
> >> А если для себя, то предлагать вы будете не менеджеру, а себе.
> >> Совершенно другая задача.
> >>
> > У меня так-то оба варианта сейчас есть.
>
> Ну и рассматривать их надо как две разных задачи, а не как одну общую.
> И решать по-разному.
>
Согласен.
Пока остановлюсь на том, что для себя.
В любом случае, в механизмах большой компании "снизу" особо ничего не
изменишь.
> >> >> И кстати, code review более чем подходит под определение "что-то там
> >> >> смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время
> >> >> code review?
> >> >>
> >> > А у нас на ревью время специально выделяется (похоже, что были
> >> > менеджеры, которые не понимали, что это "за ревью такое", и в правила
> >> > записали официально).
> >> > На парное программирование же времени не выделяют.
> >> > Код пишут не вместе, хотя иногда вместе раздирают.
> >>
> >> А у нас выделяют время на работу, а не процедуры определенного
> >> вида. Надо поработать в паре - попросил коллегу, сели, поработали в
> >> паре. Надо попросить коллегу посмотреть код - попросил коллегу
> >> посмотреть код. И т.д.
> >>
> > Так тоже возможно, но постоянную "работу в паре" не одобрят точно.
>
> "Тут ведь как"... С одной стороны, она переменная. XP настаивает на
> постоянной, но в нашей практике она в основном используется в случаях,
> где одна голова хорошо, а две лучше. С другой, "вам шашечки или ехать?"
> В смысле, результат или квартальный отчет?
Видимо, мне стоит задуматься над этим вопросом?
> Если нужен результат, и
> работа в паре его дает, то с хрена ли ее не одобрять? Вы полагаете, что
> поодиночке будет лучше? Ну, давайте сравним на интервале в пару лет,
> чтобы в статистику затрат еще и саппорт попал.
>
Reply to: