?

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 19:54 (UTC) (Link)
> Но я не согласен, что запреты и наказания будут работать.

Удивительное рядом. Что же им помешает работать? :)

> Code review - практика понятная и в некоторых проектах безусловно необходимая. Но применение её не всегда целесообразно или даже не всегда возможно.

Без кодревью не будет соблюдаться кодстандарт, и код не будет понятным. Чтобы писать для человека, а не для машины, автор должен быть абсолютно уверен, что его код прочтет человек. Сейчас прочтет, не через год.

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

Про "не все всегда возможно" - я изумлен. Пример, пожалуйста. Что же нам может помешать?

> А вот документирование через JavaDoc - это откровенная лажа. Разве что JavaDoc будет писать ревьюер, а коммитер будет его проверять.

Почему?
Яков Сироткин
yakov_sirotkin at 2011-06-18 20:10 (UTC) (Link)
Всегда можно поставить левый номер бага или ласково убедить ревьюера, что нужно быстренько проапрувить, потому что так надо.

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

Фатально помешать ревью может отсутствие двух вменяемых программистов в команде. А ещё бывают административные проблемы вроде разных часовых поясов и сложностях в настройке VCS.

С JavaDoc всё довольно просто: not tested - not implemented. И на практике мы обычно имеем первую версию JavaDoc к десятой версии кода, что никакого смысла не имеет. А вот комментарии к коммитам и история изменений - вот это работает.
Gaperton
gaperton at 2011-06-18 20:18 (UTC) (Link)
> Всегда можно поставить левый номер бага

И тогда ревьювер, когда к нему придет настоящая задача, не увидит твоего коммита, когда к нему придет задача. После чего он завернет ее тебе обратно.

А если ты делаешь просто "левый" коммит - то когда его заметят (а его заметят, ты же к нему комментарий пишешь, и он шлется в общую ленту) - то тебя на первый раз предупредят, а потом - депремируют.

> или ласково убедить ревьюера, что нужно быстренько проапрувить, потому что так надо.

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

После этого, тебе будет куда сложнее ласково договориться с ревьювером. Причем, с любым из.
Яков Сироткин
yakov_sirotkin at 2011-06-18 20:44 (UTC) (Link)
Люлей? Депримируют? А люди не пойдут после таких слов другую работу искать?

Тем более, что речь идёт о в общем-то санитарных нормах. По-моему, это не то, что должно насаждаться силой.
Gaperton
gaperton at 2011-06-18 20:51 (UTC) (Link)
> Люлей? Депримируют?

Ага. Если по человечески до людей не доходит - то будет именно так.

> А люди не пойдут после таких слов другую работу искать?

Ой, ой, как страшно.

Кому нужен сотрудник, который до такой степени принципиально не хочет следовать простейшему процессу, что готов поменять из-за этого работу, и своим примером подрывает дисциплину и боевой дух всей команды? Тебе нужен? Мне нет.

Пусть ищет, это будет его выбор. И заодно - наглядный урок его коллегам.

> Тем более, что речь идёт о в общем-то санитарных нормах.

Именно.

> По-моему, это не то, что должно насаждаться силой.

Неужели?
Яков Сироткин
yakov_sirotkin at 2011-06-18 21:07 (UTC) (Link)
У меня никогда не было полномочий кого-то увольнять, но у тех людей, которых я набирал, не было проблемы комментарий к коммиту написать.

При работе с теми, у кого такая проблема есть, я использую личный пример и доброе слово. И если формально "нет коммита без бага" у меня недавно получилось достаточно просто привить, то качество самих багов и к комментариев к коммитам уже тяжелее поднять до приличного уровня.
Alexey Fyodorov
23derevo at 2011-06-18 23:50 (UTC) (Link)
кому нужны такие люди?
Gaperton
gaperton at 2011-06-18 20:21 (UTC) (Link)
> Фатально помешать ревью может отсутствие двух вменяемых программистов в команде.

Нет, не может. Ревью делается по правилам, а не по мнениям. Ошибка ревью - либо человек багу нашел, либо несоответствие кодстандарту.

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

Конфликт ревью разрешает тимлид под свою ответственность.
Яков Сироткин
yakov_sirotkin at 2011-06-18 20:31 (UTC) (Link)
На некоторых проектах бывает только один программист. И никакого тимлида, который читает код. И даже если программиста всё-таки два, то это очень не просто может быть наладить код ревью из-за разных человеческих особенностей.
Gaperton
gaperton at 2011-06-18 20:38 (UTC) (Link)
> На некоторых проектах бывает только один программист.

Что у нас бывает с некоторыми проектами, когда этот один программист крепко болеет, увольняется, или ему не дай бог падает на голову кирпич?

И главное - что же нам с этим делать, а? Может быть, взять другого программиста, у которого тоже один проект, и попросить их проверять код друг друга?

> И никакого тимлида, который читает код.

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

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

Это, право слово, очень просто. Достаточно фамилию проверяющего в текст коммитмессаджа писать, и реально наказывать за вопиющие косяки обоих. Сразу всем станет очень просто.
Яков Сироткин
yakov_sirotkin at 2011-06-18 20:53 (UTC) (Link)
Если я ухожу с проекта, то за мной код правят другие программисты, мне даже вопросов не задают. Я правда стараюсь понятно писать.

Никакого тимлида - значит тимлида нет физически. При этом два программиста могут работать в совсем разных компаниях.
Gaperton
gaperton at 2011-06-18 20:24 (UTC) (Link)
> С JavaDoc всё довольно просто: not tested - not implemented

JavaDoc проверяется ревьювером, этого достаточно. Предполагается, что программист до этого протестировал код, прогнал регрессию (если есть), и написал своих тестов (если так принято) - тесты тоже проверяются.

Учитывая, что в JavaDoc пишется "контракт" функции или класса, а не реализация - никакой "дырки" в процессе я не вижу. Ее нет.
Яков Сироткин
yakov_sirotkin at 2011-06-18 20:47 (UTC) (Link)
А если контракт поменялся, а JavaDoc - нет?
Gaperton
gaperton at 2011-06-18 20:53 (UTC) (Link)
Ревьювер должен проверить. Он разделяет ответственность за коммит - забыл?

Впрочем, я не сторонник этих тулов, ИМХО они мало чего добавляют к коду. Потому и написал в соответствующем пункте - "для маньяков".

Но если есть желание обеспечить их актуальность - это можно сделать.
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 ключевыми людьми, которые тесно сотрудничают, это возможно
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, ленится заводить под него баг и ставит левый номер при коммите фикса.

С современными тулами несложно сделать так, что это будет в принципе невозможно.
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)
> Хук можно повесить, если у тебя есть доступ к человеку, который может администрировать сервер.

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

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

В целом - да, хватит. Но хук на пустой коммит-мессадж поставить не худо - чтобы рефлекс побороть. Кроме того - что может быть плохого в автоматической проверке, и исключении возможности ошибиться? Люди же ошибаются, не компьютеры. Нехорошо их за это наказывать.
Previous Entry  Next Entry