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

Question

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

Трещины на нем. Просто застрял.

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

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

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