Что планировать, прежде чем начинать разработку проекта? [закрыто]

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

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

Чтобы лучше понять, о чем я прошу, как мне

а) разделить проект на составляющие,

б) Планировать их взаимодействие, например, должен ли я делать диаграммы классов, писать модульные тесты и т. д.?

Есть идеи?

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

• Начните с целей проекта. Цели обязательно самые туманные, но они помогают вам сосредоточиться на том, что клиент или пользователь намеревается сделать с программным обеспечением. В конце концов, вы хотите достичь этих целей - даже если это означает отказ от некоторых действительно интересных функций.
• Затем я начинаю разбивать приложение на поддомены. Вероятно, есть сотня разных способов сделать это, поэтому мы начинаем с целей проекта. Мы хотим разбить приложение на несколько связанных подсистем, поддерживающих эти цели. Это помогает нам сосредоточиться на следующей задаче.
• Определите, как и когда подсистемы должны взаимодействовать. Мы не обрабатываем детали, а просто информацию высокого уровня, чтобы убедиться, что у нас есть интегрированная система подсистем. Вам нужно общее представление об этом, чтобы вы могли конкретизировать детали, которые поддерживают общие цели проекта.
• Предоставляйте только сведения о подсистеме, над которой я сейчас работаю (аналогично вашей текущей стратегии). Я уже знаю, как эта подсистема должна взаимодействовать с другими подсистемами, но мне может понадобиться разработать несколько альтернатив, чтобы это имело смысл. Каждая подсистема разделена интерфейсом, поэтому я могу максимально корректировать реализацию, не нарушая систему в целом.
• Посмотрите, как все реализовано в моей текущей подсистеме по сравнению с тем, как оно реализовано в других подсистемах. Каждый непоследовательный подход - это то, что пользователь должен изучить. Это нормально, если мы говорим о совершенно новой концепции. Ради удобства использования мы не хотим 5 различных способов удаления информации, которая присутствует просто потому, что мы были ленивы. Повторное использование одних и тех же элементов пользовательского интерфейса - это самый быстрый способ сделать приложение более интуитивно понятным. Изучить три понятия гораздо проще, чем выучить 20.

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

Я думаю, что было бы лучше, если бы я прошел спецификации

Правильно. Хорошая идея.

спланировал, как система будет работать, прежде чем я ее закодировал.

Хорошо. Сделай больше этого.

каковы основные компоненты,

Отлично.

как они собираются взаимодействовать,

Верный.

Я просто не уверен, что именно я должен планировать.

Как вы можете быть не уверены, когда уже перечислили кучу вещей? Если это то, что вас волнует, почему бы просто не сосредоточиться на этих вещах?

Читайте о 4 + 1 представлении модели: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Читайте о структуре Zachman: http://en.wikipedia.org/wiki/Zachman_Framework

Это то, что вам нужно планировать.

как я должен а) Разделить проект на составляющие,

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

Если вы сомневаетесь, прочитайте чертежи J2EE для идей.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

как я должен б) Планировать их взаимодействие, например, должен ли я делать диаграммы классов, писать модульные тесты и т. д.?

Да. Хорошие идеи, все.

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

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

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

Разрабатывайте варианты тестирования / использования и проверяйте их у клиента. Если требование не подлежит проверке, выбросьте его.

Разработайте дизайн и убедитесь, что все части функционируют правильно, что теоретически будет делать то, что вам нужно.

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

Вы определенно хотите иметь какой-то дизайн, прежде чем начать кодирование.

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

Затем я создаю 1 функцию сверху вниз, чтобы вы что-то реализовали полностью.

Тогда иди оттуда.

Все

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