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

Question

У меня есть идея, которую я хочу превратить в приложение (у меня есть опыт программирования на C / C ++, C # и Java, поэтому я буду разрабатывать в QT Creator для кросс-компиляции). Итак, теперь я спрашиваю вас, старшие разработчики, что мне делать дальше? Я знаю, что все хорошие программы исходят из идеи. Тогда что мне делать? Прототип пользовательского интерфейса? Затем разработать код? Есть ли как кружок разработки приложения?
Я НЕ ОЗНАЧАЮ, ЧТОБЫ ЭТОТ ВОПРОС БЫЛ СУБЪЕКТИВНЫМ ИЛИ АРГУМЕНТАЦИОННЫМ

Answer 1

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

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

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

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

Answer 2

Тресни с этим. Просто застрять.

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

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

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

Answer 3

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

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

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

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