Какие важные артефакты дизайна вы производите?

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

Для общего серверного «корпоративного приложения» я бы хотел, чтобы минимум был примерно таким:

• Подробный документ функционального дизайна (также известный как спецификация). Как правило, что-то вроде спецификации примера WhatsTimeIsIt Джоэла, хотя, возможно, с некоторым UML диаграммы вариантов использования.
• Технический проект программного обеспечения. Не обязательно подробное для 100% охвата системы, но подробное во всех ключевых областях и содержащее все проектные решения. Будучи немного помешанным на UML, было бы неплохо увидеть множество изображений вдоль линий диаграмм пакетов, диаграмм компонентов, диаграмм классов ключевых функций и, возможно, некоторых диаграмм последовательности, добавленных для хорошей меры.
• Документ проектирования инфраструктуры. Вероятно, со схемой развертывания UML для концептуального проектирования и, возможно, сетевой диаграммой для чего-то более физического.

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

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

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

Рабочий код... и рисунки на доске.

:P

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

Я делаю снимки досок и сохраняю файлы JPEG в системе управления версиями. Это одни из моих лучших дизайнерских документов!

В нашей модели (которая довольно специфична для приложений бизнес-процессов) артефакты проектирования включают:

• модель данных предметной области с комментариями по каждому объекту и атрибуту
• файл свойств, в котором перечислены все триггеры изменения и создания для каждой сущности, вычисляемые атрибуты, валидаторы и другая бизнес-логика
• набор определений экрана (модель представления)

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

Но тот факт, что они выполняют двойную функцию, имеет большое значение, потому что они по определению актуальны и постоянно синхронизируются с кодом.

Это не проектный документ как таковой, но наши модульные тесты служат двойной цели: «описывают», как должен функционировать тестируемый код. Самое приятное в этом то, что они никогда не устаревают, поскольку наши модульные тесты должны пройти, чтобы наша сборка была успешной.

Я не думаю, что что-то может заменить старую добрую спецификацию дизайна по следующим причинам:

• Он служит средством информирования других о том, как вы будете создавать приложение.
• Это позволяет вам выбрасывать идеи из головы, чтобы не беспокоиться об одновременном отслеживании миллионов вещей.
• Если вам нужно приостановить проект и вернуться к нему позже, вы не начнете свой мыслительный процесс заново.

Мне нравится видеть различную информацию в спецификации дизайна:

• Общее объяснение вашего подхода к решению поставленной задачи
• Как вы будете контролировать свое приложение?
• Каковы проблемы безопасности и как они решаются?
• Блок-схемы / диаграммы последовательности
• Открытые вопросы
• Известные ограничения

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