24.03.2018 11:47, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org @ Sat, 24 Mar 2018 10:58:11 +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 и зовем автора проблемного
> места. Но это нужно очень не всегда.
>
Но если в конторе более тысячи программистов, а за код отвечают разные
отделы, причём часть людей, его написавших, уже давно не работает, будет
ли такая схема эффективна (это не к моему случаю, а в общем)?
> За коммитами джуниоров просто присматривают вручную. Недолго, человек
> либо обучается, либо идет искать работу в другом месте.
>
Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
сложный, хотелось бы видеть, что уйдёт в репозиторий.
> > - Сколько людей работают с репозиторием?
>
> Десятка полтора-два.
>
Ну больше, чем в моём случае.
> >> В общем, даже модель pull request не использовали, не говоря уже о code
> >> review. А вот работу в паре как раз использовали.
> >>
> > А подробнее? Это из области "экстремального программирования"?
>
> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
> такие грабли".
>
> Результаты различного качества, в зависимости в основном от дисциплины
> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
> вылетает аппаратура, чем вылезают не дающие работать баги.
>
Только читал об этом, не думал, что в РФ используется. В любом случае,
если я такое (чисто теоретически) предложу менеджеру, он только у виска
покрутит. Это же получается, что каждый программист работает, условно
половину времени, а половину сидит "и что-то там смотрит".