Может ли быть полезно создать приложение, начинающееся с графического интерфейса?

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

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

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

Может ли это быть осуществимой идеей для реального проекта? Может быть, мы могли бы добавить GDD (GUI Driven Development) к стабильной аббревиатуре ...

Создание быстрых прототипов GUI - хорошая идея, и я слышал, что она используется во многих проектах. Ранняя обратная связь действительно ценна. Тем не менее, это имеет свои опасности:

• для менеджеров / пользователей очень заманчиво использовать код прототипа и создавать на нем окончательное приложение, что может иметь очень плохие долгосрочные последствия (это фактически произошло в одном из проектов, над которым я работал, и это привело к «рабочий» продукт с несуществующей архитектурой и большой головной болью для нас)
• для обычного пользователя GUI - это приложение . Таким образом, как только они увидят красивый графический интерфейс, они склонны полагать, что большая часть реальной работы выполнена, поэтому они могут очень расстроиться из-за того, что «маленькая оставшаяся работа» тянется так долго: - /

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

Проблема, которую я вижу в этом, состоит в том, что цель, кажется, полностью отсталая.

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

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

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

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

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

Я думаю, что @ Петер прав, что хорошая идея - создавать прототипы GUI. Я хотел бы дополнить потенциальные ловушки предоставления пользователю удобного и обратного подхода, то есть сосредоточиться сначала на онтологиях, архитектуре и инфраструктуре, а затем на непосредственном опыте пользователей:

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

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

Для каждого craptastic опыта, изворотливый потока, плохо соотнесен информации, отсутствие очевидной функциональности, вещи, которые просто неправильно, экземпляры всякий раз , когда вы умоляли , чтобы спросить «какой именно гений придумал , что ?», Лежит что - то , что игнорировали, отрицается или раскрыл пользователя в качестве передового в усилиях по разработке.

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

Однако иногда графический интерфейс действительно является наиболее важной частью приложения. Иногда вы хотите посмотреть на данные новым и особым образом - и вы берете их оттуда, а затем разрабатываете модель. Например, CashCurve - это такое приложение, где точка находится в графическом интерфейсе, а сама модель данных - это стандартная скучная вещь, которую любой может смоделировать за несколько минут. (Отказ от ответственности: я не связан с CashCurve, просто очень довольный пользователь.)

Это актуально и для разработки веб-сервисов или других API-интерфейсов - только там это называется дизайном " сначала по контракту ".

Итак, что касается всего, нет правила относительно того, что спроектировать в первую очередь; иногда это модель, а иногда и графический интерфейс. Как правило, я бы предпочел «сначала спроектировать самую важную часть».

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

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

Вы должны понимать, что GUI - это окно в систему (т. Е. База данных, файловая система и т. Д.). В ситуации, когда требования проекта столь же расплывчаты, как куча слякоти, у вас не будет надежды на то, что вы сможете найти правильное решение, начав с бэкэнда. Почти всегда благий разработчик с благими намерениями разрабатывает набор API, который не имеет отношения к взаимодействию с пользователем.

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

И почему вы хотите выбросить прототип? Мы не имеем дело со стадионами, построенными из спичек. Просто превратить эту чертову вещь во что-то хорошее.

Совсем не плохо для меня, если человек, который смотрит на графический интерфейс, понимает, что это просто оболочка, и буквально кнопки и процессы не работают (добавьте новый NotImplementedException ();;)).

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

Что касается управления, нарисуйте им большую круговую диаграмму из 3 частей, пометьте их «M», «V» и «C». Дайте V около 20% и объясните остальную часть пирога "TBC";).

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

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

Если разработка GUI и других механизмов ввода и вывода может помочь, это проверка модели. Атрибуты, которые никогда не выводятся, могут не требоваться. (Могут быть причины для их сохранения, но они, вероятно, будут соответствовать требованиям аудита или регулирующего органа.)

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

Не забывайте, что вам может понадобиться настроить интерфейс после разработки. Я слышал сообщение о неудачной замене интерфейса проверки для пятиэтапного процесса проверки. Гораздо более простой интерфейс не давал пользователям соответствующего чувства безопасности и имел гораздо более низкий уровень выполнения. Слушайте Speed ​​Bumps: волшебный ингредиент в маркетинге .