Когда Вы разрабатываете GUI сначала, и бэкенд кодируют позже, или наоборот? [закрытый]

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

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

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

Иначе Вы заканчиваете с чем-то вроде этого чудовище.:-)

Btw, если необходимо создать прототип UI для тестирования удобства пользования, удостоверяются, что это создается с чем-то, что не может быть интегрировано в производственном коде. Например, создайте прототип в Flash, если Вы пишете, что C++/C#/Java кодирует.

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

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

Конечно, всегда помогает, ли это для клиента, и они дают Вам зрительный ряд перед рукой :) Тот путь, пока Вы соответствуете зрительному ряду, можно все еще перейти к городу с не визуальная связанная забава бэкэнда.

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

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

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

Однако в некотором смысле можно сказать, что мы делаем первый код бэкенда и затем UI, с тех пор при высказывании, что этап должен предложить UI для тестирования функциональности, это не означает, что это - заключительный UI, который мы поставим. Обычно около конца, когда почти вся внутренняя функциональность готова и протестирована, мы часто делаем перестройку UI. Это вызвано тем, что UI для тестирования должен быть готов в течение этапа, но это не может всегда быть симпатично или UI, который мы наконец поставим. Часто UI замедлял бы целый проект (нашими приложениями обычно является очень интенсивный UI, так как нам не нравится производить приложения со скучным стандартным UIs, мы хотим прекрасный взгляд UIs, которые заставляют Вас сказать, "Ничего себе, что потрясающие взгляды!"), таким образом мы часто должны реализовывать промежуточный UI, чтобы иметь UI, готовый в течение этапа и для тестирования. Чаще, чем меньше мы затем обновляем UI как заключительный шаг перед выпуском. Поскольку у нас уже есть UI для всего, это не грандиозное предприятие, если мы не можем обновить некоторые части его (из-за времени, ограничивает), в конце концов, существует UI, это просто не красиво, но это работает и протестированное. Таким образом, мы попытаемся обновить как можно больше в течение данного периода времени, зная все время, что, если мы должны остановить процесс модернизации завтра, у нас есть полностью рабочее, shipable приложение. Модернизация UI просто полирует, IOW, который хорошо иметь, но Вы могли также выпустить без него.

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

GUI сначала при разработке быстрых прототипов.

Существует два вопроса попросить определять это: a), какой является самым важным b), какой является самым твердым.

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

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