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

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

СА>А что касается написания части функциональности — есть две модели: гибкая и негибкая. В первой мы не будем писать дополнительный код сверх части функционала (тоже неплохо, а вдруг потом заказчик обанкротится, а так — мы не затратим лишних усилий ), а во второй — запланируем сразу. По моим ощущениям (даже и не расчитывайте на объективность мнения ) — временные затраты в первом случае (плюс рефакторинг и доведение до полного функционала) и во втором случае (полная архитектура, часть функциональность, доведение до полной) будут примерно одинаковы. А вот риск в первом случае вроде как меньше. Хотя он тоже растёт с ростом величины проекта.

И что? Как это связано с документированием или не документированием модели (с использованием или без использования UML)?

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

СА>>>Опять же, из функциональных требований, которые сами по себе не требуют UML.
AF>> Да, как уже многократно говорилось, обойтись можно. И в зависимости от ситуации это будет разумно использовать UML или не использовать.
СА>Ну вот. А я предлагаю структурировать код, чтобы и архитектура (не функциональные требования) им же просто и описывалась. Чтобы этот не очень удобный инструмент (UML то есть) и вовсе не был нужен.
И помещать туда тонны текста, картинок, диаграмм?

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

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