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