?

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:


Alexey Fyodorov
23derevo at 2011-06-19 09:35 (UTC) (Link)
тут Вы абсолютно правы. Я неаккуратно сформулировал. Я имел в виду, что нужно спокойно разъяснить, что это и зачем нужно.

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

Есть ещё вариант - написать плагин, который превращает работу с коммитом в формочку. В полях - номер бага и дропдаун с ревьюером.
malica_dee
malica_dee at 2011-06-19 10:00 (UTC) (Link)
Да, собственно, ставить номер бага и ревьюера и внятный камент к коммиту само по себе полезно (и при работе эта самая польза вполне ощущается, особенно в случае распределенной команды, которая еще и в разных часовых поясах), но, в то же время, из попытки заставить разработчиков заводить отдельный баг и писать телегу на каждый чих, вроде исправили в сообщении "Connection timeput" на "Connection timeout" ничего хорошего не получится.
Gaperton
gaperton at 2011-06-19 10:19 (UTC) (Link)
Пишешь в коммит-сообщении, "присасываясь" к содержательному коммиту:
- исправлены орфографические ошибки.

Это не критично, так как орфография не меняет требований, трассировка для них не нужна.
malica_dee
malica_dee at 2011-06-19 10:33 (UTC) (Link)
Формально - это тот самый случай "левого номера бага", часто бывает, что орфографические ошибки и тому подобная хрень просто попадается на глаза, и к багу отношения не имеет. Т. е. чисто формально - это именно то, за что предлагается наказывать и депремировать.
Программисты не идиоты и себе не враги, и понимают, что в их собственных интересах заводить баги и оставлять внятные каменты при коммитах, когда речь идет о чем-то серьезном, но не стоит перегибать палку, добиваясь безукоризненного соблюдения правил коммитов.
Gaperton
gaperton at 2011-06-19 10:38 (UTC) (Link)
"Формально - это тот самый случай "левого номера бага", часто бывает, что орфографические ошибки и тому подобная хрень просто попадается на глаза, и к багу отношения не имеет. Т. е. чисто формально - это именно то, за что предлагается наказывать и депремировать."

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

"Программисты не идиоты и себе не враги,"
Ага. Только, как свойственно всем людям, терпеть не могут дисциплины.
malica_dee
malica_dee at 2011-06-19 14:08 (UTC) (Link)
>>Если подходить к делу формально - то можно абсолютно любую инструкцию или процесс свести на дерьмо.
Ну, основная мысль была - только не надо перегибать.

>>Ага. Только, как свойственно всем людям, терпеть не могут дисциплины.
Есть немного. Но что характерно, на те вещи, которые реально нужны, все же народ забивает намного реже, кроме случаев клинического раздолбайства.
Gaperton
gaperton at 2011-06-19 16:32 (UTC) (Link)
>Есть немного.
Да лано скромничать. Вещи надо называть своими именами.

>Но что характерно, на те вещи, которые реально нужны, все же народ забивает намного реже, кроме случаев клинического раздолбайства.

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

Менеджмент делает в данной ситуации простую вещь. Вводя санкции, он переводит "может быть когда-нибудь" в "точно, здесь и сейчас". Что неиллюзорно поднимает мотивацию.

И менеджмент молодец, когда он это делает. Он делает свою работу, реагируя на упреждение ситуации. Сами потом спасибо скажете, и новичков бедете заставлять.
malica_dee
malica_dee at 2011-06-19 21:10 (UTC) (Link)
Когда сильно не первый год работаешь над долгоииграющими проектами, отлично понимаешь, что это "может быть когда-нибудь" в какой-то ммомент сыграет обязательно.

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

А когда не сильно не первый год первый год работаешь - тоже понимаешь?

Или руководителю надо выдержать сильно не первый год, завалить парочку проектов, и дождаться, когда все все поймут?

> А вообще, общефилософское: разработчиков можно "строить, заставлять и тыкать носом" - это действительно очень просто, но является ли это оптимальной политикой?

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

Что предпочитаете?
malica_dee
malica_dee at 2011-06-20 06:00 (UTC) (Link)
Я предпочитаю качественное обучение.
Gaperton
gaperton at 2011-06-20 10:27 (UTC) (Link)
То есть, выработка условного рефлекса на соблюдение элементарных правил, как-то не писать мимо унитаза, мыть руки, и не делать в код левых коммитов без описаний - это, по вашему, предмет "качественного обучения"? :) Ну-ну :).

Давайте пойдем дальше, и отменим законы и суды. :) Предпочтем этому "качественное обучение" - должно хватить ведь. :)
dr.chaos
dr_cha0s at 2011-06-22 07:53 (UTC) (Link)
Ну, детям вполне удаётся привить привычку мыть руки и не писать мимо унитаза, для этого действительно нужны санкции: Обоссал унитаз? - Взял тряпку и вытер. Или просто прививание привычки - домой пришёл - в первую очередь помыл руки. И что интересно не обучаются этому только дети с патологиями мозга (ну или очень долго обучаются). Собственно если у юного девелопера не привиты эти привычки - привить, а у опытного они, как правило, есть. Ну или прививаются тем же образом.
Gaperton
gaperton at 2011-06-22 08:45 (UTC) (Link)
Да, именно так. С небольшой поправкой - программисты не дети. И, бывает, что дорожат своими "плохими" привычками.
dr.chaos
dr_cha0s at 2011-06-22 08:55 (UTC) (Link)
Не только программисты — все. Например, пожилого человека очень трудно приучить соблюдать чистоту в большим объёмах чем он привык. Тебя за авторитета не считают, а эффект от пиздюлин непродолжителен, да и снижается со временем, как, впрочем, и от положительных поощрений, а только отвлёкся на минуту сразу "саботаж".
Но с разработчиками и прочими наёмными работниками с мотивацией всё несколько яснее и ести возможность избавить коллектив.
Gaperton
gaperton at 2011-06-22 20:42 (UTC) (Link)
Да, все абсолютно точно. Все так.
Gaperton
gaperton at 2011-06-22 20:46 (UTC) (Link)
Именно поэтому уповать надо не только на пиздюлины, но и на социальный фактор.

1) Пиздюлины - двоим (атор + проверяющий), и позаботиться, чтоб все знали за что.
2) Рассылка сообщений о коммитах. Вообще - там весь пункт правильно описан, он в значительной степени избавляет от раздачи пиздюлин.
ndochp at 2011-06-19 18:18 (UTC) (Link)
А с третьей стороны случай - в свежем январском релизе одной 1Сины на форме разместили поле ввода и очепятались в его названии. (январские релизы в виду обострений у законодателей в сочетании с отторможенностью у них же это мрак и тихий ужас - когда ряд форм утверждается через неделю после начала сдачи этих форм, то релизы с обновлениями идут единым потоком, кажется не задерживаясь особо в отделе тестирования)
Я не знаю чем руководствовался народ при дальнейшем написании, то ли автомат все генерил, то ли переименовать реквизит это немерянная бюрократическая волоките, но это название встречалось в десятке мест внутри модуля формы в разных функциях, и в одной процедуре в глобальном модуле в блоке кейсов, куда эта форма уезжала в виде параметра.
Вот и поправь орфографию не глядя.
Сама 1С это зачистила релиза через два.
Alexey Fyodorov
23derevo at 2011-06-19 10:25 (UTC) (Link)
если не писать коммент на каждый чих, то через пару лет в проекте будет полный и безоговорочный пиздец!
Previous Entry  Next Entry