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

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

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

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

Ответов (10)

Решение

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

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

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

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

Будь проще!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Draw it up on plain paper, thinking of where to section off the code. Remeber not to mix logic with GUI code (common error). This way you will be set to extend your applications reach in the future to servlets and/or applets or whatever platform comes along. Section in layers so that you can respond to large changes faster without rebuilding everything. Layers should not see any other layers than their closest neighbouring layers.

Begin with true core functionallity. All that time consuming fluff (that will make your project 4 weeks late), wont matter much to the wast majority of users. It can be added later once you are sure you can deliver on time.

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