С чего вы начинаете проектирование большой системы?[закрыто]

https://stackoverflow.com/questions/15690

08-06-2019
|

Вопрос

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

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

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

Решение

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

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

Другие советы

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

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

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

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

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

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

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

Сначала прочтите спецификацию как историю (бегло просмотрев ее).Не останавливайтесь на каждом требовании, чтобы проанализировать его прямо здесь и тогда.Это позволит вам получить общую картину системы без излишних деталей.На этом этапе вы должны приступить к определению основных функциональных компонентов системы.Начните записывать их (если хотите, используйте инструмент mindmap).
Затем возьмите каждый компонент и начните его разбирать (и привязывать каждую деталь к требованиям в документе спецификации).Делайте это для всех компонентов, пока не выполните все требования.
Теперь вам следует начать изучать взаимосвязи между компонентами и наличие повторений функций в различных компонентах (которые затем вы можете использовать для создания служебных компонентов или чего-то подобного).Примерно сейчас у вас в голове должна быть хорошая подробная карта ваших требований.
ТЕПЕРЬ вам следует подумать о проектировании базы данных, ER-диаграмм, проектировании классов, DFDS, развертывании и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

Пусть все будет просто!

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow