[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Системы управления сервером?



>  >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
>  >>  >>  >> либо обучается, либо идет искать работу в другом месте.
>  >>  >>  >> 
>  >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
>  >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
>  >>  >> 
>  >>  >> В одной из контор у нас были любители почитать код, уходящий в
>  >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
>  >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
>  >>  >> 
>  >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
>  >>  > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
>  >> 
>  >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
>  >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
>  >> происходит.
>  >> 
>  > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
>  > практики.
> 
> Собственно, системы управления версиями придуманы ровно для этой
> ситуации.  Чтобы заменить трехслойную бюрократию ревью, которая работает
> месяц, но тоже пропускает баги, возможностью найти и откатить изменение,
> если оно оказалось неудачным.
> 
> А чтобы неудачное изменение не долетело до заказчика, существует
> релизный цикл.  И ревью его необходимости не отменяет.
> 
Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
репозитория, на которую уже понакоммитили и заложили функционал.

>  >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - не
>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
>  >>  >> 
>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
>  >>  > ли - не допустить?
>  >>  > Какая практика?
>  >>  > В чём нехорошесть данной идеи?
>  >> 
>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
>  >> будет изменен, проходит время.
>  > Как минус, так и плюс.
> 
> В течение этого времени в системе присутствуют и старые, и новые баги.
> Где плюс?
> 
Нет, присутствуют только старые баги, которые уже известны, проверены и
одеты в пиджак, так что стали напоминать фичи.
А тут новые баги, которые успеют сломать тестирование, например, в
результате чего могут не пройти другие тесты и т.п..
На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
однако есть факты на практике).


>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
>  > ждать ответов автора (который в этом время уже над другим работает), к
>  > тому же, ревьюверов бывает несколько.
> 
> Я про прерывания не процесса ревью, а про прерывания процесса своей
> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
> той задачи, к которой относится просматриваемый код.  Он там неизбежно
> заменит контекст своей задачи.  После ревью придется снова грузить свой.
> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
> часа каждая перегрузка, а их тут две.
Ну час - это явный перебор. А отрыв на 15 минут - не критично: вы же не
соревновательным программированием занимаетесь, надеюсь?
Иногда вообще полезно от задачи оторваться, бывает.
Другое дело, если ревью много. Тогда да, на них забивают.

> 
>  >>  >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
>  >>  >> там такова, что оно окупается.
>  >>  >> 
>  >>  > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
>  >>  > привязана задача, после чего проверяются (перед репозиторием).
>  >> 
>  >> А "в случае того, что есть сейчас" непонятно, окупается ли этот
>  >> тормозной путь.
>  >> 
>  > Продукт окупается.
>  > "Тормозной путь", скорее всего, да.
>  > Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.
> 
> Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
> на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
> окупалось?
> 
Запаренные.

>  >> Менталитет программиста тоже интернационален. С менталитетом "кодера по
>  >> обезьяньей работе" хуже, но extreme programming - технология для
>  >> программистов.
>  >> 
>  > Ну что-то мне подсказывает, что русским и китайцам ужиться будет
>  > несколько сложно, и не для всех эта техника подходит.
> 
> А никто не утверждал, что для всех.  А вот русский с китайцем, скорее
> всего, в паре как раз неплохо уживутся.  Только роли будут не
> переменные, а ближе к постоянным.  Китаец кодит, русский следит и
> корректирует.  Характерного китайца не надо подгонять, зато надо
> своевременно тормозить и/или поворачивать.  Тогда он будет выдавать
> качественный продукт, а быстро он его и так будет выдавать.
> 
Что-то динамика развития Китая по отношению к РФ показывает: роли
меняются. :-/

>  >>  >>  > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
>  >>  >>  > он только у виска покрутит. Это же получается, что каждый программист
>  >>  >>  > работает, условно половину времени, а половину сидит "и что-то там
>  >>  >>  > смотрит".
>  >> 
>  >>  >> А если тебе не результат а имитацию бурной деятельности для менеджера,
>  >>  >> то да, подход ровно обратный.
>  >>  > В конкретном случае мне нужно сделать для себя: имитировать там не для кого.
>  >>  > Над своими проектами я не за деньги работаю.
>  >>  > И те, кто со мной работает, понимают, что если ты не сделаешь, ничего не
>  >>  > будет сделано.
>  >> 
>  >> А если для себя, то предлагать вы будете не менеджеру, а себе.
>  >> Совершенно другая задача.
>  >> 
>  > У меня так-то оба варианта сейчас есть.
> 
> Ну и рассматривать их надо как две разных задачи, а не как одну общую.
> И решать по-разному.
> 
Согласен.
Пока остановлюсь на том, что для себя.
В любом случае, в механизмах большой компании "снизу" особо ничего не
изменишь.

>  >>  >> И кстати, code review более чем подходит под определение "что-то там
>  >>  >> смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время
>  >>  >> code review?
>  >>  >> 
>  >>  > А у нас на ревью время специально выделяется (похоже, что были
>  >>  > менеджеры, которые не понимали, что это "за ревью такое", и в правила
>  >>  > записали официально).
>  >>  > На парное программирование же времени не выделяют.
>  >>  > Код пишут не вместе, хотя иногда вместе раздирают.
>  >> 
>  >> А у нас выделяют время на работу, а не процедуры определенного
>  >> вида. Надо поработать в паре - попросил коллегу, сели, поработали в
>  >> паре. Надо попросить коллегу посмотреть код - попросил коллегу
>  >> посмотреть код. И т.д.
>  >> 
>  > Так тоже возможно, но постоянную "работу в паре" не одобрят точно.
> 
> "Тут ведь как"...  С одной стороны, она переменная.  XP настаивает на
> постоянной, но в нашей практике она в основном используется в случаях,
> где одна голова хорошо, а две лучше.  С другой, "вам шашечки или ехать?"
> В смысле, результат или квартальный отчет? 
Видимо, мне стоит задуматься над этим вопросом?

> Если нужен результат, и
> работа в паре его дает, то с хрена ли ее не одобрять?  Вы полагаете, что
> поодиночке будет лучше?  Ну, давайте сравним на интервале в пару лет,
> чтобы в статистику затрат еще и саппорт попал.
> 


Reply to: