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 - технология для >> >> >> программистов. >> >> >> >> >> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет >> >> > несколько сложно, и не для всех эта техника подходит. >> >> >> >> А никто не утверждал, что для всех. А вот русский с китайцем, скорее >> >> всего, в паре как раз неплохо уживутся. Только роли будут не >> >> переменные, а ближе к постоянным. Китаец кодит, русский следит и >> >> корректирует. Характерного китайца не надо подгонять, зато надо >> >> своевременно тормозить и/или поворачивать. Тогда он будет выдавать >> >> качественный продукт, а быстро он его и так будет выдавать. >> >> >> > Что-то динамика развития Китая по отношению к РФ показывает: роли >> > меняются. :-/ >> >> Ой, да ладно... Может, лет через несколько русский тут просто станет >> лишним, но заменить китайца как работник... >> > Я как-то уже писал: китайцы свою процессорную архитектуру отгрохали, > реализовали на ней процессоры и построили из них самый быстрый в мире > суперкомпьютер, обогнав США (сейчас, вроде Япония первая). > Где здесь русский? А я этого в оригинале не видел, и не знаю, насколько тыренная (вряд ли из России, скорее всего, из Штатов) та архитектура. А типичный китаец, по опыту, хорошо работает, только будучи поставлен на рельсы. Рельсы же кто-то другой должен проложить. > РФ в этом плане, пусть и не в полной жопе (есть те же Эльбрусы), но даже > близко подойти не может. В этом плане РФ как раз в полной жопе. Но это другие задачи, и там другая ситуация. >> > В любом случае, в механизмах большой компании "снизу" особо ничего не >> > изменишь. >> >> Кстати, тоже есть варианты. Если помнить, что у нас нет цели поменять >> компанию, нам достаточно поменять условия лично своей работы. Но это >> совсем уже оффтопик. >> > Ну я бы не сказал, что нет такой цели, об этом и задумываюсь (или > поменять отдел). > Без одного другое не сделать. Поменять компанию может быть только средством. Целью - только если сдуру. Даже если это твоя компания (в смысле, если ты ее владелец).
