UML, разработка проекта

/s/класов/классов.

абсолютно нецелесообразно. нужно как можно быстрее бросаться в бой с шашкой наголо. документацию писать не обязательно.

// wbr

Это сарказм?

> Это сарказм?

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

// wbr

По заверениям маститых теоретиков (ну и практиков, Брукс тот же), собственно написание кода должно составить десятую часть времени разработки проекта. Остальное - это как раз проектирование. И тестирование-документирование.

Так что, если в проекте больше 3-х классов, такой подход будет определенно лучше :)

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

слово "OSS" можно выкинуть

Подумать никогда не помешает. Модель классов тем и хороша, что она моделирует будущую программу, помогает раньше увидеть ошибки дизайна.

Но зацикливаться на чистом проектировании, имхо, тоже не стоит, особенно если это опенсорсный проект, в котором не надо составлять начальству графики планов и затрат. Имхо, 20—30% общего времени это то время, которое даёт наибольшую пользу.

И, да, используйте практики XP, они позволяют сильно снизить затраты на исправление ошибок.

> И, да, используйте практики XP, они позволяют сильно снизить затраты на исправление ошибок.

факт! правда, реально рулит лишь после 2го SP а лучше с 3м, но это уже мелочи.

// wbr

>практики XP

это что за?

Экстримальное программирование

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

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

в противном случае UML будет не полезней QBasic'а. более того - он будет вреден, как и любой инструмент, применяемый вслепую

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

ключевое слово "иногда" ;)

>Экстримальное программирование

ч0рт, у меня понятие "XP" ассоциируется только с одной, весьма некрасивой, вещью =))

DDD почитай

Судя по постановке вопроса, ты вообе не понимаешь, зачем нужен UML. Собственно, в большинстве случаев он и не нужен, если конечно речь над проектом не работает 8 групп дебилов по 30 человек в каждой. Грэма лучше почитай, может, ума наберёшься.

> По заверениям маститых теоретиков (ну и практиков, Брукс тот же), собственно написание кода должно составить десятую часть времени разработки проекта.

Но в реальности все обстоит не так. :-)

> По заверениям маститых теоретиков (ну и практиков, Брукс тот же), собственно написание кода должно составить десятую часть времени разработки проекта.

По заверениям тех же маститых теоретиков (ну и практиков) после опробования теории на практике, не нужно пытаться написать 100% документации до написания первой строчки кода.