Важность объектной модели в управляемом предметом дизайне

Question

Наша команда - новичок в разработке, ориентированной на домен. У нас есть новый проект, который только что перешел с этапа проектирования на этап кодирования. На этапе проектирования некоторые члены команды создавали модели проектирования UML в Visio, а другие только начали программировать. Кроме того, из-за давления сборочных выпусков многие наши модели быстро устаревают.

Важно ли поддерживать объектные модели в актуальном состоянии? Важно ли иметь их для всех / большинства подсистем?

Answer 1

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

Answer 2

Я думаю, что ответ "это зависит", нет?

Если проект небольшой, меняется быстрыми темпами и т. Д., Окупаемость моделей, вероятно, довольно плохая, и в конце концов все, что имеет значение, - это рабочий код.

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

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

Answer 3

Любая документация ниже уровня User Story напрямую связана с деталями реализации и, следовательно, с изменчивыми фактами (почему и как). Поэтому (как, модели) не следует поддерживать вручную, а генерировать их, когда это необходимо, ради улучшения коммуникации с разработчиками.

Документация великолепна, когда она поддерживается постоянно. Если вы не можете этого гарантировать, перейдите к документации по исходному коду (и сохраняйте ее при изменении кода) и генерируйте столько UML из своего кода, сколько вам нужно, , когда вам это нужно .

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

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

Answer 4

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

Но вы должны знать, что у вас не будет материала (кроме самого кода), чтобы показать, скажем, новичку в команде, и это будет стоить некоторое время, чтобы научить нового парня.

Так что это вопрос выбора наиболее эффективного. Если сохранение устаревшей модели делает команду быстрее, не обновляйте модели. Если обновление модели несколько улучшит разработку, вам следует это сделать (как бы скучно это не было)