Здравствуйте, Сомов Александр, Вы писали:

AF>> Прямо как классики марксизма-ленинизма. Коммунизм должен быть построен. Есть большая разница между "должен" и что есть на самом деле. Вы и картинки в код поместите?
СА>Вообще говоря, следование какой-нибудь методологии лучше, чем не следование ничему вообще. А если картинки очень нужны будут (ни разу не встретилось таких) — да, в код помещу.
И после этого какова будет читабельность этого кода?
Не говоря о том, что как вы сумеете это сделать чисто технически?

AF>>И что? Как это связано с документированием или не документированием модели (с использованием или без использования UML)?
СА>Очень просто связано. Документирование модели вовсе не всегда нужно (с использованием или без использования UML).
О том, что документирование нужно далеко не всегда (как и UML) я написал уже минимум раз двадцать. Юрий Иванович по-моему тоже...

AF>> Почему то вы забыли о том, что бывают весьма интересные и оригинальные решения — от алгоритмов до архитектуры — ценность которых гораздо выше, чем того (часто кривого) кода, который их реализует?
СА>Ценность работающего кода состоит только в том, какие результаты он приносит от использования. А framework'остроительство ради "интересных и оригинальных решений" мне уже надоело. Если вы хотите, чтобы команда высококвалифицированных разработчиков два года занималась чепухой, заставьте их писать какой-нибудь красивый framework.
А фреймворки то тут причём???! Это уже какие то эротические фантазии...
Я писал о разных ситуациях. На вскидку: я видел вариант базы данных оптимизированной под очень высокую производительность и большие объёмы данных. Её разработка заняла довольно много времени и там было очень много оригинальных и не тривиальных решений как на уровне архитектуры, так и на уровне алгоритмов. А вот качество кода по разным причинам — хромало. Несколько позже она была переписана с нуля по модели и достигла совсем другого уровня качества и производительности.

AF>> И помещать туда тонны текста, картинок, диаграмм?
СА>Ничего не помещать, так как эти тонны не нужны.
А что нужно?

AF>> Поймите, часто бывает ситуация, когда есть проект, который тянется годами, когда изначально не ясно, что делать, а делать что-то надо.
СА>Это нездоровая ситуация.
Это реальная ситуация.

AF>>И в этой ситуации — система пишется, притом, естественно, весьма далеко от идеала, но это всё хозяйство сертифицируется и отправляется клиентам — ибо бизнес не ждёт. И вот проходит 2-3-4 года за которые наконец-то становится ясно, что и главное как нужно делать.
СА>Можно достичь такого понимания и за 2-3 месяца, причём без всяких картинок. Достаточно дать пользователям первую версию программы вообще с минимумом функциональности (и возможно даже вы не угадаете и вообще эта функциональность не будет нужна, но вам об этом скажут).
Куда мостится дорога благими намерениями — вы и сами знаете. Нельзя этого было сделать. Неужели если вы думаете, что люди, которые вели проект не додумались до столь тривиальной мысли? Но сделать этого было не возможно — по целому ряду причин.

AF>>Если всё это время строилась модель — на уровне бизнес-процессов, на уровне UML моделей, на уровне толковых описаний, то это даёт возможность переписать систему грамотно — с использованием более современных технологий. Так вот эта модель — квинтэссенция опыта — стоит гораздо дороже, чем весь написанный код.
СА>А в моём случае вы будете не только модель иметь, но и работающий по ней код. Причём гораздо быстрее.
Код — да. Модель — нет. Потому, что на написание качественной документации времени нужно одинакого. И то, что вы её засовываете в код вам совершенно не поможет. Скорее наоборот.

AF>> В чём здесь роль UML? Да в том, что опыт накапливается годами, времени писать романы нет. А вот накидать диаграммку с пояснениями возможно. Люди приходят и уходят. И через 2-3 года найти концы почти не реально. И если не использовать UML (или любую другую общепринятую систему обозначений) — то у кого потом спрашивать, что имел в виду автор диаграммки 3 года назад?
СА>У нас в проекте после 5 лет развития концы находятся очень просто, в том числе и потому, что мы не дорожим вещами даже 2-хлетней давности. Опыт накапливается, а они теряют ценность. В результате мы имеем не 5-летней давности картинки, а годовой давности (что гораздо лучше по качеству) код.
В вашей ситуации это может быть возможно. А в других — нет. Потом, естественно, картинки в модели все эти пять лет постоянно уточнялись — и это были вовсе не исходные наброски пятилетней давности.

AF>> Придумать систему обозначений, да ещё её задокументировать (по сути разработать стандарт) — эта работа может быть сопоставима по объёму с самим проектом. И ради чего? Ради фанатичного нежелания учить UML? Или ради высокомерного самомнения — что всё сделаем лучше?
СА>Ничего кроме некоторого набора общих терминов, да описания функциональности, достаточно неформального, не требуется. Для пятилетнего проекта с размером команды разработчиков в 25 человек это описание по объёму и содержимому вполне таково, что пишется одним человеком за выходные. А большего просто не требуется.
Святая наивность. Вы ГОСТы хоть раз в жизни видели? Вы уверены что описание системы, которая должна строго соответстовать ГОСТ'ам могут за выходные написать даже двадцать человек?

СА>>>Мы же не говорим о том, как быть с уже написанной лапшой, мы говорим, как писать код так, чтобы он не требовал (или требовал минимум) подобных дополнений.
AF>> Ещё раз. Часто код сразу пишется для мусорной корзины — потому, что его просто не возможно сразу писать хорошо. И его единственное предназначение — выработать модель, которая будет нужна в дальнейшем.
СА>Правильно. А что — я не о том же? И разве ваши картинки точно также не попадут в мусорную корзину. Или их-то вы сразу хорошо пишите?
Попадут конечно. Сиграв свою роль. Так же как и мы сами...