Установка [закрытого] отдела архитектуры
, если вы хотите посмотреть доступный маршрут, импортировав его в компонент.
назначьте свои маршруты константе, как показано ниже
const appRoutes: Routes = [
{
path: 'asd',
component: asdComponent
},
{
path: 'ar',
component: arComponent
}
];
export const routing = RouterModule.forRoot (appRoutes);
здесь вы сможете экспортировать маршруты
импортируют константную маршрутизацию
import { routing } from './app.routing';
export class AppComponent {
route=routing;
/// route.providers is an array which internally contains the list of routes provided
console.log(route.providers);
}
, это просто найти доступные маршруты. не рекомендуется применять логику на основе этого
9 ответов
Вот несколько проблем, о которых нужно думать:
- Каков точный мандат для команды архитектуры?
- Что команда архитектуры является поставляемым компонентом? Платформа, инструкции, справка реализации... Или они - просто Астронавты Архитектуры?
- Это только для продвижения приложений, или это будет бэкпортом?
- Кто будет ответственен за бэкпортирование? (И мы имеем в виду бюджет здесь...),
- Будут ресурсы, выделенные тестированию бэкпортов?
- Делает Команду Архитектуры, имеют реальную мышцу, или будет управление сворачиваться, когда первая группа будет ворчать об этих 4 месяцах, она возьмет для реализации изменений...
- Как Вы будете иметь дело с трением между отдельными группами проекта и architure командой (и будет трение?). Оппортунисты возьмут это в качестве замечательной возможности всеми средствами добиться выгодного положения...
- Знайте, что это будет, прежде всего, политической игрой...
Мой друг, у Вас есть жесткая дорога вперед...
Первый шаг должен быть совершенно прозрачным на том, чего команда архитектуры, как предполагается, достигает.
Почему Вы помещаете команду на месте?
Вы пытаетесь объединить все приложения, разработать общие основы, что?
Каковы мандат и видение для этой команды?
Кто бы ни вывод в этой команде лучше имеют удар ** коммуникабельность.
Это не должен быть блестящий кодер, который может свистеть музыкальная тема Звездных войн и издавать шум светового меча..., но он должен, вероятно, быть в команде в технической способности.
Необходимо, вероятно, заполнить команду с людьми, которые знакомы с большинством проектов. Я опасался бы выбирать весь ток, ведет, поскольку это могло бы взять большой блок знания от текущих команд. И давайте столкнемся с ним, те команды должны быть продуктивными, в то время как команда архитектуры придумывает свои собственные результаты.
В архитектуре трудно разобраться.
"Архитекторы" нуждаются в питании добиться цели, но должны быть достаточно здравым смыслом, чтобы не злоупотребить тем питанием и полностью отчуждать остальную часть компании.
Я работал в двух местах, где команды архитектуры были реализованы - каждый имел успех, другой не выглядит настолько хорошим. В успешном месте это была относительно небольшая среда, где главный архитектор был распознан как технический лидер, и у других членов команды были превосходная запись и политические навыки. Все действовали в интересах организации.
В месте, которое это не разрабатывало так хорошо, архитекторы ясно представили определенные фракции в организации и не завоевывали доверие или уважение всего места. Результат состоял в том, что больше времени было проведено, готовя, извиняет для обхода архитектуры, чем подбирание любого значения от него. В этом случае, разочарование, в которое превращаются пассивные/агрессивные и другие антисоциальные поведения.
Я думаю другие вопросы, которые Вы спрашиваете об объеме/обязанностях/переходе, все отвечены "им, зависит". Это зависит от компании, людей, денег и расписания.
Интересный вопрос.
Во-первых, у Вас должно быть ясное понятие того, какую проблему эта команда "архитектуры" решает. Если Вы не можете ясно определить "миссию" команды, она приведет к сбою и сделает это с большими большими взрывами.:)
Однако первый шаг, определяют проблему, которую Вы решаете. Вы пытаетесь не отставать от технологии? Вы пытаетесь включить некоторое повторное использование кода между проектами? Вы пытаетесь использовать свой штат разработки к самому лучшему эффекту? Существует несколько причин реализовать команду архитектуры и, учитывая Вашу установку, любой из них мог бы быть sufficent. От Вашего вопроса похоже, что Ваша цель переделывает существующие приложения так, чтобы был хороший первый шаг.
Так как у Вас уже есть группа, ведет, которые имеют хорошие специальные знания приложений, которые это была бы хорошая идея запустить с них. Соберите их и долго обсудите то, на что должна быть похожей новая общая архитектура. Вы могли бы также хотеть заставить консультанта помогать упростить разговор в этой точке. Определите цели переделывания и выпустите "большое изображение", на которое все могут согласиться.
После этого я взял бы горстку приведение и продвинул бы их (заделывание приведения от объединения разработчика) команде архитектуры. Они затем встретятся с приведением, чтобы гарантировать, что дела идут согласно тому "Большому Изображению".
Я НЕ ввел бы совершенно новую группу с внешней стороны. Это создало бы нежелательное Нас по сравнению с Ними динамичный, который никогда не хорош. Посторонние также понятия не имели бы о том, как вещи, как предполагается, работают или почему вещи не работают способ, которым логика подразумевала бы, что они должны.:)
в целом будьте очень осторожны относительно стимулов, и политических и в других отношениях связанных с группой архитектуры. это далеко к легкому для 'архитектурного наблюдательного совета' (или независимо от того, что Вы хотите назвать его) стать барьерами для прогресса. Все это, взятия являются нулевым стимулом улучшить вещи и отрицательный стимул, когда вещи изменяются и сразу не улучшаются.
поймите, что ошибки будут сделаны, некоторые 'большие новые технологии' окажутся непродуманными популярными товарами, и изменением ecourage и инновациями. это может привести к случайному краткосрочному перевороту и отказавшему преобразованию, но это лучше, чем застой.
и альтернатива неизбежно приводит к застою; в более крупных организациях я видел карьеру, разрушенную, потому что менеджер верил достаточно в свою команду для поддержки их рекомендации для новой технологии полностью к вершине, обеспечьте тематические исследования, чтобы доказать его и поддержать ее к рукоятке. Когда новая технология была наконец утверждена (после почти года политической борьбы) технический директор (кто выступил против нее все время), требуемый кредит на инновации, и передал менеджера отделу задворок. В другом инциденте новая технология была предложена с многочисленными примерами успеха в той же сфере бизнеса, и комитет был сформирован для изучения проблемы. Пять лет спустя они все еще изучают проблему, и ничто не было сделано
"Архитектура" в этом контексте сам по себе ничего не означает. Это означает "экспертов по трансверсальным темам".
Каждый раз, когда у Вас есть "Команда архитектуры", у Вас будет трансверсальная команда, которая предоставит услуги для многих проектов.
Как указано предыдущими ответами, необходимо знать, к каким темам такой "Отдел архитектуры" должен будет обратиться.
Теперь, вот пример организации команд архитектуры на основе нескольких тем:
- Бизнес-архитектура и команда Функциональной архитектуры: записи много связанных с бизнесом спецификаций и проверок выравнивание между существующим приложением и функциональным рабочим процессом, для завершения когерентной картографии приложения.
- Команда Архитектуры приложения: обеспечивает картографию, но также и решите того, как функциональные спецификации, решенные Командой Бизнес-архитектуры и Функциональной архитектуры, будут организованы в приложения.
Например, Вам нужен функциональный модуль для "процесса портфеля", но команда Архитектуры приложения может решить разделить это на "средство запуска", "диспетчера", GUI, и так далее. - Команды Технической архитектуры, всегда состоящие из:
- Команда Архитектуры выполнения, для всех non-business-purely-technical тем (вход, KPI, платформы...)
- Команда Архитектуры разработки (оценка инструмента и поддержка, технологический обзор, управление репозиториями для управления версиями и управления конфигурацией)
- OA (Операционная Архитектура) для того, чтобы сделать среду "исполняемым файлом" (то есть, зная правильные процессы, правильные серверы и правильные сети для развертывания системы или для гомологизации или для производства.)
Можно хотеть добавить Логистическую команду для всего управления сервером и сетями с задачами Резервного копирования и стратегий DRP. И стратегия поддержки на основе хорошей системы случая.
И Вы хороши для движения.
Теперь, не забывайте, что, когда Вы начинаете, некоторые "большие переделывают", Ваша Функциональная архитектура будет иметь миссию осуществить когерентность оба между:
- переделанные проекты быть уверенными они остаются в фиксированном функциональном периметре
- проекты прежней версии быть уверенными их обслуживания не включают противоположный выбор по сравнению с тем, относился к переделанным проектам.
Любой переделывает в магазине это средство размера действительно, чтобы смочь сделать необходимые эволюции к проектам прежней версии при ожидании переделывания для создания первых выпусков. (Наследие не может только ожидать и остаться все еще в течение 2-3 лет, переделывают),
Большое переделывает, должен включить три главных этапа:
- Диалоговое окно 1/с наследием
- 2/завершают наследие
- 3/заменяют наследие
Значение любого данного компонента в действительности разрабатывается в три раза!;)
Удача и хорошая ночь.
Я думаю потребности команды архитектуры иметь людей, достаточно старших, что они знают внутренние работы всех групп разработчиков и смочь сказать "нет" запросам/направляющим линиям. Я был в, подходит к хорошим разработчикам, все же не имейте достаточного количества полномочий, и закончился после того, что более высокие менеджеры разработчика разряда от различных команд и произвел непоследовательные платформы.
Рассмотрите чтение/покупку этой статьи от ACM: Архитектор программного обеспечения. Существует несколько ссылок, доступных там, и автор необычно ясен по такой рассеянной теме. Он не ответит на Ваши вопросы непосредственно, но статья сфокусирует Вашу стратегию.
Находящийся на вершине рейтинга ответ на Ваш вопрос делает правильное замечание: Внимание на мягкие навыки и определяет цели. Я добавил бы глубокое понимание того, как вещи сделаны в Вашей организации.
Одна только архитектура могла бы превратить людей в астронавтов / зомби. Таким образом, у них должно определенно быть некоторое кодирование, чтобы сделать, даже если это - основная разработка прототипа. На самом деле успех их прототипов должен быть определенным фактором обзора.
Они должны выделить презентации ежемесячным журналом / частые блоги, которые отслеживают их работу, так, чтобы другие в организации могли учиться.
Должны быть академические цели как то, чтобы быть знакомым с определенными платформами / инструменты / книги и принципы проектирования.
Им нужно дать время для преследования новых инструментов / проекты / обязанности в существующих проектах, если они чувствуют себя подобно ему.
Они несли бы ответственность сделать по крайней мере 3-4 обзора кода критических модулей и придумать инструкции по стилю кода.
Они несли бы ответственность рассмотреть низкоуровневые проекты в - наименьшее количество ключевых модулей.
Им нужно дать свободное время как люди или команда для создания чего-то, что они чувствуют, могло бы быть полезным.
У них должна быть опция предшествовать архитектуре и возвратиться к постоянной работе, если они чувствуют себя подобно ему без включенных штрафов.
У них должна быть информация о том, что происходит через все проекты, работающие в организации. По крайней мере один проект должен сопровождаться тесно так, чтобы они могли сообщить своим собственным коллегам о материале, происходящем в другом месте. Это может возможно быть проектом, в котором они выполняют обзоры кода и такой.
У них должен быть очень технический человек как их менеджер.
Архитекторы должны быть переключены между проектами, после того как они очень знакомы с одним из них и разрешенные последовать безотносительно прототипа они где, следуя при работе с исходным проектом.
Имейте по крайней мере одну реальную цель (Как, консолидируют все общности через проекты в единственную библиотеку), каждый 1 год
Инвестируйте время и обучение гарантировать, чтобы архитекторы не связали эго и провели справедливо профессионально. Разрешение конфликтов и другое мягкое обучение навыков наряду с бюджетом для технических совещаний и обучение определенно требовались бы также.
Вам нужна работа через бизнес-сценарии A) и B)
A) Что, если Вы не настраиваете его, т.е. ничего не делаете:
Оценки переделывания на идущих затратах на обслуживание
B) Вы действительно настраиваете затем:
Разрушение к ближайшим результатам, из-за диверсии ресурса.
Риск несколько продуктов может быть скидкой-avantanged в ближайшей перспективе.
Затраты на воспринятую дополнительную рабочую силу.
Кто отметит, если продукты будут ослаблены осуществлением (производительность или воспринятая негибкость)
Затем получите команды продукта к так тому же осуществлению, сравните результаты.
При выравнивании по ширине его вот два маршрута, которые я видел:
1. Выберите ведущий продукт, чтобы управлять архитектурой и добавить ресурсы к этому проекту.
Затем будьте готовы добавить больше ресурсов и быть терпеливыми иначе, ведущий продукт страдает.
Вы рискуете подразделением с этим маршрутом, оно работало, когда ведущим продуктом составляли 40% дохода.
2. Запустите малочисленную команду, привлеченную из самых многообещающих обсуждений, которые происходили внутренне, перенеситесь в новой архитектуре в каждом продукте инкрементно.
Сотките эту работу команд в работа продуктов.
Некоторый Вопрос для Вас для взгляда на:
1. Как скоро делают необходимо достигнуть сходимости архитектуры для получения бизнес-преимущества.
2. Кто члены команды, уже говорящие о сходимости архитектуры, и они спрашивающий/предлагающий ее важность, Вам нужен этот вопрос на "втором месте" для 80% Ваших руководителей группы.
Что не сделать
* Наем в экспертах снаружи (если Вы не находитесь в реальной путанице теперь),
* Сдаются после нескольких месяцев это - длительный срок.
* Изменение все проекты сразу.
* Запускаются, пока у Вас нет ядра три, который может заставить это произойти.
* Позволяют отделу архитектуры стать немного более крупным, чем это должно быть
* Позволяют ему быть воспринятым, отдел архитектуры решит проблемы команд продукта
* Позволяют любому продукту, казаться, "ожидать новой архитектуры"
* Позволяют отделу архитектуры "определить все" или иметь расползание границ проекта
* Сила все продукты в архитектуру, некоторые не могут соответствовать (например, не разработанные в той же стране)
Что действительно делает:
* Вооруженный с хорошим выравниванием от первого вопроса заставляют высшее руководство покупать акции и просить, чтобы команды продукта сообщили о прогрессе
* Вносят пошаговые изменения в выравнивании продукта к карте архитектуры
* Работа над выравниванием линейки продуктов самого многообещающего или низкого риска сначала
* Установка метрики, таким образом, можно продемонстрировать значение, добавляют (см. выравнивание от ряда вопросов кулака),
* Имеют план действий для всех продуктов, которые будут сходиться или нет.
* Думают, что поставляет базовая архитектура и кто поддерживает ее артефакты
* Позволяют командам продукта способствовать ядру с точки зрения specificatios, кода и обслуживания ядра
* Установка trainig о том, как использовать работу команды архитектуры для новых начинающих и существующих команд