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