Re: Системы управления сервером?
- To: debian-russian@lists.debian.org
- Subject: Re: Системы управления сервером?
- From: artiom <artiom14@yandex.ru>
- Date: Sun, 8 Apr 2018 11:55:37 +0300
- Message-id: <[🔎] 4baa04f1-453b-152b-817c-1c7f3e72cfeb@yandex.ru>
- In-reply-to: <87a7uorr10.fsf@silver.lasgalen.net>
- 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>
> > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
> > репозитория, на которую уже понакоммитили и заложили функционал.
>
> Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую
> очень не сразу удалось обнаружить, не брали никакие разумные тесты, и
> трудоемко было потом починить. Так и не починили, кстати. Причем по
> крайней мере два первых ревью (два разных человека, входивших в разное
> время в проект, внимательно читали этот код) она тоже успешно
> проскочила.
>
Ну да, бывает.
> Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как
> раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки
> находится тысяча первый ревьюер, который таки замечает багу и делает
> эксплойт.
>
Может быть из-за ревью он находится через 10-15 лет, а не каждый год на
их протяжении?
> А обычно бага либо легко правится, либо быстро замечается. В идеале и
> то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
> реализации фичи, но так бывает не всегда :)
>
Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о
чём как-то давно вы сами и писали.
> >> >> >> Практика показывает, что читать код _до_ попадания в репозиторий - не
> >> >> >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
> >> >> >>
> >> >> > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
> >> >> > ли - не допустить?
> >> >> > Какая практика?
> >> >> > В чём нехорошесть данной идеи?
> >> >>
> >> >> Тормозной путь. Между моментом изменения кода и моментом, когда код
> >> >> будет изменен, проходит время.
> >> > Как минус, так и плюс.
> >>
> >> В течение этого времени в системе присутствуют и старые, и новые баги.
> >> Где плюс?
> >>
> > Нет, присутствуют только старые баги, которые уже известны, проверены и
> > одеты в пиджак, так что стали напоминать фичи.
>
> В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И
> поверх них уже идет работа.
>
Да не идёт поверх них работы, пока их нет в репозитории, иначе процесс
неверно построен.
> И не факт, кстати, что старые баги известны. Мы можем говорить о ревью,
> например, фикса свеженаступленной грабли. Она, может, в коде и пару лет
> уже, но важный заказчик наступил на нее только сегодня, а до него просто
> никому не приходило в голову проделать именно эту последовательность
> действий.
>
Главное, чтобы фикс не внёс два других ещё более неочевидных бага и
ничего не сломал.
> > А тут новые баги, которые успеют сломать тестирование, например, в
> > результате чего могут не пройти другие тесты и т.п..
> > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
> > однако есть факты на практике).
>
> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
> если тест сломался, то багу надо чинить. Если бага сломала сразу много
> тестов, починка приоритетна, и все дела.
>
Ладно, умолчу про тех, кто "чинит" тесты в таком случае.
Такие тоже бывали.
Но очень редко тестовое покрытие полное.
> >> > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
> >> > ждать ответов автора (который в этом время уже над другим работает), к
> >> > тому же, ревьюверов бывает несколько.
> >>
> >> Я про прерывания не процесса ревью, а про прерывания процесса своей
> >> работы необходимостью ревью. Для ревью надо загрузить в голову контекст
> >> той задачи, к которой относится просматриваемый код. Он там неизбежно
> >> заменит контекст своей задачи. После ревью придется снова грузить свой.
> >> Это время, и в случае сложной задачи весьма изрядное. От 15 минут до
> >> часа каждая перегрузка, а их тут две.
> > Ну час - это явный перебор.
>
> Это значит, у тебя все задачи простые.
>
Не сказал бы. Ревью компактные относительно. И, естественно, что я не
вникаю в весь код: только в изменения.
А задача делается не один день. Я её помню и хотя бы иногда надо
отвлекаться.
> > А отрыв на 15 минут - не критично: вы же не соревновательным
> > программированием занимаетесь, надеюсь?
>
> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст.
>
Есть вечер, утро и обед, если не критично.
Обычно срочно закрывать не приходится.
Вполне себе нормальный способ оторваться от задачи.
> > Иногда вообще полезно от задачи оторваться, бывает.
>
> В моем опыте оторваться от задачи полезно, а вот заменять в голове ее
> контекст контекстом другой задачи как раз вредно. Ну да люди разные,
> задачи тоже.
>
Ну это возможно. Просто обычно на ревью "отдыхаешь". Хотя...
> > Другое дело, если ревью много. Тогда да, на них забивают.
>
> И это, кстати, тоже. Не написанный тест ловится хотя бы coverage, а
> забитое ревью от выполненного без претензий к коду не отличить никак.
>
Да, тут правда.
> >> Вот тут уже сомнения. Если сжатые сроки, то потеря в среднем получаса
> >> на каждое ревью... Это какие же должны быть разработчики, чтобы оно
> >> окупалось?
> >>
> > Запаренные.
>
> Я не видел, чтоб окупалось. Ревьюеры-то при этом - те же разработчики, и
> точно так же запаренные. Да еще надо ревью делать, что еще больше
> запаривает...
>
> В вышепоскипанном примере с байкой про Боинг как раз запаренности-то и
> нет. Там регламент устроен так, чтобы затормозить именно запарку.
>
Ну хорошо Боингу, а когда "давай сократим срок до месяца, хотя можно
делать шесть", а в реальности не помешало бы два, постоянно "атмосфера
гонки" и ощущение того, что ничего не успеваешь.
> >> >> Менталитет программиста тоже интернационален. С менталитетом "кодера по
> >> >> обезьяньей работе" хуже, но extreme programming - технология для
> >> >> программистов.
> >> >>
> >> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет
> >> > несколько сложно, и не для всех эта техника подходит.
> >>
> >> А никто не утверждал, что для всех. А вот русский с китайцем, скорее
> >> всего, в паре как раз неплохо уживутся. Только роли будут не
> >> переменные, а ближе к постоянным. Китаец кодит, русский следит и
> >> корректирует. Характерного китайца не надо подгонять, зато надо
> >> своевременно тормозить и/или поворачивать. Тогда он будет выдавать
> >> качественный продукт, а быстро он его и так будет выдавать.
> >>
> > Что-то динамика развития Китая по отношению к РФ показывает: роли
> > меняются. :-/
>
> Ой, да ладно... Может, лет через несколько русский тут просто станет
> лишним, но заменить китайца как работник...
>
Я как-то уже писал: китайцы свою процессорную архитектуру отгрохали,
реализовали на ней процессоры и построили из них самый быстрый в мире
суперкомпьютер, обогнав США (сейчас, вроде Япония первая).
Где здесь русский?
РФ в этом плане, пусть и не в полной жопе (есть те же Эльбрусы), но даже
близко подойти не может.
> >> >> >> > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
> >> >> >> > он только у виска покрутит. Это же получается, что каждый программист
> >> >> >> > работает, условно половину времени, а половину сидит "и что-то там
> >> >> >> > смотрит".
> >> >>
> >> >> >> А если тебе не результат а имитацию бурной деятельности для менеджера,
> >> >> >> то да, подход ровно обратный.
> >> >> > В конкретном случае мне нужно сделать для себя: имитировать там не для кого.
> >> >> > Над своими проектами я не за деньги работаю.
> >> >> > И те, кто со мной работает, понимают, что если ты не сделаешь, ничего не
> >> >> > будет сделано.
> >> >>
> >> >> А если для себя, то предлагать вы будете не менеджеру, а себе.
> >> >> Совершенно другая задача.
> >> >>
> >> > У меня так-то оба варианта сейчас есть.
> >>
> >> Ну и рассматривать их надо как две разных задачи, а не как одну общую.
> >> И решать по-разному.
> >>
> > Согласен.
> > Пока остановлюсь на том, что для себя.
> > В любом случае, в механизмах большой компании "снизу" особо ничего не
> > изменишь.
>
> Кстати, тоже есть варианты. Если помнить, что у нас нет цели поменять
> компанию, нам достаточно поменять условия лично своей работы. Но это
> совсем уже оффтопик.
>
Ну я бы не сказал, что нет такой цели, об этом и задумываюсь (или
поменять отдел).
Без одного другое не сделать.
Reply to: