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. А вот работу в паре как раз использовали. > >> > > А подробнее? Это из области "экстремального программирования"? > > Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй > рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем > абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность > сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот > такие грабли". > > Результаты различного качества, в зависимости в основном от дисциплины > написания тестов. Но так, чтобы было неработоспособно - нет. Чаще > вылетает аппаратура, чем вылезают не дающие работать баги. > Только читал об этом, не думал, что в РФ используется. В любом случае, если я такое (чисто теоретически) предложу менеджеру, он только у виска покрутит. Это же получается, что каждый программист работает, условно половину времени, а половину сидит "и что-то там смотрит".