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

[Artem Chuprina <ran@lasgalen.net>]

artiom -> debian-russian@lists.debian.org  @ Sun, 8 Apr 2018 11:55:37 +0300:

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

И это тоже, но это ревью, опять же, в духе байки про Боинг, и задолго до
начала реализации.

А баги в реализации обычно ловят тесты.

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

Если считать только время реализации, отдельно от размышлений об
архитектуре, то больше 50%. На глазок, примерно 70. Оно, правда, часто
окупается.

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

То есть в верно построенном процессе эти два дня никто ничего не делает
ни в чем, завязанном на это место кода? Верно построен процесс, что и
говорить...

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

А это по коду фикса очень трудно понять. Нужен контекст гораздо большего
объема. Тут как раз набор автоматизированных тестов работает не в пример
лучше - в нем этот контекст зафиксирован.

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

Практически никогда. Но требуется не полнота, а хорошая вероятность
вылавливания баги раньше, чем на нее наступит заказчик.

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

То есть как раз неочевидные грабли, которые вносит изменение, ты
пропустишь с вероятностью, близкой к 1.

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

В обед надо обедать. И мозгом тоже. Иначе очень быстро огребешь гастрит.

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

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

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

На "давай сократим срок до месяца" я отвечаю "давай тогда делать работу
будет тот, кто сделает ее за месяц".  Способствует просветлению.

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

А я этого в оригинале не видел, и не знаю, насколько тыренная (вряд ли
из России, скорее всего, из Штатов) та архитектура.  А типичный китаец,
по опыту, хорошо работает, только будучи поставлен на рельсы.  Рельсы же
кто-то другой должен проложить.

 > РФ в этом плане, пусть и не в полной жопе (есть те же Эльбрусы), но даже
 > близко подойти не может.

В этом плане РФ как раз в полной жопе.  Но это другие задачи, и там
другая ситуация.

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

Поменять компанию может быть только средством.  Целью - только если
сдуру.  Даже если это твоя компания (в смысле, если ты ее владелец).