Процесс разработки программного обеспечения - архитектура

Question

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

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

Мой вопрос:

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

2. Для чего я понимаю, архитектура более полезна для большого проекта или системы. Хотя для небольшого проекта, возможно, архитектура не очень помогает. Итак, действительно ли нужна архитектура для проекта запуска, или мы можем реализовать базовый проект и иметь архитектуру позже, когда она вырастет?

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

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

Благодаря

Answer 1

В идеальном мире, было бы лучше, чтобы полностью спроектировать систему до начала строительства, но на практике это не всегда происходит.

Однако, в отношении вашего первого пункта, если система хорошо спроектирована, во время строительства будет потребоваться гораздо меньше изменений, и, как правило, ускорить внесение изменений во время разработки по сравнению со сборкой.

Конечно, все это зависит от размера проекта и количества людей, участвующих в разработке и принятии решений.

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

Конечно, это все мое мнение, от разработки веб-проектов для себя и в небольших командах.

Смотрите также Software Design vs. Software Architecture

Answer 2

Прежде всего, вы должны знать, что есть 2 цель сделать дизайн/схема архитектуры системы.

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

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

Ваша цель для небольшой компании или запуска для второго пункта. Как заявил Крис, легче найти подводные камни и изменить бизнес на этапе проектирования, а не на этапе кода. Я рекомендую делать только дизайн высокого уровня, а не низкоуровневый, такой как диаграмма классов. Вы можете найти рассуждения у моего другого answer here.