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

Question

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

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

Несколько вещей, о которых следует помнить: я студент колледжа в своей первой реальной работе по программированию. Я буду использовать Java. У нас уже есть SCM с автоматическим тестированием и т. Д., Поэтому инструменты не являются проблемой.

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

• сейчас, вы должны думать о создании базы данных, диаграммы ER, Class Design, DFDS, развертывание и т.д.

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

Answer 5

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

Answer 6

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

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

Так что мой совет:

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

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

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

Answer 7

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

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

Держите это просто!

Answer 8

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

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

Answer 9

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

• общих передовой практики
• Test Driven Development
• и прагматичный подход

в книге Growing Object-Oriented Software, Guided by Tests.

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

Answer 10

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

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

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

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