Re: Системы управления сервером?
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 настаивает на
постоянной, но в нашей практике она в основном используется в случаях,
где одна голова хорошо, а две лучше. С другой, "вам шашечки или ехать?"
В смысле, результат или квартальный отчет? Если нужен результат, и
работа в паре его дает, то с хрена ли ее не одобрять? Вы полагаете, что
поодиночке будет лучше? Ну, давайте сравним на интервале в пару лет,
чтобы в статистику затрат еще и саппорт попал.
Reply to: