?

Log in

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 департамента. "Митинги о целесообразности" :).
миххон
mihhon at 2011-06-18 21:37 (UTC) (Link)
большая компания - это большая бюрократическая машина, мотивация частей которой не совпадает с интересами компании :)

Принципиальные вопросы, относящиеся к процессу разработки, решаются исходя из 2х принципов: 1. уменьшение собственной ответственности, 2. увеличение размера команды и бюджета, что прямо влияет на зарплату и вес внутри машины

Вопрос процессов уровня компании, и технической политики - это вопрос кому достанется больше власти и откатов :)
Gaperton
gaperton at 2011-06-18 21:39 (UTC) (Link)
Ну если все так - то конечно все погрязнет в митингах :).
Ilya
tech_mind at 2011-06-20 18:05 (UTC) (Link)
> Какие еще "митинги о целесообразности внедрения"? :) Принципиальные вопросыь , относящиеся к процессу разработки, решаются руководителем соответствующего уровня, а не "митингами". :) Каждый должен свою работу делать.

Буквально пару месяцев назад, я пришел в новую для себя компанию и мягко говоря был в шоке, когда посмотрел код, посмотрел вики(там было аж два стандарта), и понял, что стандарты кодирования мягко говоря не соблюдаются, а на вопрос к руководителю какого мне был дан ответ: "У нас анархия. Ввести стандарты кодирования вызовет больше срача, по их поводу, чем польза от внедрения". Вот как, то так, но продукт приносит деньги и немалые, так что всех все устраивает.
Gaperton
gaperton at 2011-06-20 21:39 (UTC) (Link)
"Стоимость внесения изменений". Maintainability. Это - показатель, на который влияют обсуждаемые здесь вещи.

Он аукнется "когда нибудь, и может быть". Посему - не принимается во внимание деревянным менеджментом.
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)
Угу, но если вы будете заставлять людей выполнять кучу телодвижения для того, чтобы (ну например) исправить орфографическую ошибку в сообщении об ошибке, или наказывать, если они этого делать не будут - не мне объяснять, какой будет эффект у такой политики на моральный климат в коллективе и что будут делать разработчики.
Gaperton
gaperton at 2011-06-19 10:13 (UTC) (Link)
Ревью исправления орфографии занимает одну минуту. Так что разумеется буду. А вдруг в изменениях _не только_ исправление орфографической ошибки? А вдруг там какой-то левый код зацеплен, по принципу, изложенному выше?

Эффект от такой политики на моральный климат - попрошу объяснить. :) Че-то за 6 лет в CQG я, работая программистом и тимлидом, не заметил отрицательного эффекта именно от этой политики - только положительные.
malica_dee
malica_dee at 2011-06-19 13:45 (UTC) (Link)
Ну чуть ниже по треду тобой же был изложен легальный в вашей конторе способ не делать лишнюю работу, если бы он легальным не был, то результатом было бы накапливающееся раздражение и "да ну его, когда QA тикет заведут, тогда и исправлю".

У нас предпочитают вместо "прицепа" к тикету, делать отдельный коммит, в котором честно написано
Bug ID: n/a
Desc: typo corrected
Если все капельку серьезнее, чем исправление "p" на "o" - то будет там и ревьюер. Если речь идет о чем-то важном - ну тогда пишем тикет, открываем баг, заказчик должен знать, над чем разработчик трудился.

Что характерно - это облегчает чтение каментов к коммитам, "прицепы" считаются скорее порочной практикой.
Gaperton
gaperton at 2011-06-19 10:10 (UTC) (Link)
Если будет знать, что разделяет ответственность за коммит - то так легко не закроет.

А после того, как кто-нибудь "из той же породы" за аналогичное раздолбайство получит взыскание - будет трижды думать, прежде чем закрывать глаза.
malica_dee
malica_dee at 2011-06-19 13:54 (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 на сервере, у которого должен быть бэкап.
zhabodav
zhabodav at 2011-06-19 09:34 (UTC) (Link)
А поднять свой сервер - религия не позволяет?
Яков Сироткин
yakov_sirotkin at 2011-06-19 10:24 (UTC) (Link)
Корпоративные стандарты. Хотя иногда возникает желание использовать какой-нибудь сервис вроде GitHub, а местные админы пусть как-нибудь сами.
Previous Entry  Next Entry