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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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