Re: Системы управления сервером?
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 и зовем автора проблемного
места. Но это нужно очень не всегда.
За коммитами джуниоров просто присматривают вручную. Недолго, человек
либо обучается, либо идет искать работу в другом месте.
> - Как и кем производится слияние feature-ветки в основную?
Релиз-менеджером. В смысле, тем, кто сегодня релиз-менеджер.
> - Сколько людей работают с репозиторием?
Десятка полтора-два.
>> В общем, даже модель pull request не использовали, не говоря уже о code
>> review. А вот работу в паре как раз использовали.
>>
> А подробнее? Это из области "экстремального программирования"?
Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
такие грабли".
Результаты различного качества, в зависимости в основном от дисциплины
написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
вылетает аппаратура, чем вылезают не дающие работать баги.
Reply to: