My<cod/>.net
Как вы начинаете проектировать большую систему?
Мне уже говорили, что я буду единственным разработчиком большой новой системы. Помимо всего прочего, я буду разрабатывать UI и схему базы данных.
Я уверен, что получу некоторые указания, но мне хотелось бы иметь возможность сбить их с ног. Что я могу сделать за это время, чтобы подготовиться, и что мне нужно будет иметь в виду, когда я сяду за свой компьютер со спецификацией?
Несколько вещей, которые нужно иметь в виду: я студент колледжа на моей первой настоящей работе по программированию. Я буду использовать Java. У нас уже есть SCM настроенных с автоматизированным тестированием, etc...so инструментов не проблема.
Много ли вы знаете о OOP? Если это так, посмотрите на Spring и Hibernate, чтобы сохранить вашу реализацию чистой и ортогональной . Если вы получите это, вы должны найти TDD хороший способ сохранить ваш дизайн компактным и бережливым, особенно с учетом того, что у вас есть "automated testing" и работает.
UPDATE: Глядя на первый ряд ответов, я не мог не согласиться больше. В частности, в пространстве Java вы должны найти много наставников/ресурсов для разработки вашего приложения с объектами, а не ориентированного на базу данных подхода . Проектирование базы данных обычно является первым шагом для людей Microsoft (что я делаю ежедневно, но нахожусь в программе восстановления, э-э, Alt.Net). Если вы продолжаете фокусироваться на том, что вам нужно доставить клиенту, и позволяете своему ORM выяснить, как сохранить ваши объекты, ваш дизайн должен быть лучше.
Это очень похоже на мою первую работу. Сразу после окончания университета меня попросили разработать базу данных и уровень бизнес-логики, в то время как другие люди будут заботиться о UI. Тем временем босс заглядывал мне через плечо, не желая отпускать то, что раньше было его ребенком, а теперь стало моим, и тыкал в него пальцем. Три года спустя разработчики бежали из компании, и мы все еще были в X месяцах от реальной продажи чего-либо.
Большая ошибка заключалась в том, что он был слишком честолюбив. Если это ваша первая работа, вы будете делать ошибки, и вам нужно будет изменить то, как все работает еще долго после того, как вы их написали. У нас были всевозможные функции, которые делали систему более сложной, чем она должна была быть, как на уровне базы данных, так и в API, который она представляла другим разработчикам. В конце концов, все это было слишком сложно, чтобы поддерживать все сразу, и просто умерло.
Так что мой совет:
Если вы не уверены, что возьмете на себя такую большую работу в одиночку, не делайте этого. Расскажите своим работодателям, и пусть они найдут или наймут кого-нибудь для вас, чтобы работать с тем, кто может вам помочь. Если людей нужно добавить в проект, то это должно быть сделано ближе к началу, а не после того, как что-то пойдет не так.
Подумайте очень тщательно о том, для чего предназначен этот продукт, и сведите его к самому простому набору требований, которые вы можете придумать. Если люди, дающие вам спецификацию, не являются техническими специалистами, попробуйте посмотреть мимо того, что они написали, на то, что действительно будет работать и приносить деньги. Поговорите с клиентами и продавцами и поймите рынок.
Нет ничего постыдного в том, чтобы признать свою неправоту. Если окажется, что вся система нуждается в переписывании, потому что вы допустили какую-то ошибку в своей первой версии, то лучше признать это как можно скорее, чтобы вы могли добраться до нее. Соответственно, не пытайтесь создать архитектуру, которая может предвидеть все возможные непредвиденные обстоятельства в вашей первой версии, потому что вы не знаете, что такое каждое непредвиденное обстоятельство, и просто ошибетесь. Напишите один раз с прицелом на то, чтобы выбросить и начать снова - возможно, Вам не придется, первая версия может быть прекрасной, но признайте это, если вы это сделаете.
Я также не согласен с тем, чтобы начать с базы данных. DB-это просто артефакт того, как сохраняются ваши бизнес-объекты. Я не знаю эквивалента в Java, но у .Net есть звездные инструменты, такие как SubSonic , которые позволяют вашему дизайну DB оставаться текучим, когда вы повторяете свой дизайн бизнес-объектов. Я бы сказал, что в первую очередь (даже до принятия решения о том, какие технологии внедрять) сосредоточьтесь на процессе и определите свои существительные и глаголы ... затем стройте из этих абстракций. Эй, это действительно работает в "реальном мире", как вас учил OOP 101!
Главное-это умение абстрагироваться от сложности системы, чтобы не увязнуть в ней сразу же, как только вы начнете.
Сначала прочитайте спецификацию как рассказ (просматривая ее). Не останавливайтесь на каждом требовании, чтобы проанализировать его прямо там и тогда. Это позволит вам получить общее представление о системе без излишних подробностей. На этом этапе вы начнете идентифицировать основные функциональные компоненты системы. Начните откладывать их (используйте инструмент mindmap, если хотите).
Затем возьмите каждый компонент и начните его взрывать (и связывать каждую деталь с требованиями в документе спецификации). Сделайте это для всех компонентов, пока вы не покрыли все требования.
Теперь вы должны начать смотреть на отношения между компонентами, а также на то, есть ли повторения функций или функций в различных компонентах (которые затем можно вытащить, чтобы создать служебные компоненты или что-то подобное). Примерно сейчас у вас в голове была бы хорошая подробная карта ваших требований.
NOW, вы должны думать о проектировании базы данных, ER диаграмм, дизайна классов, DFDs, deployment и т. д.
Проблема с выполнением последнего шага в первую очередь заключается в том, что вы можете увязнуть в сложности своей системы, не получив на самом деле полного понимания в первую очередь.
Я делаю это наоборот. Я нахожу, что, делая это database-schema-first, система застревает в data-driven-design,который трудно абстрагировать от настойчивости. Мы стараемся сначала разработать модели доменов, а затем основывать на них схему базы данных.
А затем идет проектирование инфраструктуры: команда должна определиться с конвенциями о том, как структурировать программу в первую очередь. А затем мы работаем вместе, чтобы сначала согласовать дизайн для общей функциональности системы (например, вещи, которые всем нужны, такие как постоянство, ведение журнала и т. д.). Это становится основой системы.
Мы все работаем над этим вместе, прежде чем разделить rest функций между собой.
Это был мой опыт, что Java приложений (.NET также), которые считают базу данных последней, с высокой вероятностью будут плохо работать при размещении в корпоративной среде. Вам нужно действительно думать о своей аудитории. Вы не сказали, Было ли это веб-приложение или нет. В любом случае инфраструктура, которую вы внедряете, важна при рассмотрении того, как вы обрабатываете свои данные.
Независимо от того, какую методологию вы рассматриваете, как вы получаете и сохраняете свои данные, и это влияние на производительность должно быть одним из ваших приоритетов #1.
Я бы предложил подумать о том, как это приложение будет использоваться. Как будут работать с ним будущие пользователи? Я уверен, что вы знаете, по крайней мере, несколько вещей о том, что это приложение должно обрабатывать, но мой первый совет-"think of the user and what he or she needs".
Нарисуйте его на обычной бумаге, думая о том, где можно отсечь код. Помните, что не следует смешивать логику с кодом GUI (распространенная ошибка). Таким образом, вы будете настроены на расширение охвата ваших приложений в будущем до сервлетов и/или апплетов или любой другой платформы. Сечение в слоях, чтобы вы могли быстрее реагировать на большие изменения, не перестраивая все. Слои не должны видеть никаких других слоев, кроме ближайших соседних слоев.
Начните с истинной основной функциональности. Весь этот отнимающий много времени пух (который сделает ваш проект на 4 недели позже), не будет иметь большого значения для подавляющего большинства пользователей. Он может быть добавлен позже, как только вы будете уверены, что можете доставить вовремя.
Кстати. Даже если это не имеет никакого отношения к дизайну, я просто хочу сказать, что вы не будете доставлять вовремя. Сделайте реалистичную оценку потребления времени, а затем удвоите его :-) я предполагаю, что вы не будете одиноки в этом проекте и что люди будут приходить и уходить по мере развития проекта. Возможно, вам придется обучать людей в середине проекта, люди уезжают в отпуск / нуждаются в операции и т. д.
Разделите большую систему на более мелкие части. И не думайте, что это так сложно, потому что обычно это не так. думая слишком сложно, это просто разрушает ваши мысли и в конечном итоге дизайн. В какой-то момент Вы просто понимаете, что могли бы сделать то же самое проще, а затем перепроектировать его.
По крайней мере, это была моя главная ошибка в проектировании.
Пусть все будет просто!
Я нашел очень проницательные идеи о начале нового большого проекта, основанного на
- общей передовой практикой
- Разработка На Основе Тестов
- и прагматичный подход
в книге растет объектно-ориентированное программное обеспечение, Ориентируемое на тесты .
Он все еще находится в стадии разработки, но первые 3 Главы могут быть тем, что вы ищете и IMHO стоит прочитать.