> > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из > > репозитория, на которую уже понакоммитили и заложили функционал. > > Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую > очень не сразу удалось обнаружить, не брали никакие разумные тесты, и > трудоемко было потом починить. Так и не починили, кстати. Причем по > крайней мере два первых ревью (два разных человека, входивших в разное > время в проект, внимательно читали этот код) она тоже успешно > проскочила. > Ну да, бывает.
> Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как > раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки > находится тысяча первый ревьюер, который таки замечает багу и делает > эксплойт. > Может быть из-за ревью он находится через 10-15 лет, а не каждый год на их протяжении? > А обычно бага либо легко правится, либо быстро замечается. В идеале и > то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе > реализации фичи, но так бывает не всегда :) > Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о чём как-то давно вы сами и писали. > >> >> >> Практика показывает, что читать код _до_ попадания в репозиторий > - не > >> >> >> очень хорошая идея. Благо репозиторий позволяет, если что, > откатить. > >> >> >> > >> >> > Но сборки уже будут собраны и отправлены на тестирование, так не > лучше > >> >> > ли - не допустить? > >> >> > Какая практика? > >> >> > В чём нехорошесть данной идеи? > >> >> > >> >> Тормозной путь. Между моментом изменения кода и моментом, когда код > >> >> будет изменен, проходит время. > >> > Как минус, так и плюс. > >> > >> В течение этого времени в системе присутствуют и старые, и новые баги. > >> Где плюс? > >> > > Нет, присутствуют только старые баги, которые уже известны, проверены и > > одеты в пиджак, так что стали напоминать фичи. > > В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И > поверх них уже идет работа. > Да не идёт поверх них работы, пока их нет в репозитории, иначе процесс неверно построен. > И не факт, кстати, что старые баги известны. Мы можем говорить о ревью, > например, фикса свеженаступленной грабли. Она, может, в коде и пару лет > уже, но важный заказчик наступил на нее только сегодня, а до него просто > никому не приходило в голову проделать именно эту последовательность > действий. > Главное, чтобы фикс не внёс два других ещё более неочевидных бага и ничего не сломал. > > А тут новые баги, которые успеют сломать тестирование, например, в > > результате чего могут не пройти другие тесты и т.п.. > > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты, > > однако есть факты на практике). > > На практике тесты для того и существуют, чтобы баги их ломали. Один фиг, > если тест сломался, то багу надо чинить. Если бага сломала сразу много > тестов, починка приоритетна, и все дела. > Ладно, умолчу про тех, кто "чинит" тесты в таком случае. Такие тоже бывали. Но очень редко тестовое покрытие полное. > >> > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и > >> > ждать ответов автора (который в этом время уже над другим работает), к > >> > тому же, ревьюверов бывает несколько. > >> > >> Я про прерывания не процесса ревью, а про прерывания процесса своей > >> работы необходимостью ревью. Для ревью надо загрузить в голову контекст > >> той задачи, к которой относится просматриваемый код. Он там неизбежно > >> заменит контекст своей задачи. После ревью придется снова грузить свой. > >> Это время, и в случае сложной задачи весьма изрядное. От 15 минут до > >> часа каждая перегрузка, а их тут две. > > Ну час - это явный перебор. > > Это значит, у тебя все задачи простые. > Не сказал бы. Ревью компактные относительно. И, естественно, что я не вникаю в весь код: только в изменения. А задача делается не один день. Я её помню и хотя бы иногда надо отвлекаться. > > А отрыв на 15 минут - не критично: вы же не соревновательным > > программированием занимаетесь, надеюсь? > > Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст. > Есть вечер, утро и обед, если не критично. Обычно срочно закрывать не приходится. Вполне себе нормальный способ оторваться от задачи. > > Иногда вообще полезно от задачи оторваться, бывает. > > В моем опыте оторваться от задачи полезно, а вот заменять в голове ее > контекст контекстом другой задачи как раз вредно. Ну да люди разные, > задачи тоже. > Ну это возможно. Просто обычно на ревью "отдыхаешь". Хотя... > > Другое дело, если ревью много. Тогда да, на них забивают. > > И это, кстати, тоже. Не написанный тест ловится хотя бы coverage, а > забитое ревью от выполненного без претензий к коду не отличить никак. > Да, тут правда. > >> Вот тут уже сомнения. Если сжатые сроки, то потеря в среднем получаса > >> на каждое ревью... Это какие же должны быть разработчики, чтобы оно > >> окупалось? > >> > > Запаренные. > > Я не видел, чтоб окупалось. Ревьюеры-то при этом - те же разработчики, и > точно так же запаренные. Да еще надо ревью делать, что еще больше > запаривает... > > В вышепоскипанном примере с байкой про Боинг как раз запаренности-то и > нет. Там регламент устроен так, чтобы затормозить именно запарку. > Ну хорошо Боингу, а когда "давай сократим срок до месяца, хотя можно делать шесть", а в реальности не помешало бы два, постоянно "атмосфера гонки" и ощущение того, что ничего не успеваешь. > >> >> Менталитет программиста тоже интернационален. С менталитетом "кодера > по > >> >> обезьяньей работе" хуже, но extreme programming - технология для > >> >> программистов. > >> >> > >> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет > >> > несколько сложно, и не для всех эта техника подходит. > >> > >> А никто не утверждал, что для всех. А вот русский с китайцем, скорее > >> всего, в паре как раз неплохо уживутся. Только роли будут не > >> переменные, а ближе к постоянным. Китаец кодит, русский следит и > >> корректирует. Характерного китайца не надо подгонять, зато надо > >> своевременно тормозить и/или поворачивать. Тогда он будет выдавать > >> качественный продукт, а быстро он его и так будет выдавать. > >> > > Что-то динамика развития Китая по отношению к РФ показывает: роли > > меняются. :-/ > > Ой, да ладно... Может, лет через несколько русский тут просто станет > лишним, но заменить китайца как работник... > Я как-то уже писал: китайцы свою процессорную архитектуру отгрохали, реализовали на ней процессоры и построили из них самый быстрый в мире суперкомпьютер, обогнав США (сейчас, вроде Япония первая). Где здесь русский? РФ в этом плане, пусть и не в полной жопе (есть те же Эльбрусы), но даже близко подойти не может. > >> >> >> > В любом случае, если я такое (чисто теоретически) предложу > менеджеру, > >> >> >> > он только у виска покрутит. Это же получается, что каждый > программист > >> >> >> > работает, условно половину времени, а половину сидит "и что-то > там > >> >> >> > смотрит". > >> >> > >> >> >> А если тебе не результат а имитацию бурной деятельности для > менеджера, > >> >> >> то да, подход ровно обратный. > >> >> > В конкретном случае мне нужно сделать для себя: имитировать там не > для кого. > >> >> > Над своими проектами я не за деньги работаю. > >> >> > И те, кто со мной работает, понимают, что если ты не сделаешь, > ничего не > >> >> > будет сделано. > >> >> > >> >> А если для себя, то предлагать вы будете не менеджеру, а себе. > >> >> Совершенно другая задача. > >> >> > >> > У меня так-то оба варианта сейчас есть. > >> > >> Ну и рассматривать их надо как две разных задачи, а не как одну общую. > >> И решать по-разному. > >> > > Согласен. > > Пока остановлюсь на том, что для себя. > > В любом случае, в механизмах большой компании "снизу" особо ничего не > > изменишь. > > Кстати, тоже есть варианты. Если помнить, что у нас нет цели поменять > компанию, нам достаточно поменять условия лично своей работы. Но это > совсем уже оффтопик. > Ну я бы не сказал, что нет такой цели, об этом и задумываюсь (или поменять отдел). Без одного другое не сделать.
