Как начать разработку большой системы? [закрыто]

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

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

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

19.08.2008 04:26:33
10 ОТВЕТОВ
РЕШЕНИЕ

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

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

11
23.06.2011 19:31:17
+1 Позвольте JPA обработать слой данных, сконцентрируйтесь на реализации java, которую ваш редактор может
klonq 6.04.2012 09:32:08

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

2
19.08.2008 04:31:27

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

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

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

1
19.08.2008 04:39:11

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

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

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

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

  • ТЕПЕРЬ, вы должны подумать о разработке базы данных, ER-диаграммах, Class Design, DFD, развертывании и т. Д.

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

2
19.08.2008 06:03:57

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

3
19.08.2008 06:08:31

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

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

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

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

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

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

5
19.08.2008 10:34:35

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

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

Будь проще!

0
19.08.2008 10:48:18

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

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

1
19.08.2008 11:21:50

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

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

в книге « Растущее объектно-ориентированное программное обеспечение, ориентированное на тесты» .

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

0
19.08.2008 21:31:46

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

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

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

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

1
22.10.2008 15:09:21