Жизненный цикл разработки для создания приложения?

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

• Прежде всего, хорошо разберитесь в своих требованиях. Если ваши пользователи сами не уверены, чего именно они хотят, то подход @Michael Herold, заключающийся в том, чтобы начать с прототипа пользовательского интерфейса, определенно является хорошим предложением. Вы также можете использовать какой-либо итеративный подход, например Agile/Scrum.
• Затем определите тип высокоуровневой архитектуры, которая должна быть достаточно гибкой для достижения вашей цели. Будет ли ваше приложение клиент-серверным? Нужна ли будет база данных? Несколько потоков? Несколько процессов? Если любой из них был «да», как эти потоки/процессы будут взаимодействовать. Составьте блок-схему, ответив на приведенные выше вопросы.
• Если ваш проект среднего размера или больше, вы также можете нарисовать некоторые диаграммы классов или UML-типа. Подумайте о том, какие классы вам понадобятся и их взаимосвязь.
• Если вы хотите попробовать подход Разработка через тестирование, возможно, сейчас самое подходящее время требования в модульные тесты.
• Когда у вас есть хорошее представление о том, ЧТО вы пытаетесь решить, и КАК вы собираетесь подойти к решению этой проблемы, вы, наконец, можете приступить к программированию решения.

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

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

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

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

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

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

Взломайте с этим. Просто застрять.

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

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

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