?

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:


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 14:01 (UTC) (Link)
Это ревьювится за минуту, не вижу причины в этом случае не делать ревью прямо с экрана, и не писать фамилию ревьювера.

А вот дырку в процессе, через которую можно шаловливые ручонки в код запустить - вижу.
malica_dee
malica_dee at 2011-06-19 14:12 (UTC) (Link)
Собственно зависит от уровня внутренней дисциплины в команде. Если она достаточно высокая, то никто в эту дырку и не полезет.
Gaperton
gaperton at 2011-06-19 14:19 (UTC) (Link)
"Уровень дисциплины" - это не данность, которая дана свыше. Уровень дисциплины зависит от руководителя.
malica_dee
malica_dee at 2011-06-19 14:18 (UTC) (Link)
Кстати, если Bug ID хочется непременно сделать обязательным, чтобы избежать "прицепов" можно создать отдельную всегда открытую задачу имени неземной красоты кода и граммар-чистоты и ставить ее id в такие коммиты.
Gaperton
gaperton at 2011-06-19 14:33 (UTC) (Link)
Это бессмысленно. Наведение красоты не модет являться целью, и соответственно, задачей. Нечего статистику этой ерундой портить.
malica_dee
malica_dee at 2011-06-19 20:15 (UTC) (Link)
Смысл исключительно в том, чтобы комит, который содержит косметические изменения был отдельным, и содежал комментарий, который говорит, что это косметическое изменение, коммит, который содержит исправление орфографическую ошибку, был отдельным и содержал информацию о том, что здесь была исправлена орфографическая ошибка и ничего больше. А не так, что меняли алогоритм согласно багу №хххх и исправили орфографические ошибки (в другом модуле) и все это одним комитом, и в каменте (который, как мы помним видно, из среды разработки) видно и про алгоритм, и про орфографию в обоих модулях, где были справления (а высота и ширина окна чсх ограничены).

Наведение красоты - это повышение читабельности и удобства сопровождения. Не такая уж бессмысленная вещь, ИМХО. Впрочем, если статистика дороже реального положения дел, то, конечно, не стоит этим заниматься.
Gaperton
gaperton at 2011-06-19 20:26 (UTC) (Link)
Статистика по задачам как раз должна отражать реальное положение дел. А положение реальное тогда, когда постановка задачи одинаково понятна как программисту, так и пользователю.

Поэтому - не надо заводить левых задач в трекере.

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

К примеру - знаешь, чем чреваты "косметические" на взгляд некоторых программистов переименования процедур и полей в T-SQL? У нас - из-за таких "безобидных" на первый взгляд изменений, твоих коллег могут поднять ночью телефонным звонком, чтобы они исправили проблемы в загрузке сделок до следующего утра.
malica_dee
malica_dee at 2011-06-19 21:28 (UTC) (Link)
Ну у нас и нету левых, просто есть возможность баг id поставить n/a. Чтобы не писать "прицепов".

Слушай, ну давай не путать мягкое с теплым, я не думаю, что то, что переименование процедур и полей в T-SQL может вызывать такие последствия такая уж тайна для тех, кто на этом проекте работает не вчера. Новичков всегда надо отслеживать очень плотно, но всегда есть тот порог, с которого проверки становятся просто непроизводительной тратой рабочего времени.
Gaperton
gaperton at 2011-06-19 21:34 (UTC) (Link)
> Ну у нас и нету левых, просто есть возможность баг id поставить n/a. Чтобы не писать "прицепов".

Ага. И обойти при этом code review. "Потому, что оно мешает работать".

