?

Log in

No account? Create an account
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.11 at 01:02

Comments:


Дмитрий Арсентьев
dmarsentev at 2011-06-11 00:25 (UTC) (Link)

не уместилось

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

Т.е. всякие приёмо-сдаточные процедуры - они
естественным образом генерируют качественную документацию.
Alexey Fyodorov
23derevo at 2011-06-11 01:22 (UTC) (Link)

Re: не уместилось

+1 за приёмо-сдаточные процедуры. И +1 за документацию пользователя.

Если контора нанимает долбоёба, который пришет непонятный код - это её проблемы. Если менеджер не может отследить странное поведение такого разрабочика - это снова проблемы конторы. Если в конторе нету code review и непонятный никому говнокод попадает в репозиторий - это снова проблемы конторы.

Если происходит всё вместе - это не контора, а говно. Слать её нахуй.

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


Енотинька
raccoon at 2011-06-11 20:42 (UTC) (Link)

Re: не уместилось

Да, мы с моим бывшим PMом (Иван Поваляев, до недавнего времени - Sitronics Telecom Solutions) пытались пропатчить мозг этим подходом добрым людям на Software People. Добрые люди жевали попкорн, дивились на Дарта Вейдера, гулявшего в коридоре, но нам не внимали.
Есть старый метод написания требований к системе: создать прототип пользовательской документации. А потом дополнить приемо-сдаточными процедурами.
По-моему, как раз agile-подход на сходном принципе построен.
Alexey Fyodorov
23derevo at 2011-06-11 21:00 (UTC) (Link)

Re: не уместилось

А сходным с чем, если не секрет? Не нанимать вредителей? Смотреть, чтобы в репозиторий попадал более-менее качественный код?

Про Agile ничего говорить не буду, у меня с ним сложные отношения. Забавно, но его всегда противопоставляют с ГОСТом. И вот тут (внимание) - фокус:
http://gaperton.livejournal.com/49867.html
Енотинька
raccoon at 2011-06-11 21:16 (UTC) (Link)

Re: не уместилось

Сходным с чем: базируется на разработке "каркаса" документации и будущего "каркаса" приемо-сдаточных процедур. Причем оба этих процесса происходят практически одновременно, и отвечает за это барахло аналитик.
А про вредителей - там же люди постоянно работают в тесном контакте друг с другом. Любое вредительство (IMHO) возможно только в режиме относительной изоляции отдельных членов коллектива. Когда все работают короткими итерациями, и результаты каждой итерации видны всем членам команды (+ есть возможность задать уточняющие вопросы на каждодневной 15-минутной встрече), вредители волшебным образом пропадают сами собой.
Alexey Fyodorov
23derevo at 2011-06-11 21:23 (UTC) (Link)

Re: не уместилось

Вы про scrum? Там много вариантов планирования как входа и проведения демо как выхода. И степерь формализации может быть любой. Как договорятся заказчик и исполнитель.

Если будет много бумажных процедур - потеряется сам дух скрама.
Яков Сироткин
yakov_sirotkin at 2011-06-11 03:50 (UTC) (Link)
Приёмо-сдаточные процедуры генерируют бред сивой кобылы, написанный для формального прикрытия задницы. А потом на это ставиться печать - задокументировано.

А по факту, если я открываю код и вижу там типичную помойку, то я не буду читать документацию, а буду разбираться в этом коде.
Alexey Fyodorov
23derevo at 2011-06-11 21:10 (UTC) (Link)
Это всё так, но только с одной стороны. Со стороны девелопера.

Ты, видимо, говоришь о внутреннем джавадоке к очередной J2EE-поделке, то да, я совершенно с тобой согласен. Нахуй надо. Читаем код. С точки зрения программиста всё обстоит именно так.

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

Ты вот недавно выступал перед дамой, рассказывающей о юзкейсах. Как ты сам-то думаешь - они нужны?

Моё мнение - юзкейсы нужны! Это документация в чистом виде!
Они же - описание функционала!
И они же - тестовые планы!
Они же - юзергад, вид сбоку.
Они же - повод заплатить или не заплатить денег исполнителю!
aamonster
aamonster at 2011-06-11 05:43 (UTC) (Link)

Re: не уместилось

Ага, насчёт приёмо-сдаточных процедур - да. Пусть даже они будут совсем уж внутренними: написал модуль - отошли товарищу, чтоб он мог поддерживать.
Alexey Fyodorov
23derevo at 2011-06-11 21:15 (UTC) (Link)

Re: не уместилось

Представьте себе такую ситуацию. Заказчик попросил исполнителя сделать некую функцию за 10000 баксов. Исполнитель её сделал и хочет получить деньги. Но заказчику не понравилось, и деньги он платить не хочет.

Что Вы будете делать с этим кейсом без приёмо-сдаточных процедур?
aamonster
aamonster at 2011-06-12 03:51 (UTC) (Link)

Re: не уместилось

Это отдельный и более понятный людям случай.
Previous Entry  Next Entry