Где вы начинаете свой дизайн - код, пользовательский интерфейс, рабочий процесс или что-то еще?

Question

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

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

Спасибо

Answer 1

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

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

Answer 2

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

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

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

Answer 3

Почему бы не начать приемочные испытания?

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

С этой целью я теперь очень заинтересован в тестировании фреймворков, которые пытаются собрать требования тестируемым способом, например:

• easyb
• concordian
• ..

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

Answer 4

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

Answer 5

Мой общий рабочий процесс имеет тенденцию идти по следующим направлениям:

1. Требования к улавливанию (определить входные и ожидаемые результаты).
2. Разработать что-то, что могло бы работать (основная структура программы / идеи потока данных, чтобы объяснить, как перейти от входных данных к выходным данным в требованиях).
3. Прототипируйте любые алгоритмы и проверяйте их на реальных данных (обычно в Excel и / или Python, чтобы доказать, что мы можем получить от ввода к выводу).
4. Реализовать решение (закодировать результат в C ++ /. Net).
5. Тест до смерти / исправление любых обнаруженных ошибок (проверка по ранним моделям и любым другим тестам, которые кажутся важными).
6. Устранить любые серьезные узкие места или проблемы с юзабилити.

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

Answer 6

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

Бумажное прототипирование , где это имеет смысл и повторение дизайна во время моей работы.

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

Answer 7

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

Затем напишите запросы и формы, фактический HTML, а также JS и CSS, которые делают его таким привлекательным (или нет, как это обычно бывает с моими «дизайнами»).

Итак, в модели MVC, я думаю, сначала M, а затем V? У меня нет большого опыта работы с MVC.

Это относительно естественный способ?

Answer 8

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

Answer 9

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

Answer 10

Я начинаю с дизайна из требований.Если требования требуют пользовательского интерфейса, я бы хотел разработать его как подзадачу, а вычислительный движок (или как вы его называете) как другую подзадачу;это своего рода MVC с четким разделением между M и V, где C обеспечивает связь между ними.Таким образом, разработка C становится еще одной подзадачей.

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

И я слышал, что Test Driven Design является популярным движением в наши дни, поэтому тесты могут стать еще одной отправной точкой длявам рассмотреть.