Re: Системы управления сервером?
artiom -> debian-russian@lists.debian.org @ Sat, 24 Mar 2018 16:59:02 +0300:
>> >> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
>> >> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких сложностей, и
>> >> код работает.
>> >>
>> > 1. Сейчас, где я работаю, используется TFS, прости Господи. Под Linux.
>> > Ревью проводится через CodeCollaborator. Это наследие такое. Гит тоже
>> > есть, но пока не везде.
>> > 2. Объективно лучше, чем ccollab, интерфейсы gitlab и bitbucket. Для
>> > всех без исключений. Даже те, кто больше всех матерился из-за перехода
>> > на git, в разных конторах, в итоге признавали, что "эти web-интерфейсы
>> > удобнее".
>>
>> > Не опровергаю ваш опыт, но узнать было бы интересно: как так?
>> > Т.е.:
>>
>> > - Первый вопрос: это код на Haskell, не C/C++ + Python + Lua + Bash + etc.?
>>
>> C, C++, Smalltalk, Haskell, Scala, tcl.
>>
>> > - Как проводится процесс контроля и устранения недостатков?
>>
>> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
>> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
>> настолько мало там багов, что написание тестов не окупается.
>>
> Ну это две параллельные задачи. Часто тесты нельзя написать.
Если тесты нельзя написать, то код негодный. Другое дело, что на
написание тестов не всегда хватает ресурса.
> Плюс, на ревью проверяется читабельность кода и его логическая
> корректность (и тесты, и код возможно написать некорректно). Плюс, в
> два раза больше работы. В общем, одно другое не заменяет.
Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в
процессах, которые применяются там, где я работал, ревью отсутствует.
>> > - Если несколько ревьюверов, как они просматривают код и вносят замечания?
>>
>> Их нет. Ревьюеров, в смысле. В одной из предыдущих контор был мем "кто
>> первый встал, того и грабли". В смысле, багу исправляет тот, кто на нее
>> наступил (или взялся за багрепорт). Это обеспечивает коллективное
>> владение кодом. В отличие от code review, которое все-таки нет. При
>> необходимости {git,svn,cvs} annotate и зовем автора проблемного
>> места. Но это нужно очень не всегда.
>>
> Но если в конторе более тысячи программистов, а за код отвечают разные
> отделы, причём часть людей, его написавших, уже давно не работает, будет
> ли такая схема эффективна (это не к моему случаю, а в общем)?
А в общем задача неразрешима. Это еще Гёдель доказал :) Решается всегда
в конкретном.
Если более тысячи программистов отвечают за одно место в коде, код
работать не будет. В больших конторах за каждое место в коде отвечает
очень небольшое количество людей, а протоколы взаимодействия между кодом
разных отделов компактны.
>> За коммитами джуниоров просто присматривают вручную. Недолго, человек
>> либо обучается, либо идет искать работу в другом месте.
>>
> Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
> сложный, хотелось бы видеть, что уйдёт в репозиторий.
В одной из контор у нас были любители почитать код, уходящий в
репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
желающим. По почте. Тем же способом присматривали за джуниорами.
Практика показывает, что читать код _до_ попадания в репозиторий - не
очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
Не, мне рассказывали байку о техпроцессе в Боинге с кодом, который идет
в авионику. Там ревью есть, но начинается оно не с would-be коммита, а с
обоснования, почему надо менять именно это место в коде, и как его
менять. Только там питона, баша и луа быть не может - их интерпретаторы
не удовлетворяют требованиям к тому техпроцессу.
Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
там такова, что оно окупается.
>> >> В общем, даже модель pull request не использовали, не говоря уже о code
>> >> review. А вот работу в паре как раз использовали.
>> >>
>> > А подробнее? Это из области "экстремального программирования"?
>>
>> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
>> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
>> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
>> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
>> такие грабли".
>>
>> Результаты различного качества, в зависимости в основном от дисциплины
>> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
>> вылетает аппаратура, чем вылезают не дающие работать баги.
>>
> Только читал об этом, не думал, что в РФ используется.
Это парадигма, ей чихать на государственные границы.
> В любом случае, если я такое (чисто теоретически) предложу менеджеру,
> он только у виска покрутит. Это же получается, что каждый программист
> работает, условно половину времени, а половину сидит "и что-то там
> смотрит".
А если тебе не результат а имитацию бурной деятельности для менеджера,
то да, подход ровно обратный. Берем софт для совместной работы,
выбираем его по критерию "наиболее красочная презентация", закупаем под
него сервер, месяц инсталлируем, три месяца настраиваем. Менеджер от
презентации в экстазе, и всё согласовывае. Если бизнес-процесс
позволяет, покупаем платный саппорт, чтобы жопу прикрыть. Потом
заставляем всех им пользоваться. Все дружно заняты все 8 часов, а то и
12...
И кстати, code review более чем подходит под определение "что-то там
смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время
code review?
P.S. жалоба листмастеру на оффтопик ушла.
Reply to: