[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Системы управления сервером?



>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
>  >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
>  >> настолько мало там багов, что написание тестов не окупается.
>  >> 
>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
> 
> Если тесты нельзя написать, то код негодный. Другое дело, что на
> написание тестов не всегда хватает ресурса.
> 
Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
делать?
А работа при загрузке ОС?

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

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

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

> Не, мне рассказывали байку о техпроцессе в Боинге с кодом, который идет
> в авионику. Там ревью есть, но начинается оно не с would-be коммита, а с
> обоснования, почему надо менять именно это место в коде, и как его
> менять. Только там питона, баша и луа быть не может - их интерпретаторы
> не удовлетворяют требованиям к тому техпроцессу.
> 
Согласен.

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

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

>  > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
>  > он только у виска покрутит. Это же получается, что каждый программист
>  > работает, условно половину времени, а половину сидит "и что-то там
>  > смотрит".

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

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

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

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


Reply to: