Как начать проектировать большую систему?

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

Вы много знаете об ООП? Если это так, изучите Spring и Hibernate, чтобы ваша реализация была чистой и ортогональный. Если у вас есть это, вы должны найти TDD хорошим способом сохранить ваш дизайн компактным и экономичным, тем более что у вас есть «автоматическое тестирование».

ОБНОВИТЬ: Глядя на первую серию ответов, я не мог не согласиться. В частности, в области Java вы должны найти множество наставников / ресурсов по разработке вашего приложения с объектами не ориентированный на базу данных подход. Проектирование базы данных обычно является первым шагом для людей из Microsoft (что я делаю ежедневно, но участвую в программе восстановления, например, Alt.Net). Если вы сосредоточитесь на том, что вам нужно доставить клиенту, и позволите ORM выяснить, как сохранить ваши объекты, ваш дизайн должен стать лучше.

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

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

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

Главное - уметь абстрагироваться от сложности системы, чтобы вы не увязли в ней, как только начнете.

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

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

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

• СЕЙЧАС вам следует подумать о разработке базы данных, диаграмм ER, дизайна классов, DFD, развертывания и т. д.

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

Я также не согласен с тем, чтобы начать с базы данных. БД - это просто артефакт сохранения ваших бизнес-объектов. Я не знаю эквивалента в Java, но .Net имеет замечательные инструменты, такие как SubSonic, которые позволяют дизайну вашей БД оставаться гибким, когда вы повторяете дизайн своих бизнес-объектов. Я бы сказал, что в первую очередь (даже до принятия решения о том, какие технологии внедрять) сосредоточьтесь на процессе и определите свои существительные и глаголы ... а затем отталкивайтесь от этих абстракций. Эй, это действительно работает в «реальном мире», как вас учило ООП 101!

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

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

Итак, мой совет:

1. Если вы не уверены, что сможете взяться за такую ​​большую работу в одиночку, не делайте этого. Сообщите своим работодателям и попросите их найти или нанять для вас кого-нибудь, с кем вы сможете помочь. Если нужно добавить людей в проект, то это нужно делать в самом начале, а не после того, как что-то пойдет не так.

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

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

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

По крайней мере, это была моя главная ошибка при проектировании.

Будь проще!

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

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

Я нашел очень проницательные идеи о запуске нового большого проекта, основанного на

• общие передовые практики
• Разработка через тестирование
• и прагматичный подход

в книге Развитие объектно-ориентированного программного обеспечения на основе тестов.

Он все еще находится в разработке, но первые 3 главы могут быть тем, что вы ищете, и ИМХО стоит прочитать.

Предлагаю подумать, как это приложение будет использоваться. Как с ним будут работать будущие пользователи? Я уверен, что вы знаете, по крайней мере, кое-что о том, что должно обрабатывать это приложение, но мой первый совет - «подумайте о пользователе и о том, что ему или ей нужно».

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

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

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