Знаем, слышали.
malica_dee
malica_dee at 2011-06-19 21:59 (UTC) (Link)
Кстати, n/a нифига не значит, что не будет кодревью. В случае, когда изменили строку сообщения в ресурсах его может не быть, не или если закоммитили временные иконки, которые нужны пока дизигнер не сделает на их место нормальные. Что-то в этом духе. В остальных случаях кодревью таки будет - никто себе не враг.
Gaperton
gaperton at 2011-06-19 21:43 (UTC) (Link)
> Слушай, ну давай не путать мягкое с теплым, я не думаю, что то, что переименование процедур и полей в T-SQL может вызывать такие последствия такая уж тайна для тех, кто на этом проекте работает не вчера.

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

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

Простая мысль, вроде, нет? А как долго я ее объясняю :) Представь, что это происходит на работе. Ну вот как тут без штрафов и взысканий, а? :) Не доходит же по другому.
Gaperton
gaperton at 2011-06-19 10:10 (UTC) (Link)
Если будет знать, что разделяет ответственность за коммит - то так легко не закроет.

А после того, как кто-нибудь "из той же породы" за аналогичное раздолбайство получит взыскание - будет трижды думать, прежде чем закрывать глаза.
malica_dee
malica_dee at 2011-06-19 13:54 (UTC) (Link)
В таком случае периодически, особенно ближе к дедлайну, будут возникать следующие явления: если взыскания будут достаточно жесткими, то людям проще будет закрывать глаза на мелкие косяки и делать вид, что они их не заметили, если взыскания будут скорее символическими, то они будут плевать на взыскания.
Gaperton
gaperton at 2011-06-19 13:59 (UTC) (Link)
Не будет. На практике до взысканий добираются только клинические идиоты, это большая редкость.
malica_dee
malica_dee at 2011-06-19 14:14 (UTC) (Link)
Насколько я поняла, у вас просто пользуются методом "прицепа", когда с изменениями в одном месте, коммитятся изменения в другом. Тут уж действительно надо быть клиническим идиотом, чтобы заработать взыскание.
Gaperton
gaperton at 2011-06-19 14:22 (UTC) (Link)
Взыскание будет за любое изменения в продакшне, не прошедшие ревью.

В том числе, если это будет "косметическое" переименование переменной. В T-SQL такие прикольные последствия от переименований бывают - обхохочешься.
malica_dee
malica_dee at 2011-06-19 20:34 (UTC) (Link)
(пожимает плечами)
В нормальной команде при изменениях, в которых потенциально можно накосячить, никто без проверки и без нормального ревью (которое не просто посмотрел в экран, а понял, что написано), комитить не будет, ибо все люди, и любой может проглядеть чего-то или ошибиться. На кой нужен лишний баг?

А если команда непрофессиональна или в гробу и в белых тапочках видала этот проект и эту контору, то ревьюера напишут, но никому от этого легче не будет.
Gaperton
gaperton at 2011-06-19 21:07 (UTC) (Link)
Все это не отменят простого факта, что за проявление клинического идиотизма, халатности, и пренебрежением техникой безопасности, руководитель должнен наложить на сотрудника взыскание, или, может быть (о ужас!) его уволить.

Соврешенно независимо от того, насколько "профессиональной" считает себя команда, и понравится ли это сотруднику.
malica_dee
malica_dee at 2011-06-19 21:14 (UTC) (Link)
Ну это как бы банальные вещи. Просто я не очень понимаю, зачем вообще брать на работу клинических идиотов и затем над ними неустанно бдить. Это исключительно утомительное и неблагодарное занятие.
Gaperton
gaperton at 2011-06-19 21:26 (UTC) (Link)
Неужели вам известен волшебный способ 100% достоверно определять на собеседовании тех, кто в последствии будет игнорировать простые санитарные правила, вроде написания комментариев к коммитам? :) Методику в студию, пожалуйста.

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

Это как бэ до такой степени банальные и элементарные вещи, что я таки поражаюсь способности их не понимать.
malica_dee
malica_dee at 2011-06-19 21:36 (UTC) (Link)
Не-а, зато я знаю, неволшебный способ выявления безответственных персонажей в течении испытательного срока, но почему-то мне кажется, что не только я его знаю.
Previous Entry  Next Entry