Re: Системы управления сервером?
- To: debian-russian@lists.debian.org
- Subject: Re: Системы управления сервером?
- From: Artem Chuprina <ran@lasgalen.net>
- Date: Sun, 08 Apr 2018 12:41:27 +0300
- Message-id: <[🔎] 87o9iuox14.fsf@silver.lasgalen.net>
- Mail-followup-to: debian-russian@lists.debian.org
- In-reply-to: <[🔎] 4baa04f1-453b-152b-817c-1c7f3e72cfeb@yandex.ru> (artiom's message of "Sun, 8 Apr 2018 11:55:37 +0300")
- References: <77b7e7b2-60dd-2654-30e9-26a1618325be@yandex.ru> <20180320162358.6f4b531e@brick.gerasiov.net> <a4b774d2-d04d-28a0-5939-2787c8ff3842@yandex.ru> <20180322161000.2f2b1ab7@brick.gerasiov.net> <d85ceee7-7bb0-99cc-a2de-772a05ecd2b9@yandex.ru> <20180323112606.1bef1ab4@brick.gerasiov.net> <cdb58703-30a6-97be-5012-7db30bd0dade@yandex.ru> <87lgeivtfw.fsf@silver.lasgalen.net> <705fb011-fb55-1523-36fb-8fcba8b9a95d@yandex.ru> <87h8p5x3ll.fsf@silver.lasgalen.net> <50e4749e-6a2b-f863-422c-9d03dd68c7ea@yandex.ru> <87woy1v02c.fsf@silver.lasgalen.net> <b2209827-b9c0-6c95-9910-c20e46366ced@yandex.ru> <87605iugmj.fsf@silver.lasgalen.net> <b217141e-2f54-21be-9d9e-a8ffd0310585@yandex.ru> <87woxwtvkj.fsf@silver.lasgalen.net> <aa1714a7-7cb9-0fc0-f418-aa00bb9f8160@yandex.ru> <87a7uorr10.fsf@silver.lasgalen.net> <[🔎] 4baa04f1-453b-152b-817c-1c7f3e72cfeb@yandex.ru>
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 - технология для
>> >> >> программистов.
>> >> >>
>> >> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет
>> >> > несколько сложно, и не для всех эта техника подходит.
>> >>
>> >> А никто не утверждал, что для всех. А вот русский с китайцем, скорее
>> >> всего, в паре как раз неплохо уживутся. Только роли будут не
>> >> переменные, а ближе к постоянным. Китаец кодит, русский следит и
>> >> корректирует. Характерного китайца не надо подгонять, зато надо
>> >> своевременно тормозить и/или поворачивать. Тогда он будет выдавать
>> >> качественный продукт, а быстро он его и так будет выдавать.
>> >>
>> > Что-то динамика развития Китая по отношению к РФ показывает: роли
>> > меняются. :-/
>>
>> Ой, да ладно... Может, лет через несколько русский тут просто станет
>> лишним, но заменить китайца как работник...
>>
> Я как-то уже писал: китайцы свою процессорную архитектуру отгрохали,
> реализовали на ней процессоры и построили из них самый быстрый в мире
> суперкомпьютер, обогнав США (сейчас, вроде Япония первая).
> Где здесь русский?
А я этого в оригинале не видел, и не знаю, насколько тыренная (вряд ли
из России, скорее всего, из Штатов) та архитектура. А типичный китаец,
по опыту, хорошо работает, только будучи поставлен на рельсы. Рельсы же
кто-то другой должен проложить.
> РФ в этом плане, пусть и не в полной жопе (есть те же Эльбрусы), но даже
> близко подойти не может.
В этом плане РФ как раз в полной жопе. Но это другие задачи, и там
другая ситуация.
>> > В любом случае, в механизмах большой компании "снизу" особо ничего не
>> > изменишь.
>>
>> Кстати, тоже есть варианты. Если помнить, что у нас нет цели поменять
>> компанию, нам достаточно поменять условия лично своей работы. Но это
>> совсем уже оффтопик.
>>
> Ну я бы не сказал, что нет такой цели, об этом и задумываюсь (или
> поменять отдел).
> Без одного другое не сделать.
Поменять компанию может быть только средством. Целью - только если
сдуру. Даже если это твоя компания (в смысле, если ты ее владелец).
Reply to: