> >> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг, > >> если тест сломался, то багу надо чинить. Если бага сломала сразу много > >> тестов, починка приоритетна, и все дела. > >> > > Ладно, умолчу про тех, кто "чинит" тесты в таком случае. > > Такие тоже бывали. > > Но очень редко тестовое покрытие полное. > > Практически никогда. Но требуется не полнота, а хорошая вероятность > вылавливания баги раньше, чем на нее наступит заказчик. > Что обеспечивается полнотой...
> >> >> > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью > и > >> >> > ждать ответов автора (который в этом время уже над другим > работает), к > >> >> > тому же, ревьюверов бывает несколько. > >> >> > >> >> Я про прерывания не процесса ревью, а про прерывания процесса своей > >> >> работы необходимостью ревью. Для ревью надо загрузить в голову > контекст > >> >> той задачи, к которой относится просматриваемый код. Он там неизбежно > >> >> заменит контекст своей задачи. После ревью придется снова грузить > свой. > >> >> Это время, и в случае сложной задачи весьма изрядное. От 15 минут до > >> >> часа каждая перегрузка, а их тут две. > >> > Ну час - это явный перебор. > >> > >> Это значит, у тебя все задачи простые. > >> > > Не сказал бы. Ревью компактные относительно. И, естественно, что я не > > вникаю в весь код: только в изменения. > > То есть как раз неочевидные грабли, которые вносит изменение, ты > пропустишь с вероятностью, близкой к 1. > Частично. Но смотрят несколько человек. В общем-то спор ни о чём: ревью помогает, но имеет свои минусы, это очевидно. > >> > А отрыв на 15 минут - не критично: вы же не соревновательным > >> > программированием занимаетесь, надеюсь? > >> > >> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в > контекст. > >> > > Есть вечер, утро и обед, если не критично. > > В обед надо обедать. И мозгом тоже. Иначе очень быстро огребешь гастрит. > Надо... > >> > Иногда вообще полезно от задачи оторваться, бывает. > >> > >> В моем опыте оторваться от задачи полезно, а вот заменять в голове ее > >> контекст контекстом другой задачи как раз вредно. Ну да люди разные, > >> задачи тоже. > >> > > Ну это возможно. Просто обычно на ревью "отдыхаешь". Хотя... > > Во-во. Если делать его как следует, то нет, не отдыхаешь, а вовсе даже > наоборот, очень интенсивно скрипишь мозгами. > Обычно, после задач, проще. > >> >> Вот тут уже сомнения. Если сжатые сроки, то потеря в среднем получаса > >> >> на каждое ревью... Это какие же должны быть разработчики, чтобы оно > >> >> окупалось? > >> >> > >> > Запаренные. > >> > >> Я не видел, чтоб окупалось. Ревьюеры-то при этом - те же разработчики, и > >> точно так же запаренные. Да еще надо ревью делать, что еще больше > >> запаривает... > >> > >> В вышепоскипанном примере с байкой про Боинг как раз запаренности-то и > >> нет. Там регламент устроен так, чтобы затормозить именно запарку. > >> > > Ну хорошо Боингу, а когда "давай сократим срок до месяца, хотя можно > > делать шесть", а в реальности не помешало бы два, постоянно "атмосфера > > гонки" и ощущение того, что ничего не успеваешь. > > На "давай сократим срок до месяца" я отвечаю "давай тогда делать работу > будет тот, кто сделает ее за месяц". Способствует просветлению. > Пока не поспособствовало. На практике. Видимо, я не умею особо доходчиво объяснять. Впрочем, какая разница? Ну сократили, вылезли критичные ошибки, сроки продлились. > >> >> >> Менталитет программиста тоже интернационален. С менталитетом > "кодера по > >> >> >> обезьяньей работе" хуже, но extreme programming - технология для > >> >> >> программистов. > >> >> >> > >> >> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет > >> >> > несколько сложно, и не для всех эта техника подходит. > >> >> > >> >> А никто не утверждал, что для всех. А вот русский с китайцем, скорее > >> >> всего, в паре как раз неплохо уживутся. Только роли будут не > >> >> переменные, а ближе к постоянным. Китаец кодит, русский следит и > >> >> корректирует. Характерного китайца не надо подгонять, зато надо > >> >> своевременно тормозить и/или поворачивать. Тогда он будет выдавать > >> >> качественный продукт, а быстро он его и так будет выдавать. > >> >> > >> > Что-то динамика развития Китая по отношению к РФ показывает: роли > >> > меняются. :-/ > >> > >> Ой, да ладно... Может, лет через несколько русский тут просто станет > >> лишним, но заменить китайца как работник... > >> > > Я как-то уже писал: китайцы свою процессорную архитектуру отгрохали, > > реализовали на ней процессоры и построили из них самый быстрый в мире > > суперкомпьютер, обогнав США (сейчас, вроде Япония первая). > > Где здесь русский? > > А я этого в оригинале не видел, и не знаю, насколько тыренная (вряд ли > из России, скорее всего, из Штатов) та архитектура. А типичный китаец, > по опыту, хорошо работает, только будучи поставлен на рельсы. Рельсы же > кто-то другой должен проложить. > Китайцев много. И, если утрировать, "рельсы" они построили раньше европейцев: у них уже демократия через диктатуру на олигархат успела смениться, когда ваши предки с каменными топорами бегали. Может и тыренная архитектура, особенно с учётом сложностей переноса ПО на новую, но не факт (не копал, по ссылкам на вики есть ссылки на доки): https://ru.wikipedia.org/wiki/ShenWei https://ru.wikipedia.org/wiki/SW26010 https://ru.wikipedia.org/wiki/Sunway_TaihuLight Написано, что "использовались некоторые идеи архитектуры DEC Alpha и SPARC", что в целом нормально, и намекает на свою разработку. > >> > В любом случае, в механизмах большой компании "снизу" особо ничего не > >> > изменишь. > >> > >> Кстати, тоже есть варианты. Если помнить, что у нас нет цели поменять > >> компанию, нам достаточно поменять условия лично своей работы. Но это > >> совсем уже оффтопик. > >> > > Ну я бы не сказал, что нет такой цели, об этом и задумываюсь (или > > поменять отдел). > > Без одного другое не сделать. > > Поменять компанию может быть только средством. Целью - только если > сдуру. Даже если это твоя компания (в смысле, если ты ее владелец). > Ну естественно, это средство, но я же написал: без одного другое не сделать.
