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

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

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

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

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

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

Как работать с лапшой — это уже совсем другая головная боль.