?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


Gaperton
gaperton at 2011-06-18 20:34 (UTC) (Link)
"Всегда можно поставить левый номер бага"

И кроме того, тебе известно, что в случае с JIRA и SVN можно повесить не просто тупой пре-коммит-хук, а хук, который требует наличия указанной задачи в JIRA в определенном состоянии? :) Скажем, в статусе "В работе", и при этом она должна быть назначена именно на тебя?

А вот можно.
миххон
mihhon at 2011-06-18 20:43 (UTC) (Link)
а вы пробовали сами внедрить все эти правила?
с хуками, связями почты-vcs-документами?

если да, сколько человек в команде и какой размер конторы (если в конторе больше одной программерской команды) ?
Gaperton
gaperton at 2011-06-18 21:01 (UTC) (Link)
> а вы пробовали сами внедрить все эти правила?
> с хуками, связями почты-vcs-документами?

Конечно. У нас в Финаме все работает именно так. Это гораздо проще, чем бегать за людьми, и проверять соблюдение процесса, не так ли?

И в CQG, где я работал первую половину нулевых, все работало примерно так.

> если да, сколько человек в команде и какой размер конторы (если в конторе больше одной программерской команды) ?

Точно не считал - но где-то под сотню. Пока не все из них охвачены новым тулчейном и процессом, но мы в самом начале. :)

В CQG сейчас две сотни.
Gaperton
gaperton at 2011-06-18 21:16 (UTC) (Link)
Могу описать, как я это сделал. В общем, все достаточно просто - в основе JIRA + SVN + WebSVN, никаких хитростей. Делается прямолинейно, без программирования, никакого хайтека.
миххон
mihhon at 2011-06-18 21:24 (UTC) (Link)
да, наверно это не так и сложно сделать технически

сложнее организационно

для небольшой компании это не так уж и нужно

для большой - не получится, митинги о целесообразности внедрения будут длиться дольше, чем время нахождение в текущей должности того, кто внесёт вопрос на обсуждение

а в софтверной конторе (у брокера, по-большому, весь бизнес софтом делается) на 100-200 человек, где решение принимается 2-5-10 ключевыми людьми, которые тесно сотрудничают, это возможно
Gaperton
gaperton at 2011-06-18 21:30 (UTC) (Link)
> для большой - не получится, митинги о целесообразности внедрения будут длиться дольше, чем время нахождение в текущей должности того, кто внесёт вопрос на обсуждение

Какие еще "митинги о целесообразности внедрения"? :) Принципиальные вопросыь , относящиеся к процессу разработки, решаются руководителем соответствующего уровня, а не "митингами". :) Каждый должен свою работу делать.

Вопрос процессов уровня компании, и технической политики - это вопрос руководителя R&D департамента. "Митинги о целесообразности" :).
kholodova
kholodova at 2011-06-21 20:21 (UTC) (Link)
А опишите, очень интересно.
malica_dee
malica_dee at 2011-06-18 20:48 (UTC) (Link)
Достаточно одной открытой задачи, и вопрос где брать левый номер - решен. Пока кто-то, кому не наплевать на консистенси, не сверит задачу с кодом.
На практике периодически бывает, что программер находит косяк, который не нашли QA, ленится заводить под него баг и ставит левый номер при коммите фикса.
Gaperton
gaperton at 2011-06-18 21:04 (UTC) (Link)
> Достаточно одной открытой задачи, и вопрос где брать левый номер - решен.

До момента, когда эта открытая задача в трекере пойдет на ревью, и ревьювер не увидит зацепленные за нее левые коммиты, которые вернет тебе обратно.

> На практике периодически бывает, что программер находит косяк, который не нашли QA, ленится заводить под него баг и ставит левый номер при коммите фикса.

С современными тулами несложно сделать так, что это будет в принципе невозможно.
malica_dee
malica_dee at 2011-06-19 08:15 (UTC) (Link)
Если ревьер из той же породы, то закроет глаза. Человеческий фактор.
malica_dee
malica_dee at 2011-06-19 08:43 (UTC) (Link)
Угу, но если вы будете заставлять людей выполнять кучу телодвижения для того, чтобы (ну например) исправить орфографическую ошибку в сообщении об ошибке, или наказывать, если они этого делать не будут - не мне объяснять, какой будет эффект у такой политики на моральный климат в коллективе и что будут делать разработчики.
dr.chaos
dr_cha0s at 2011-06-21 15:40 (UTC) (Link)
Точно знаю в git-е, можно огранизовать ворфлоу такого рода: При переводе тикета на девелопера, создаётся ветка с именем из номера тикета и девелопер имеет право пушить коммиты только туда. Сколько открытых тасок, столько и веток. При переводе ревьюером тикета в reviewed состояние ветка мержится в master, при этом автор коммита девелопер, а коммитер - ревьюер и они с коммитом вместе навсегда :). А аутентификация чисто доменная. Т.е. технически реализовать это можно весьма жестко.
Яков Сироткин
yakov_sirotkin at 2011-06-18 20:56 (UTC) (Link)
Хук можно повесить, если у тебя есть доступ к человеку, который может администрировать сервер.

И нормальным людям хватает просто автоматической привязки коммитов к багам и почтовой рассылки.
Gaperton
gaperton at 2011-06-18 21:07 (UTC) (Link)
> Хук можно повесить, если у тебя есть доступ к человеку, который может администрировать сервер.

А что - такого доступа каким-то образом может не быть? :)

> И нормальным людям хватает просто автоматической привязки коммитов к багам и почтовой рассылки.

В целом - да, хватит. Но хук на пустой коммит-мессадж поставить не худо - чтобы рефлекс побороть. Кроме того - что может быть плохого в автоматической проверке, и исключении возможности ошибиться? Люди же ошибаются, не компьютеры. Нехорошо их за это наказывать.
Яков Сироткин
yakov_sirotkin at 2011-06-18 21:11 (UTC) (Link)
Ещё бывает надо спасибо сказать, что в принципе есть svn на сервере, у которого должен быть бэкап.
Previous Entry  Next Entry