?

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 2009.05.03 at 16:01

Comments:


Gaperton
gaperton at 2009-05-03 21:41 (UTC) (Link)
Выглядит, как поток сознания какой-то. Крэшдамп. Слава богу, в UTF-8, а не в шестнадцатеричном виде. Вы документацию свою так же оформляете?
n0way
n0way at 2009-05-03 22:46 (UTC) (Link)
человек резонно возражает. а вам, похоже, нечего ответить.
Gaperton
gaperton at 2009-05-03 23:42 (UTC) (Link)
А что, вы правда считаете это сколько-нибудь серьезным возражением? Эту "резонную" песню в разных обработках все неоднократно слышали от разных людей, и читали в умных книгах. Оно конечно понятно, что если бы волшебным образом была понятная документация, которая всегда актуальна, написана кратко, и по существу, да еще появлялась и обновлялась бы бесплатно - то тогда да. Никто бы никогда код не читал, все б такую замечательную документацию только и смотрели.

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

Все об этом говорят, что хорошо бы так, да. Но на практике этого неуловимого Джо почему-то никто не видел. Это не наводит ни на какие мысли? Покажите мне хотя бы один долгоживущий КОММЕРЧЕСКИ УСПЕШНЫЙ проект, в котором есть актуальная и подробная проектная документация по коду, которая не "уплыла" бы ПРИ РАЗВИТИИ И ПОДДЕРЖКЕ, и поддерживается в актуальном состоянии. Нет таких проектов.

Исключения составляют случаи, когда документация генерируется из кода автоматически, а это как раз то, о чем я говорю. А если вам кажется, что не смотря ни на что есть - то я ни в жисть вам не поверю, пока не увижу описания процесса контроля качества, поддерживающего ее в актуальном состоянии в случае РАЗВИТИЯ И ПОДДЕРЖКИ. А после того, как будет приведено описание процесса (в чем я лично сомневаюсь), а не пионерское бла-бла-бла с биением себя пяткой в грудь (что мы пока наблюдаем), можно будет сначала
1) половить процесс на "дырки", которые приведут к расползанию документации с кодом. Выяснится, что дырок этих будет дофига, и что качество и актуальность документации на самом деле ничем не гарантирована. А потом
2) посчитать его оверхэд и спросить окружающих, считают ли они такие затраты оправданными. Если процесс будет хоть что-то гарантировать, затраты будут огромными, и зависеть примерно квадратично от размера кода. Ответ окружающих вас удивит - в здравом уме на это пойдет только идиот. Впрочем, подождем описания процесса, зачем делать за пионеров работу. Держу пари, будет ссылка на общий стандарт, если вообще будет, потому что нихрена на самом деле он не знает.

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

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

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

К тому же, всем, ВСЕМ, у кого есть мало-мальский реальный опыт, известно, как составляется проектная документация в данных случаях, воспринимаемая исполнителем как бесполезное, никому не нужное зло. Она на практике даже в этих случаях outdated, и не соответствует действительности, ибо стоимость процедур контроля качества для РЕАЛЬНОГО обеспечения ее актуальности ужасающая. Ее соответствие нерентабельно даже проверять в большинстве заказных проектов, не говоря о том, что вести разработку строго по ней, так как чистый "ватерфол" в природе попросту невозможен.

Зная это, и то, что заказчик также не произведет проверки, в реальности в большинстве случаев вполне сознательно производится тонна документации, ПРИМЕРНО, в общих чертах напоминающей результат. Она на практике читается заказчиком один раз, если вообще читается.

Исключения из этого настолько редки, что из них глупо делать правило, и в любом случае не имеют значения, так как заказчик при развитии системы документацию все равно выбросит, вместо того, чтобы поддерживать в актуальном состоянии.
Gaperton
gaperton at 2009-05-03 23:45 (UTC) (Link)
"Что вовсе не означает, что они есть."
->
"Что вовсе не означает, что их нет".
metaclass
metaclass at 2009-05-04 06:56 (UTC) (Link)
Возражает может и обоснованно, но прочитать невозможно.
Если так писать документацию - то лучше бы ее вообще не было.
Макс Лапшин
levgem at 2009-06-09 07:05 (UTC) (Link)
отнюдь. Я попытался прочитать и сломался на третьей строчке.
Always crashing in the same car
debose at 2009-06-14 15:43 (UTC) (Link)
+1
Previous Entry  Next Entry