> artiom -> debian-russian@lists.debian.org  @ Mon, 26 Mar 2018 20:53:38 +0300:
> 
>  >>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
>  >>  >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
>  >>  >> настолько мало там багов, что написание тестов не окупается.
>  >>  >> 
>  >>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
>  >> 
>  >> Если тесты нельзя написать, то код негодный. Другое дело, что на
>  >> написание тестов не всегда хватает ресурса.
>  >> 
>  > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
>  > делать?
> 
> Не каждый. Для unit-тестирования да, а для acceptance подключать
> аппаратуру, ага.
> 
А она бажная. Как факт. Потому что тоже разрабатывается.

>  > А работа при загрузке ОС?
> 
> И это тоже надо тестировать. Ну да, придется контейнер тюнить.
> 
>  >>  > Плюс, на ревью проверяется читабельность кода и его логическая
>  >>  > корректность (и тесты, и код возможно написать некорректно).  Плюс, в
>  >>  > два раза больше работы.  В общем, одно другое не заменяет.
>  >> 
>  >> Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в
>  >> процессах, которые применяются там, где я работал, ревью отсутствует.
>  >> 
>  > Понял вас. Хотя, всё-равно не могу представить. У меня опыт поменьше, но
>  > всё-таки, в трёх достаточно известных конторах, где я работал, ревью
>  > имеется, причём через WEB GUI.
> 
> Известная контора - еще далеко не гарантия качества результата :)
> 
Ну, я точно в курсе.

>  >> Если более тысячи программистов отвечают за одно место в коде, код
>  >> работать не будет. В больших конторах за каждое место в коде отвечает
>  >> очень небольшое количество людей, а протоколы взаимодействия между кодом
>  >> разных отделов компактны.
>  >> 
>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
>  >>  >> либо обучается, либо идет искать работу в другом месте.
>  >>  >> 
>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
>  >> 
>  >> В одной из контор у нас были любители почитать код, уходящий в
>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
>  >> 
>  > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
>  > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
> 
> Тут важный момент - не веб или почта "код не проходит в репозиторий без
> одобрения". У нас проходил. Мой point в том, что проблем от этого не
> происходит.
> 
Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
практики.

>  >> Практика показывает, что читать код _до_ попадания в репозиторий - не
>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
>  >> 
>  > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
>  > ли - не допустить?
>  > Какая практика?
>  > В чём нехорошесть данной идеи?
> 
> Тормозной путь. Между моментом изменения кода и моментом, когда код
> будет изменен, проходит время.
Как минус, так и плюс.

> Либо это очень большое время, либо
> ревьюер работает с частыми прерываниями. Если у него содержательная
> работа не обезьянья, то частые прерывания очень сильно снижают его
> продуктивность. Так и так изрядно падает КПД.
>
Ну, допустим, пара дней на ревью - это большое время?
Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
ждать ответов автора (который в этом время уже над другим работает), к
тому же, ревьюверов бывает несколько.

>  >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
>  >> там такова, что оно окупается.
>  >> 
>  > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
>  > привязана задача, после чего проверяются (перед репозиторием).
> 
> А "в случае того, что есть сейчас" непонятно, окупается ли этот
> тормозной путь.
> 
Продукт окупается.
"Тормозной путь", скорее всего, да.
Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.

>  >>  >>  >> В общем, даже модель pull request не использовали, не говоря уже 
> о code
>  >>  >>  >> review. А вот работу в паре как раз использовали.
>  >>  >>  >> 
>  >>  >>  > А подробнее? Это из области "экстремального программирования"?
>  >>  >> 
>  >>  >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
>  >>  >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
>  >>  >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
>  >>  >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
>  >>  >> такие грабли".
>  >>  >> 
>  >>  >> Результаты различного качества, в зависимости в основном от дисциплины
>  >>  >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
>  >>  >> вылетает аппаратура, чем вылезают не дающие работать баги.
>  >>  >> 
>  >>  > Только читал об этом, не думал, что в РФ используется.
>  >> 
>  >> Это парадигма, ей чихать на государственные границы.
>  >> 
>  > Границы не при чём, имеет значение "менталитет", в общем и, в частности:
>  > культура разработки и стоимость такого подхода.
> 
> Менталитет программиста тоже интернационален. С менталитетом "кодера по
> обезьяньей работе" хуже, но extreme programming - технология для
> программистов.
> 
Ну что-то мне подсказывает, что русским и китайцам ужиться будет
несколько сложно, и не для всех эта техника подходит.

>  >>  > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
>  >>  > он только у виска покрутит. Это же получается, что каждый программист
>  >>  > работает, условно половину времени, а половину сидит "и что-то там
>  >>  > смотрит".
> 
>  >> А если тебе не результат а имитацию бурной деятельности для менеджера,
>  >> то да, подход ровно обратный.
>  > В конкретном случае мне нужно сделать для себя: имитировать там не для 
> кого.
>  > Над своими проектами я не за деньги работаю.
>  > И те, кто со мной работает, понимают, что если ты не сделаешь, ничего не
>  > будет сделано.
> 
> А если для себя, то предлагать вы будете не менеджеру, а себе.
> Совершенно другая задача.
> 
У меня так-то оба варианта сейчас есть.

>  >> Берем софт для совместной работы,
>  >> выбираем его по критерию "наиболее красочная презентация", закупаем под
>  >> него сервер, месяц инсталлируем, три месяца настраиваем.  Менеджер от
>  >> презентации в экстазе, и всё согласовывае.  Если бизнес-процесс
>  >> позволяет, покупаем платный саппорт, чтобы жопу прикрыть.  Потом
>  >> заставляем всех им пользоваться.  Все дружно заняты все 8 часов, а то и
>  >> 12...
>  >> 
>  > Как ни печально, наблюдаю подвижки в этом направлении.
> 
> Я с натуры это писал :)
> 
Ну а я "в натуре" это вижу (хотя и не настолько всё плохо).

>  >> И кстати, code review более чем подходит под определение "что-то там
>  >> смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время
>  >> code review?
>  >> 
>  > А у нас на ревью время специально выделяется (похоже, что были
>  > менеджеры, которые не понимали, что это "за ревью такое", и в правила
>  > записали официально).
>  > На парное программирование же времени не выделяют.
>  > Код пишут не вместе, хотя иногда вместе раздирают.
> 
> А у нас выделяют время на работу, а не процедуры определенного
> вида. Надо поработать в паре - попросил коллегу, сели, поработали в
> паре. Надо попросить коллегу посмотреть код - попросил коллегу
> посмотреть код. И т.д.
> 
Так тоже возможно, но постоянную "работу в паре" не одобрят точно.

>  >> P.S. жалоба листмастеру на оффтопик ушла.
>  >> 
>  > На тот офтопик, который вы поддерживаете сами? :-)
>  > У вас, прямо таки сейчас духовность зашкалила.
> 
> Нет, на политический. Который я как раз не поддерживаю.
> 
А причём здесь эта тема?

Ответить