Есть ли логическая прогрессия в разработке приложений?

Question

В настоящее время я работаю над приложением в WPF / C # для личного использования. Я не «классически обученный» программист. Просто любитель, который любит писать в свободное время. Есть ли принятый подход к прогрессу разработки приложений? И. Е .; Заставьте его работать, добавьте отказоустойчивость, создайте графический интерфейс, затем оптимизируйте производительность. Или, может быть, я должен сначала спроектировать весь графический интерфейс? В основном я собираюсь начать новый проект в ближайшее время и хотел бы иметь какой-то контрольный список "каждая программа нуждается в этом".

Answer 1

На самом деле нет списка «каждой программе нужен этот», потому что нет абсолютно ничего, что нужно каждой программе.

Хотя некоторые советы: не «заставляйте это работать», затем «добавляйте отказоустойчивость». Защитное программирование и учет ошибок должны быть непрерывной частью разработки. Гораздо проще (и обычно более эффективно), если вы учитываете ошибки и неожиданный ввод , когда вы пишете кусок кода, а не после того, как это сделано.

Что касается того, стоит ли сначала создавать графический интерфейс, ответьте на этот вопрос: является ли самый важный аспект программы в том, что он делает или , как он выглядит ? Это серьезный вопрос, который, честно говоря, может варьироваться от приложения к приложению (хотя обычно важнее первый).

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

Если графический интерфейс действительно важнее, сначала создайте его и смоделируйте объекты данных и бизнес-логику вокруг графического интерфейса.

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

Answer 2

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

Как правило, для коммерческой разработки сначала создается прототип (для WPF отлично подходит SketchFlow с Blend). Обычно это требуется, поскольку вам чаще всего необходимо «продать» концепцию клиенту, руководству и т. Д.

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

Answer 3

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

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

Затем заполните детали.

Answer 4

В прошлом у меня работала следующая (высокоуровневая) последовательность:

1. Понимать и записывать требования (кто, что и когда) - варианты использования, список функций, блок-схемы, требования к уровню обслуживания - все, что вам подходит (хотя я неравнодушен к сценариям использования).
2. Понимать и записывать дизайн (как) - диаграммы классов, диаграммы последовательности, конструкции экранов, спецификации API - начинать с высокого уровня и выполнять детализацию (может начать разработку до завершения детализации)
3. Реализация - начните с API / заглушек и модульных тестов, затем заполните код, обновите модульные тесты и выполняйте модульные тесты по ходу работы.
4. Проверка системы - проверить работоспособность компонентов и устранить неисправности. Не забудьте о тестировании производительности (убедитесь, что вы выполнили требования к уровню обслуживания, начиная с шага 1).
5. Пакет, разверните и наслаждайтесь.

Answer 5

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

Answer 6

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

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

Answer 7

Жизненный цикл разработки сильно варьируется. Дисперсия обусловлена ​​размером проекта, размером команды, сроками и т. Д ...

Для небольших хобби-проектов я обычно придерживаюсь этого подхода:

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

2. План: обычно документ, в котором я обрисовываю основные этапы развития, такие как «полное подтверждение концепции», «базовый интерфейс», «ведение журнала системы», «успешные операции CRUD»

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

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