artiom -> debian-russian@lists.debian.org @ Tue, 27 Mar 2018 23:35:21 +0300:
>> >> >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на >> >> >> грабли :) Код на Haskell и Scala даже и не тестируется >> автомагически, >> >> >> настолько мало там багов, что написание тестов не окупается. >> >> >> >> >> > Ну это две параллельные задачи. Часто тесты нельзя написать. >> >> >> >> Если тесты нельзя написать, то код негодный. Другое дело, что на >> >> написание тестов не всегда хватает ресурса. >> >> >> > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз >> > делать? >> >> Не каждый. Для unit-тестирования да, а для acceptance подключать >> аппаратуру, ага. >> > А она бажная. Как факт. Потому что тоже разрабатывается. Именно поэтому для acceptance, или, точнее, для integration, ее надо подключать. >> >> Если более тысячи программистов отвечают за одно место в коде, код >> >> работать не будет. В больших конторах за каждое место в коде отвечает >> >> очень небольшое количество людей, а протоколы взаимодействия между кодом >> >> разных отделов компактны. >> >> >> >> >> За коммитами джуниоров просто присматривают вручную. Недолго, >> человек >> >> >> либо обучается, либо идет искать работу в другом месте. >> >> >> >> >> > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код >> >> > сложный, хотелось бы видеть, что уйдёт в репозиторий. >> >> >> >> В одной из контор у нас были любители почитать код, уходящий в >> >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты >> >> желающим. По почте. Тем же способом присматривали за джуниорами. >> >> >> > Примерно так и есть, но почта заменяется ccollab (или, в общем случае, >> > любым web интерфейсом), и код не проходит в репозиторий без одобрения. >> >> Тут важный момент - не веб или почта "код не проходит в репозиторий без >> одобрения". У нас проходил. Мой point в том, что проблем от этого не >> происходит. >> > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой > практики. Собственно, системы управления версиями придуманы ровно для этой ситуации. Чтобы заменить трехслойную бюрократию ревью, которая работает месяц, но тоже пропускает баги, возможностью найти и откатить изменение, если оно оказалось неудачным. А чтобы неудачное изменение не долетело до заказчика, существует релизный цикл. И ревью его необходимости не отменяет. >> >> Практика показывает, что читать код _до_ попадания в репозиторий - не >> >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить. >> >> >> > Но сборки уже будут собраны и отправлены на тестирование, так не лучше >> > ли - не допустить? >> > Какая практика? >> > В чём нехорошесть данной идеи? >> >> Тормозной путь. Между моментом изменения кода и моментом, когда код >> будет изменен, проходит время. > Как минус, так и плюс. В течение этого времени в системе присутствуют и старые, и новые баги. Где плюс? >> Либо это очень большое время, либо >> ревьюер работает с частыми прерываниями. Если у него содержательная >> работа не обезьянья, то частые прерывания очень сильно снижают его >> продуктивность. Так и так изрядно падает КПД. >> > Ну, допустим, пара дней на ревью - это большое время? Офигительно. За это время я успею еще много чего сделать, и оно будет пересекаться по коду с теми изменениями, и если изменение не примут как есть, то попытка что-то там подкрутить приведет к конфликтам с точки зрения VCS. А разбор конфликта - одно из самых багопродуцирующих действий. И результатом его оказывается патч, разбираться в котором - уже два полных рабочих дня, а не просто задержка на пару дней. > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и > ждать ответов автора (который в этом время уже над другим работает), к > тому же, ревьюверов бывает несколько. Я про прерывания не процесса ревью, а про прерывания процесса своей работы необходимостью ревью. Для ревью надо загрузить в голову контекст той задачи, к которой относится просматриваемый код. Он там неизбежно заменит контекст своей задачи. После ревью придется снова грузить свой. Это время, и в случае сложной задачи весьма изрядное. От 15 минут до часа каждая перегрузка, а их тут две. >> >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки >> >> там такова, что оно окупается. >> >> >> > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним >> > привязана задача, после чего проверяются (перед репозиторием). >> >> А "в случае того, что есть сейчас" непонятно, окупается ли этот >> тормозной путь. >> > Продукт окупается. > "Тормозной путь", скорее всего, да. > Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков. Вот тут уже сомнения. Если сжатые сроки, то потеря в среднем получаса на каждое ревью... Это какие же должны быть разработчики, чтобы оно окупалось? >> >> >> >> В общем, даже модель pull request не использовали, не говоря >> уже о code >> >> >> >> review. А вот работу в паре как раз использовали. >> >> >> >> >> >> >> > А подробнее? Это из области "экстремального программирования"? >> >> >> >> >> >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй >> >> >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем >> >> >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь >> возможность >> >> >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда >> вот >> >> >> такие грабли". >> >> >> >> >> >> Результаты различного качества, в зависимости в основном от >> дисциплины >> >> >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще >> >> >> вылетает аппаратура, чем вылезают не дающие работать баги. >> >> >> >> >> > Только читал об этом, не думал, что в РФ используется. >> >> >> >> Это парадигма, ей чихать на государственные границы. >> >> >> > Границы не при чём, имеет значение "менталитет", в общем и, в частности: >> > культура разработки и стоимость такого подхода. >> >> Менталитет программиста тоже интернационален. С менталитетом "кодера по >> обезьяньей работе" хуже, но extreme programming - технология для >> программистов. >> > Ну что-то мне подсказывает, что русским и китайцам ужиться будет > несколько сложно, и не для всех эта техника подходит. А никто не утверждал, что для всех. А вот русский с китайцем, скорее всего, в паре как раз неплохо уживутся. Только роли будут не переменные, а ближе к постоянным. Китаец кодит, русский следит и корректирует. Характерного китайца не надо подгонять, зато надо своевременно тормозить и/или поворачивать. Тогда он будет выдавать качественный продукт, а быстро он его и так будет выдавать. >> >> > В любом случае, если я такое (чисто теоретически) предложу менеджеру, >> >> > он только у виска покрутит. Это же получается, что каждый программист >> >> > работает, условно половину времени, а половину сидит "и что-то там >> >> > смотрит". >> >> >> А если тебе не результат а имитацию бурной деятельности для менеджера, >> >> то да, подход ровно обратный. >> > В конкретном случае мне нужно сделать для себя: имитировать там не для >> кого. >> > Над своими проектами я не за деньги работаю. >> > И те, кто со мной работает, понимают, что если ты не сделаешь, ничего не >> > будет сделано. >> >> А если для себя, то предлагать вы будете не менеджеру, а себе. >> Совершенно другая задача. >> > У меня так-то оба варианта сейчас есть. Ну и рассматривать их надо как две разных задачи, а не как одну общую. И решать по-разному. >> >> И кстати, code review более чем подходит под определение "что-то там >> >> смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время >> >> code review? >> >> >> > А у нас на ревью время специально выделяется (похоже, что были >> > менеджеры, которые не понимали, что это "за ревью такое", и в правила >> > записали официально). >> > На парное программирование же времени не выделяют. >> > Код пишут не вместе, хотя иногда вместе раздирают. >> >> А у нас выделяют время на работу, а не процедуры определенного >> вида. Надо поработать в паре - попросил коллегу, сели, поработали в >> паре. Надо попросить коллегу посмотреть код - попросил коллегу >> посмотреть код. И т.д. >> > Так тоже возможно, но постоянную "работу в паре" не одобрят точно. "Тут ведь как"... С одной стороны, она переменная. XP настаивает на постоянной, но в нашей практике она в основном используется в случаях, где одна голова хорошо, а две лучше. С другой, "вам шашечки или ехать?" В смысле, результат или квартальный отчет? Если нужен результат, и работа в паре его дает, то с хрена ли ее не одобрять? Вы полагаете, что поодиночке будет лучше? Ну, давайте сравним на интервале в пару лет, чтобы в статистику затрат еще и саппорт попал.