Как начать обсуждение архитектуры программного обеспечения?

Ответ 1

• Узнайте, кто в вашей команде.
• Узнайте, что им интересно на уровне системного анализа.
• Узнайте, кто знает людей в более широкой корпорации.
• Узнайте, что используется в более широкой корпорации.
• Узнайте, что раньше люди использовали в вашем конкретном подразделении.
• Возьмите всю приведенную выше информацию и используйте ее, чтобы начать говорить о Сейчас, Скоро, и В конечном счете. Обратите особое внимание на то, как вы связываетесь с внешним миром как с точки зрения вне подразделения, так и вне корпорации.

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

Ответ 2

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

Лидерство. Великая книга Фреда Брукса, "Мифический человек-месяц" , рассказывает о том, что у технического лидера есть лидер в области техники. Лично мне нравится больше сотрудничества, чем я вижу с врачами, поэтому позвольте лечить хирургическую бригаду Брукса как крайность. Тем не менее, вам нужен кто-то, кто технически координирует, кто что делает, что-то вроде распределения людей на работу в разных частях системы, для решения, какие самые тяжелые (самые рискованные) части (чтобы они не откладывались до тех пор, пока они не станут дорогими изменить/исправить) и сделать выбор, когда команда не согласна. Такое техническое лидерство необходимо, будь вы создаете программное обеспечение, автомобили или палочки pogo.

Архитектура/Дизайн. Стандартная мантра состоит в том, что "каждая система имеет архитектуру", но следствие заключается в том, что не каждая архитектура намеренно выбрана. Вы можете неявно скопировать архитектуру из вашего последнего проекта, скажем, трехуровневую систему. Или это может быть предварительно определено после того, как вы знаете, что используете фреймворк вроде EJB. В начале проекта вы будете принимать архитектурные решения, и некоторые из них будут трудно изменить позже. Как вы будете хранить данные? Будете ли вы использовать фреймворк (например, Spring, EJB, RoR)? Будете ли вы обрабатывать данные постепенно или в пакетном режиме?

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

Не бойтесь думать об архитектуре заранее, особенно о том, как это может помочь вам избежать трудностей, но также не пытайтесь все решать заранее. У вас возникнут проблемы, если одна часть вашей команды начнет использовать Ruby on Rails, а другая часть начнет использовать EJB - так что сделайте некоторые технические решения, те, которые навязаны вам и тем, которые будут решать ваши самые большие риски.

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

Я рекомендую главе 12 Applied Software Architecture для руководства по вашему вопросу. Список заголовков дает хорошее представление о его совете: создание видения, архитектор в качестве главного технического консультанта, архитектор принимает решения, архитекторы, координаторы архитекторов, архитектор, защитники архитекторов. 97 Things, о которой вы говорите, скорее представляет собой сборник жемчужин мудрости, а не связный путеводитель по архитектуре.

Джордж Фэрбенкс, автор Только достаточная архитектура программного обеспечения

Ответ 3

У меня лично не было такого опыта, но вот несколько советов:

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

Ответ 4

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

Начните рассмотрение конкретных основных проблем архитектуры, таких как

• Общность и изменчивость
• разделение проблем
• агрегация над абстракцией

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

Ответ 5

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