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

[artiom <artiom14@yandex.ru>]

>  > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
>  > репозитория, на которую уже понакоммитили и заложили функционал.
> 
> Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую
> очень не сразу удалось обнаружить, не брали никакие разумные тесты, и
> трудоемко было потом починить. Так и не починили, кстати. Причем по
> крайней мере два первых ревью (два разных человека, входивших в разное
> время в проект, внимательно читали этот код) она тоже успешно
> проскочила.
> 
Ну да, бывает.

> Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как
> раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки
> находится тысяча первый ревьюер, который таки замечает багу и делает
> эксплойт.
> 
Может быть из-за ревью он находится через 10-15 лет, а не каждый год на
их протяжении?

> А обычно бага либо легко правится, либо быстро замечается. В идеале и
> то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
> реализации фичи, но так бывает не всегда :)
> 
Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о
чём как-то давно вы сами и писали.

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

> И не факт, кстати, что старые баги известны. Мы можем говорить о ревью,
> например, фикса свеженаступленной грабли. Она, может, в коде и пару лет
> уже, но важный заказчик наступил на нее только сегодня, а до него просто
> никому не приходило в голову проделать именно эту последовательность
> действий.
> 
Главное, чтобы фикс не внёс два других ещё более неочевидных бага и
ничего не сломал.

>  > А тут новые баги, которые успеют сломать тестирование, например, в
>  > результате чего могут не пройти другие тесты и т.п..
>  > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
>  > однако есть факты на практике).
> 
> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
> если тест сломался, то багу надо чинить. Если бага сломала сразу много
> тестов, починка приоритетна, и все дела.
> 
Ладно, умолчу про тех, кто "чинит" тесты в таком случае.
Такие тоже бывали.
Но очень редко тестовое покрытие полное.

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

>  > А отрыв на 15 минут - не критично: вы же не соревновательным
>  > программированием занимаетесь, надеюсь?
> 
> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст.
> 
Есть вечер, утро и обед, если не критично.
Обычно срочно закрывать не приходится.
Вполне себе нормальный способ оторваться от задачи.

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

>  > Другое дело, если ревью много. Тогда да, на них забивают.
> 
> И это, кстати, тоже. Не написанный тест ловится хотя бы coverage, а
> забитое ревью от выполненного без претензий к коду не отличить никак.
> 
Да, тут правда.

>  >> Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
>  >> на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
>  >> окупалось?
>  >> 
>  > Запаренные.
> 
> Я не видел, чтоб окупалось.  Ревьюеры-то при этом - те же разработчики, и
> точно так же запаренные.  Да еще надо ревью делать, что еще больше
> запаривает...
> 
> В вышепоскипанном примере с байкой про Боинг как раз запаренности-то и
> нет.  Там регламент устроен так, чтобы затормозить именно запарку.
> 
Ну хорошо Боингу, а когда "давай сократим срок до месяца, хотя можно
делать шесть", а в реальности не помешало бы два, постоянно "атмосфера
гонки" и ощущение того, что ничего не успеваешь.

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

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