Каков рабочий процесс, который вы используете для разработки программного обеспечения, которое вы собираетесь написать?

Ответ 1

Когда вы работаете над личными, средними проектами, что вы указываете перед началом кода?

Я указываю спецификацию :

• Я опасался, что это может быть слишком легко, если я только начал кодирование (это "как" ), чтобы забыть "почему" и "что" я хотел бы закодировать (для "довольно сложного" программного обеспечения в течение нескольких месяцев или лет, которые могут потребоваться для разработки).
• Я также хотел более или менее понять "сферу" того, что я буду развивать: для оценки примерно (на порядок):
  • Насколько велика будет
  • Можно ли закончить его
  • Стоит ли начинать
  • Какое подмножество может быть разработано в первую очередь

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

Как?

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

Я сделал и не указывал архитектуру программного обеспечения заранее:

• Я начинаю разработку с базовой архитектуры (несколько небольших компонентов), а затем добавляю код; и, когда я добавляю код, если какой-либо компонент становится слишком большим и сложным, я разделяю его на несколько меньших компонентов... это эволюционный процесс... как он говорит в Systemantics, КОМПЛЕКСНАЯ СИСТЕМА, РАБОТАЮЩАЯ, НЕЗАКОННО НАЙДЕНО ЭВОЛЮЦИЯ ИЗ ПРОСТОЙ СИСТЕМЫ, КОТОРЫЕ РАБОТАЛИ.
• Я не документирую архитектуру; или, скорее, единственной документацией архитектуры является сам код: например, способ, с помощью которого исходный код упорядочен в исходные каталоги, пространства имен и библиотеки DLL.

У меня есть теоретическое обоснование архитектуры, как сейчас, но я не документировал эти причины:

• Я единственный разработчик
• Фактическая архитектура документируется кодом
• Причины для архитектуры в моей голове и [re] обнаруживаются такими вещами, как соглашения об именах в исходном коде и зависимостями различных компонентов

Если (только если) я не был единственным разработчиком, я мог бы подумать, что стоит документировать архитектуру и ее обоснование.

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

Что касается тестирования, я немного код, а затем проверяю его; или написать тест, а затем закодировать функциональность, которая пройдет этот тест. Я не делаю "интеграцию большого взрыва", т.е. Месяцы написания без какого-либо тестирования.

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

Ответ 2

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

Вам не нужно получать его на 100% в первый раз. На самом деле, если вы стремитесь к этому, вы, вероятно, никогда не закончите. Реальность заключается в том, что вы не будете полностью понимать дизайн до тех пор, пока вы не построите систему один раз.

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

Ответ 3

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

С наилучшими пожеланиями.

Ответ 4

Я нахожу чистый лист бумаги, и луч является лучшей отправной точкой:

• набросать несколько грубых диаграмм
• запишите некоторые идеи/заметки.
• напишите некоторый псевдокод
• продумайте основные варианты использования
• думать о потенциальных проблемах

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

Ответ 5

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

Ответ 6

• Нарисуйте экраны
• Нарисуйте отношения данных (rdbms или in-memory)
• Начать кодирование
• Скорее, Промыть, Повторить (или в программе-Lingo GOTO 1)

Я бы начал с минимальной реализации и добавил больше возможностей на каждой итерации.