| 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 |
Navigation
This page
Summary
2011.06.18 @ 23:06
Миф о документации, продолжение
yakov_sirotkin: (no subject) [+94]
| 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 |
yakov_sirotkin: (no subject) [+94] 
А вот документирование через JavaDoc - это откровенная лажа. Разве что JavaDoc будет писать ревьюер, а коммитер будет его проверять.
Удивительное рядом. Что же им помешает работать? :)
> Code review - практика понятная и в некоторых проектах безусловно необходимая. Но применение её не всегда целесообразно или даже не всегда возможно.
Без кодревью не будет соблюдаться кодстандарт, и код не будет понятным. Чтобы писать для человека, а не для машины, автор должен быть абсолютно уверен, что его код прочтет человек. Сейчас прочтет, не через год.
Побочным эффектом кодревью является то, что у нас как минимум двое людей будут в курсе любого куска кода. Так что эта практика целесообразна всегда.
Про "не все всегда возможно" - я изумлен. Пример, пожалуйста. Что же нам может помешать?
> А вот документирование через JavaDoc - это откровенная лажа. Разве что JavaDoc будет писать ревьюер, а коммитер будет его проверять.
Почему?
Следование стандартам кодирования у меня происходит практически в автоматически режиме, а над понятностью кода я всегда работаю по собственной инициативе. При этом я готов разобраться практически в произвольном коде на Java, примерно этим я и занимаюсь много лет. Да, иногда приходиться повозиться пару часиков, но это не от того, что ревью не было.
Фатально помешать ревью может отсутствие двух вменяемых программистов в команде. А ещё бывают административные проблемы вроде разных часовых поясов и сложностях в настройке VCS.
С JavaDoc всё довольно просто: not tested - not implemented. И на практике мы обычно имеем первую версию JavaDoc к десятой версии кода, что никакого смысла не имеет. А вот комментарии к коммитам и история изменений - вот это работает.
И тогда ревьювер, когда к нему придет настоящая задача, не увидит твоего коммита, когда к нему придет задача. После чего он завернет ее тебе обратно.
А если ты делаешь просто "левый" коммит - то когда его заметят (а его заметят, ты же к нему комментарий пишешь, и он шлется в общую ленту) - то тебя на первый раз предупредят, а потом - депремируют.
> или ласково убедить ревьюера, что нужно быстренько проапрувить, потому что так надо.
До первого случая, когда ревьювер вместе с тобой получат люлей. Оба получите выговор с занесением, или депремирование, о чем будут оповещены все сотрудники отдела.
После этого, тебе будет куда сложнее ласково договориться с ревьювером. Причем, с любым из.
Тем более, что речь идёт о в общем-то санитарных нормах. По-моему, это не то, что должно насаждаться силой.
Ага. Если по человечески до людей не доходит - то будет именно так.
> А люди не пойдут после таких слов другую работу искать?
Ой, ой, как страшно.
Кому нужен сотрудник, который до такой степени принципиально не хочет следовать простейшему процессу, что готов поменять из-за этого работу, и своим примером подрывает дисциплину и боевой дух всей команды? Тебе нужен? Мне нет.
Пусть ищет, это будет его выбор. И заодно - наглядный урок его коллегам.
> Тем более, что речь идёт о в общем-то санитарных нормах.
Именно.
> По-моему, это не то, что должно насаждаться силой.
Неужели?
Нет, не может. Ревью делается по правилам, а не по мнениям. Ошибка ревью - либо человек багу нашел, либо несоответствие кодстандарту.
Если есть претензии к читабельности - отправляем на ревью ко второму программисту, и смотрим, бьются ли их рекомендации между собой.
Конфликт ревью разрешает тимлид под свою ответственность.
JavaDoc проверяется ревьювером, этого достаточно. Предполагается, что программист до этого протестировал код, прогнал регрессию (если есть), и написал своих тестов (если так принято) - тесты тоже проверяются.
Учитывая, что в JavaDoc пишется "контракт" функции или класса, а не реализация - никакой "дырки" в процессе я не вижу. Ее нет.
И кроме того, тебе известно, что в случае с JIRA и SVN можно повесить не просто тупой пре-коммит-хук, а хук, который требует наличия указанной задачи в JIRA в определенном состоянии? :) Скажем, в статусе "В работе", и при этом она должна быть назначена именно на тебя?
А вот можно.
с хуками, связями почты-vcs-документами?
если да, сколько человек в команде и какой размер конторы (если в конторе больше одной программерской команды) ?
На практике периодически бывает, что программер находит косяк, который не нашли QA, ленится заводить под него баг и ставит левый номер при коммите фикса.
И нормальным людям хватает просто автоматической привязки коммитов к багам и почтовой рассылки.
Что-то случаев неприменимости в голову не приходит.
Приведи пример, плиз.