Миф о документации, продолжение

[gaperton]

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

Давайте посмотрим, почему же люди пишут документы тогда, когда они их действительно пишут, а не рассуждают о том, как бы хорошо было, если бы они были, и как плохо,

Comments

[rlabs]

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

[malica_dee]

А еще можно ввести дресс-код и штрафы за опоздания.

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

[malica_dee]

Да, собственно, ставить номер бага и ревьюера и внятный камент к коммиту само по себе полезно (и при работе эта самая польза вполне ощущается, особенно в случае распределенной команды, которая еще и в разных часовых поясах), но, в то же время, из попытки заставить разработчиков заводить отдельный баг и писать телегу на каждый чих, вроде исправили в сообщении "Connection timeput" на "Connection timeout" ничего хорошего не получится.

[gaperton]

Пишешь в коммит-сообщении, "присасываясь" к содержательному коммиту:
- исправлены орфографические ошибки.

Это не критично, так как орфография не меняет требований, трассировка для них не нужна.

[malica_dee]

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

[gaperton]

"Формально - это тот самый случай "левого номера бага", часто бывает, что орфографические ошибки и тому подобная хрень просто попадается на глаза, и к багу отношения не имеет. Т. е. чисто формально - это именно то, за что предлагается наказывать и депремировать."

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

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

[malica_dee]

>>Если подходить к делу формально - то можно абсолютно любую инструкцию или процесс свести на дерьмо.
Ну, основная мысль была - только не надо перегибать.

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

[gaperton]

>Есть немного.
Да лано скромничать. Вещи надо называть своими именами.

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

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

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

И менеджмент молодец, когда он это делает. Он делает свою работу, реагируя на упреждение ситуации. Сами потом спасибо скажете, и новичков бедете заставлять.

[malica_dee]

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

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

[gaperton]

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

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

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

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

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

Что предпочитаете?

[malica_dee]

Я предпочитаю качественное обучение.

[gaperton]

То есть, выработка условного рефлекса на соблюдение элементарных правил, как-то не писать мимо унитаза, мыть руки, и не делать в код левых коммитов без описаний - это, по вашему, предмет "качественного обучения"? :) Ну-ну :).

Давайте пойдем дальше, и отменим законы и суды. :) Предпочтем этому "качественное обучение" - должно хватить ведь. :)

[dr_cha0s]

Ну, детям вполне удаётся привить привычку мыть руки и не писать мимо унитаза, для этого действительно нужны санкции: Обоссал унитаз? - Взял тряпку и вытер. Или просто прививание привычки - домой пришёл - в первую очередь помыл руки. И что интересно не обучаются этому только дети с патологиями мозга (ну или очень долго обучаются). Собственно если у юного девелопера не привиты эти привычки - привить, а у опытного они, как правило, есть. Ну или прививаются тем же образом.

[gaperton]

Да, именно так. С небольшой поправкой - программисты не дети. И, бывает, что дорожат своими "плохими" привычками.