Comments 53
Вы забыли самое главное.
Архитектор должен писать код. Например, половину времени.
Писал код год назад не работает. Смотреть на код только через код ревью тоже не работает.
Иначе он быстро станет типичным менеджером, который в технические внутренности проекта даже не лезет. И все технические решения как обычно будут принимать лиды и сеньеры.
Архитектор должен писать код. Например, половину времени.
Писал код год назад не работает. Смотреть на код только через код ревью тоже не работает.
Иначе он быстро станет типичным менеджером, который в технические внутренности проекта даже не лезет. И все технические решения как обычно будут принимать лиды и сеньеры.
Согласен с Вами полностью. В обязательное требование я не включил это осмысленно. Иногда на это действительно нет времени из-за пула задач. Но отсутствие практики отрывает архитектора от реальности.
Я бы сказал, что он должен это делать как процесс поддержания навыков. Самостоятельно.
Я бы сказал, что он должен это делать как процесс поддержания навыков. Самостоятельно.
Самостоятельно писать продашен реди код в свободное время? На постоянной основе? У вас странные вкусы.
А когда отдыхать? Семья, хобби. Работая в свободное время можно быстро устать и уйти назад в разрабы. Денег не сильно меньше, а на твое свободное время никто не претендует.
Никто не говорит что обязательно каждый день по 4 часа. 2-3 дня в неделю, неделю через неделю, месяц через месяц если совсем никак.
Время выделяется руководством. Это обязательная часть работы. Чтобы чуство реальности не терять.
А когда отдыхать? Семья, хобби. Работая в свободное время можно быстро устать и уйти назад в разрабы. Денег не сильно меньше, а на твое свободное время никто не претендует.
Никто не говорит что обязательно каждый день по 4 часа. 2-3 дня в неделю, неделю через неделю, месяц через месяц если совсем никак.
Время выделяется руководством. Это обязательная часть работы. Чтобы чуство реальности не терять.
Продакшен реди код это сильно круто. У архитектора должен оставаться конфликт интересов с этим самым кодом. Я предполагаю участие архитектора в ключевых основах системы. Например базовые классы проекта или его структура. А развитие уже идет разработчиками.
В наших проектах для этого выделена область «core». В нее доступ имеет core-team. В том числе и архитектор через нее «видит» проект. Бизнес-логика же реализуется путем наследования от классов core.
Документация по API также развивается архитектором. Описанный контракт уже реализуется разработчиком.
В наших проектах для этого выделена область «core». В нее доступ имеет core-team. В том числе и архитектор через нее «видит» проект. Бизнес-логика же реализуется путем наследования от классов core.
Документация по API также развивается архитектором. Описанный контракт уже реализуется разработчиком.
Продакшен реди код это сильно круто. У архитектора должен оставаться конфликт интересов с этим самым кодом. Я предполагаю участие архитектора в ключевых основах системы. Например базовые классы проекта или его структура. А развитие уже идет разработчиками.
Так в доведении до прода весь сок.
Чтобы понять как все это ложится и переписывается при пятом изменении желаний менеджеров.
Как все это мониторится, отлаживается, саппортится.
Насколько часто происходят вообще неведомые вещи.
Насколько приятно писать, отлаживать и катать готовый код.
Если не доводить свой код до прода, то это все остается где-то сбоку и как бы не важно. Более-менее прилично сделать можно на любой основе. Вопрос только в количестве страданий в процессе.
В наших проектах для этого выделена область «core». В нее доступ имеет core-team. В том числе и архитектор через нее «видит» проект. Бизнес-логика же реализуется путем наследования от классов core.
Выглядит очень странно. В проекте есть код который нельзя менять, но который надо использовать.
Первое что я сделаю когда он не совпадет с реальностью это напишу свой рядом. Хорошо напишу, код ревью всякие он пройдет без проблем.
А такие несопадения будут примерно раз месяц. Менеджеры такие затейники, такие фичи хотят. Понятно что после такого я вероятно пойду на мороз, но это лучше чем страдать и делать костыли или заниматься бюрократией на пустом месте.
Документация по API также развивается архитектором. Описанный контракт уже реализуется разработчиком.
В век микросервисов АПИ это примерно все.
Публичное АПИ? Конечно, все только спасибо скажут. С ним море проблем и согласований всегда.
А вот апи между парой соседних микросервисов, которое еще и меняется в процессе разработки раз 5 фиксировать это такое себе. Поправить по паре строк и там и там, убедиться что никто больше не задет и всем станет лучше. Часто ведь бывает.
У вас там точно нет рядом второго «теневого» апи? Которое разработчики сделали чтобы работало, а не чтобы правильно было?
Коротко я ответить я тут не смогу. Нужно развернуто. Уже завтра отпишусь. Мы много обсуждали те вопросы, которые Вы подняли.
Так в доведении до прода весь сок.
Разработка это процесс. Ведь даже при наличии архитектуры ты не просто кодишь? Ты продумываешь алгоритм, реализацию этой архитектуры. Одну и ту же архитектуру можно реализовать несколькими способами. И от мастерства разработчика это зависит напрямую.
Архитектор хоть и обязан иметь широкий кругозор, но глубина его познаний в частных вещах может страдать по сравнению с сеньором по направлению.
Помимо этого, разработчик функционирует в окружении с которым постоянно взаимодействует. Это и лид, и тестировщики, и постановщики и т.д. Все это направлено на получение качественного кода.
Если архитектор должен писать прод реди код, то он обязан следовать установленным стандартам. Очевидно, что он превращается в разработчика. И выполнять свою функцию далее не может.
Но, архитектор не должен отрываться от реальности. Он обязан понимать как реализуется его задумка в системе. А в лучшем случае — контролировать этот процесс. Для этого создается процесс его участия.
Например, выделяется область core, в ней создаются базовые классы, хелперы, интерфейсы. Конечно, создается это не в одно лицо архитектором. А в тандеме с core-team, куда входят ведущие разработчики.
Далее, т.к. ведущие разработчики погружены в архитектуру, они сами приняли участие в ее реализации, экспертиза органично «разливается» на остальную команду.
Выглядит очень странно. В проекте есть код который нельзя менять, но который надо использовать.
Я не говорил, что нельзя. Я написал, что менять его может core-team. Это не какие-то люди в закрытом помещении на 45 этаже. Это твои коллеги за соседнем столом. И если тебе в голову пришло что-то поменять, и ты видишь, что это область core, то ты должен обратиться к ним — core-team.
Возможно ты удумал велосипед. В этом случае они помогут тебе его избежать. Вероятно, что тебе нужен новый функционал, но не хватает экспертизы или у тебя вообще «лапки». Тогда core-team поставит задачу в свой пул.
Но чаще всего, если это действительно нужно, делается все тот же классический pull-request, о принимает его core-team.
Таким образом, это административное выделение критического сегмента кода. Испортить систему вне core затруднительно. И именно эта точка контролируется архитектором.
В век микросервисов АПИ это примерно все.
Тут мы уже говорим о бардаке. Архитектура или есть или ее нет. Возможно, что архитектора не хватает на все. Хотя в этом случае нужно больше архитекторов. Но допустим. Это не повод отступать от принципов. Архитеткор разрабатывает стандарты и внедряет в процессы. И теперь любой API перед его реализацией как и код проходит процесс ревью.
Он может контролировать этот процесс через pull-requests. Всегда найти документацию на контракты. Всегда построить интеграционные связи. Без этого никуда.
У вас там точно нет рядом второго «теневого» апи?
Есть. Но это также узаконено. Есть область проттипирования и оперативного принятия решений. В прототипирование входят эксперименты не включенные в архитектуру. Да, это риск. Но риск этот управляемый.
Реальная проблема начинается тогда, когда разработчики не видят ценности в архитектуре. Именно тогда все разваливается на ходу. Когда ценность ясна, сам разработчик стремится контролировать свой сегмент, чтобы не превращать в бардак.
Надеюсь, смог ответить на все вопросы.
Вот вы создали область участия. Она не идет в прод. Точнее идет, но руками обычных разрабов. Те кто ее делал понятия не имеют насколько это удобно.
Они также понятия не имеют насколько больно выполнять их же правила разработки. Для решения надо просто писать код в продакшен. Eat your own dog food.
Надо поменять вот тут кусочек. Вместо типичного: ПР и на ревью устроена бюрократия.
Разработчики они часто нелюдимые и не хотят ни к кому подходить. А вы заставляете. Мне бы было просто неудобно третий раз идти и говорить что вот тут плохо. Надо переписать. Люди имеют привычку забывать, откладывать, делать потом. То есть то что мне нужно еще неизвестно когда прорастет в мастер.
Все таки стоит сделать рядом свое. Так даже быстрее будет. И всем хорошо сделаю. Надо поменять? Меняйте смело!
Вы слишком не доверяете свои разработчикам. Архитектура и ревью архитектуры это хорошо и правильно. Допустим на задачи от пары месяцев работы. А вот спускаться на уровень "этот код тебя нельзя трогать, его можно трогать только специальным людям" не стоит. Обязательное код ревью на этот код от сеньеров покрывает все задачи невнесения говнокода в общие места. И не вынуждает никого ни о чем просить или ждать.
Те кто ее делал понятия не имеют насколько это удобно.
Те, кто ее делал, не только понимают, но и непосредственно участвовали в принятии такого решения. Потому, что были причины так действовать.
Ключевая причина — противодействие хаусу. Т.е. когда любой в команде, вдруг, считает что нужно половину кода переписать. Потому, что он не хочет у кого-то что-то узнать. И думает, что легче все самому наваять.
А это приводит к дублированию кода. К лапше. Вечному рефакторингу и растущему техническому долгу. Этими процессами нужно управлять.
Вы слишком не доверяете свои разработчикам.
Мы доверяем своим разработчикам настолько, что в любой момент времени, любой разработчик может встать и сказать:
— Архитектура говно! Давайте что-то с этим сделаем!
Это приведет к совершенно конкретным активностям.
- Архитектор подключится к вопросу;
- Выслушает претензии;
- Если претензии основаны на недостатке информации — доведет ее. Проверит, что источники получения информации достаточны. А если нет, доработает.
- Если претензия обоснована, будет запущен процесс корректировки архитектуры.
Но… если разработчик просто считает, что архитектура такая себе, при этом не может ни обосновать своего мнения, ни предложить иных вариантов решения, то активность сведется к тому, что запрос будет отклонен с формулировкой — необоснованно.
Подчеркиваю, процессы должны служить делу. Если процессы мешают делу, их нужно корректировать. Но они должны быть ясны всем. И разумная бюрократия тут необходима.
Те, кто ее делал, не только понимают, но и непосредственно участвовали в принятии такого решения. Потому, что были причины так действовать.
Вы сами сказали что они не пишут код в прод. Окуда им знать?
Причины могут быть любые сделать что угодно. С какой-то стороны это будет хорошо и удобно. Но опять таки вероятно что мнение разработчика пишушего в прод будет другим. И не очень лестным.
— Архитектура говно! Давайте что-то с этим сделаем!
Это приведет к совершенно конкретным активностям.
Архитектор подключится к вопросу;
Выслушает претензии;
Если претензии основаны на недостатке информации — доведет ее. Проверит, что источники получения информации достаточны. А если нет, доработает.
Если претензия обоснована, будет запущен процесс корректировки архитектуры.
Будем реалистами. Кому это надо? Прыгать на людей которых поставили выше тебя? Да еще и доказывать что они не правы? Ну его. Больно надо. Я тут код пишу, а не политикой занимаюсь.
Костылим или акккуратно пишем сбоку. Отдаем на ревью такому же разрабу и никто ничего не узнает. Тикеты закрыты, фича выкачена. Что там в глубинах абстракций никто не полезет копаться. А полезет так ничего не скажет из-за тех же соображений. Фича сделана, код в проде, предположим что код нормальный. Чего прикапываться?
Но… если разработчик просто считает, что архитектура такая себе, при этом не может ни обосновать своего мнения, ни предложить иных вариантов решения, то активность сведется к тому, что запрос будет отклонен с формулировкой — необоснованно.
Вы мои слова ровненько подверждаете.
Писать код неудобно и неприятно? Отклонено.
Ваш велосипед заменяем вот на эту типовую библиотечку с нормальной лицензией? Отклонено.
Приходится городить бойлерплейт когда его можно избежать? Отклонено.
Можно просто сдедать в разы проще? Отклонено.
Стиль кода устарел лет на 10? Отклонено.
Все. Доводов нет.
Разговор заходит в тупик.
Кто они? Где сказал?
Архитектор не находится выше разработчика. Он — партнер.
Тем, кто болеет за результат.
Это выбор каждого.
Получим на ревью отлуп. И разъяснения почему это плохо. Потому, что ревью проводит не тот кому я захочу отдать, а тот кто облечен ролью ревьювера.
Для этого есть процесс качества. Возникший инцидент приведет к разработчику. Если еще на тестировании не будет выявлен.
Где?
Вы точно внимательно мой пост читали?
Создается впечатление, что вы упорно транслируете свою модель поведения в роли архитектора. Оно так не работает. Мне казалось, что в статье я достаточно четко выразил мысль о формировании доверия между разработчиком и архитектором.
Более того, Вы как-то странно представляете разработчика флегматичным лентяем да еще и глупым до мозга костей. Простите, я таких не видел. Все с кем мне доводилось общаться разумные люди воспринимающие аргументы. Умеющие выражать свое мнение также аргументированно.
И тот факт, что лично Вы в это не верите не меняет ситуации.
Вы сами сказали что они не пишут код в прод.
Кто они? Где сказал?
Прыгать на людей которых поставили выше тебя?
Архитектор не находится выше разработчика. Он — партнер.
Будем реалистами. Кому это надо?
Тем, кто болеет за результат.
Ну его. Больно надо. Я тут код пишу, а не политикой занимаюсь.
Это выбор каждого.
Костылим или акккуратно пишем сбоку.
Получим на ревью отлуп. И разъяснения почему это плохо. Потому, что ревью проводит не тот кому я захочу отдать, а тот кто облечен ролью ревьювера.
и никто ничего не узнает.
Для этого есть процесс качества. Возникший инцидент приведет к разработчику. Если еще на тестировании не будет выявлен.
Вы мои слова ровненько подверждаете.
Где?
Писать код неудобно и неприятно? Отклонено.
Вы точно внимательно мой пост читали?
Создается впечатление, что вы упорно транслируете свою модель поведения в роли архитектора. Оно так не работает. Мне казалось, что в статье я достаточно четко выразил мысль о формировании доверия между разработчиком и архитектором.
Более того, Вы как-то странно представляете разработчика флегматичным лентяем да еще и глупым до мозга костей. Простите, я таких не видел. Все с кем мне доводилось общаться разумные люди воспринимающие аргументы. Умеющие выражать свое мнение также аргументированно.
И тот факт, что лично Вы в это не верите не меняет ситуации.
Talk is cheap. Show me the code
Eat your own dog food
Вы нарушаете основополагающие принципы.
Вы сами сказали. Человек пишуший код и делающий архитектуру с ревью этой архитектуры другими такими людьми обычно называется сеньером. Если хотите назвать его архитектором ваш право.
Вы же говорите о людях не пишуших код. Я специально это сразу уточнил.
Партнер это тот кто вместе со мной хотфиксит релиз.
Тот чей код я ревьюю, а он мой ревьюит.
Тот, кто вместе со мной ночью откатывает внезапно упавший прод.
Тот с кем мы гадаем о причинах неведомой фигни по графикам. И потом переделываем эти графики, потому что они ничего не показывали на самом деле. Объяснять почему нужны не те, а вот эти графики? Увольте. Я даже простыми словами не расскажу что на них. Для менеджеров есть простые графики, которые им понятны. Вот на них пусть и смотрят.
В конце концов тот кто просто пишет код. Пилит фичи, рефакторит, сажает баги и фиксит их, знает о всех типовых проблемах и костылях.
У вас еще и ревью не все подряд проводят? Новичков и джунов исключаем по понятным причинам. А остальных то за что? Им же этот код поддерживать, дописывать и дежурить с ним. Им и оценивать насколько он хорош.
Нет. Я просто видел во что быстро превращаются люди не пишушие продакшен код, но пытающиеся указывать как это надо делать.
И видел типовые варианты обхода таких людей.
Допустим у вас люди увольняться не хотят, и они честно хотят чтобы было сделано нормально. Вариантов как запилить что-нибудь в обход формальных процедур море. Даже при десятке разработчиков в проекте никто ничего не отследит. Слишком много всего разом идет.
Я даже хитрые варианты с «развернуть микросервис вот на этой виртуалочке с именем dragons-lives-here и дергать его через воон тот балансер в конфиг которого годами никто не лазил туда можно любой роутинг запихать» не предлагал. Только самые очевидные.
Обычно вообще хватает простого невыполнения того о чем они говорят. Киваешь головой, соглашаешься и делаешь как хочешь. Они все равно не полезут код смотреть. Не их дело руки марать и читать тысячи строк кода новой фичи. А ведь в этих тысячах строк еще разобраться надо. Этот навык тоже быстро утрачивается. А дедлайн вон он. В прод надо. Срочно.
А потом: Это же уже продакшен код. Работает. Проблем не вызывает. Вот если соберемся рефакторить или переписывать из-за изменений задачи тогда и разбираться будем что там.
Я видел подобное и представляю как это работает. На самом деле достаточно разок послушать на совещании технические высказывания и предложения любого с любой должностью кто не писал хотя бы года 2. Это просто люди из другого мира.
Они могут быть отличными техническими менеджерами, знать много баззвордов. Причем на самом деле знать, а не на вики о них читать. Могут уметь договариваться с бизнесом о желаниях разработчиков, могут наоборот договариваться с разработчиками о желаниях бизнеса. Но им нельзя лезть в то как именно будет писаться код. Это дело разработчиков, в конце концов за это разрабочикам большие деньги платят.
Eat your own dog food
Вы нарушаете основополагающие принципы.
Кто они? Где сказал?
Вы сами сказали. Человек пишуший код и делающий архитектуру с ревью этой архитектуры другими такими людьми обычно называется сеньером. Если хотите назвать его архитектором ваш право.
Вы же говорите о людях не пишуших код. Я специально это сразу уточнил.
Архитектор не находится выше разработчика. Он — партнер.
Партнер это тот кто вместе со мной хотфиксит релиз.
Тот чей код я ревьюю, а он мой ревьюит.
Тот, кто вместе со мной ночью откатывает внезапно упавший прод.
Тот с кем мы гадаем о причинах неведомой фигни по графикам. И потом переделываем эти графики, потому что они ничего не показывали на самом деле. Объяснять почему нужны не те, а вот эти графики? Увольте. Я даже простыми словами не расскажу что на них. Для менеджеров есть простые графики, которые им понятны. Вот на них пусть и смотрят.
В конце концов тот кто просто пишет код. Пилит фичи, рефакторит, сажает баги и фиксит их, знает о всех типовых проблемах и костылях.
Получим на ревью отлуп. И разъяснения почему это плохо. Потому, что ревью проводит не тот кому я захочу отдать, а тот кто облечен ролью ревьювера.
У вас еще и ревью не все подряд проводят? Новичков и джунов исключаем по понятным причинам. А остальных то за что? Им же этот код поддерживать, дописывать и дежурить с ним. Им и оценивать насколько он хорош.
Создается впечатление, что вы упорно транслируете свою модель поведения в роли архитектора. Оно так не работает. Мне казалось, что в статье я достаточно четко выразил мысль о формировании доверия между разработчиком и архитектором.
Более того, Вы как-то странно представляете разработчика флегматичным лентяем да еще и глупым до мозга костей. Простите, я таких не видел. Все с кем мне доводилось общаться разумные люди воспринимающие аргументы. Умеющие выражать свое мнение также аргументированно.
Нет. Я просто видел во что быстро превращаются люди не пишушие продакшен код, но пытающиеся указывать как это надо делать.
И видел типовые варианты обхода таких людей.
Допустим у вас люди увольняться не хотят, и они честно хотят чтобы было сделано нормально. Вариантов как запилить что-нибудь в обход формальных процедур море. Даже при десятке разработчиков в проекте никто ничего не отследит. Слишком много всего разом идет.
Я даже хитрые варианты с «развернуть микросервис вот на этой виртуалочке с именем dragons-lives-here и дергать его через воон тот балансер в конфиг которого годами никто не лазил туда можно любой роутинг запихать» не предлагал. Только самые очевидные.
Обычно вообще хватает простого невыполнения того о чем они говорят. Киваешь головой, соглашаешься и делаешь как хочешь. Они все равно не полезут код смотреть. Не их дело руки марать и читать тысячи строк кода новой фичи. А ведь в этих тысячах строк еще разобраться надо. Этот навык тоже быстро утрачивается. А дедлайн вон он. В прод надо. Срочно.
А потом: Это же уже продакшен код. Работает. Проблем не вызывает. Вот если соберемся рефакторить или переписывать из-за изменений задачи тогда и разбираться будем что там.
И тот факт, что лично Вы в это не верите не меняет ситуации.
Я видел подобное и представляю как это работает. На самом деле достаточно разок послушать на совещании технические высказывания и предложения любого с любой должностью кто не писал хотя бы года 2. Это просто люди из другого мира.
Они могут быть отличными техническими менеджерами, знать много баззвордов. Причем на самом деле знать, а не на вики о них читать. Могут уметь договариваться с бизнесом о желаниях разработчиков, могут наоборот договариваться с разработчиками о желаниях бизнеса. Но им нельзя лезть в то как именно будет писаться код. Это дело разработчиков, в конце концов за это разрабочикам большие деньги платят.
Абсолютно.
Мы пошли по немного иному пути: у нас несколько очень сильных разработчиков, и они все выступают в роли архитектора на разных участках. Часто слышен клич: «ребята, застрял, нужна свежая идея» — внутри «команды» архитекторов.
Основная проблема с архитекторами, которые не пишут код — они не в состоянии оценить соотношение «качество архитектуры» / «качество + скорость имплементации». Некоторые вещи имеет смысл упростить архитектурно, ради изящества реализации. Некоторые — наоборот, усложнить, ради завтрашнего дня, — но не до состояния «реализовывать три года с группой синьеров».
… и они все выступают в роли архитектора на разных участках
Ну т.е. архитекторы есть. Сколько их это вопрос частный.
«ребята, застрял, нужна свежая идея» — внутри «команды» архитекторов
Мне кажется, это совершенно бытовой кейс. Более того, я не вижу необходимости выделить тут диалог архитектора с архитектором. Застрять это нормально. И совершенно логично обсудить со всеми, кто может в этом деле помочь.
Основная проблема с архитекторами, которые не пишут код
Это какие-то крайне высокоуровневые архитекторы, которые проектируют экосистемы на уровне бизнес-функций. Архитектор проектирующий систему не может не участвовать в разработке кода. Элементарно, разрабатывая архитектуру БД он должен понимать как туда класть данные и как достать. Как сделать это быстро. И быть способным ответить на вопрос — какого хрена ты придумал?
То же касается любого сегмента проектирования.
Некоторые вещи имеет смысл упростить архитектурно, ради изящества реализации. Некоторые — наоборот, усложнить, ради завтрашнего дня, — но не до состояния «реализовывать три года с группой синьеров».
А вот это как раз дает богатый опыт. Этот шаткий баланс между «а забьем на это пака» и «не, давайте в ни как в прошлый раз» очень ценен. И, к сожалению, молодые ребята, какие бы они умные не были не имеют его.
Архитектор проектирующий систему не может не участвовать в разработке кода. Элементарно, разрабатывая архитектуру БД он должен понимать как туда класть данные и как достать.
Не получается ли, что такой архитектор будет сильно ограничен в выборе компонентов?
Kafka/NATS/RabbitMQ/ZeroMQ… и это только очереди, с БД все еще более пестро. Разнообразные реализации edge router, ingress, serviсe mesh, logging, monitoring… Со всем не наработаешься.
Предыдущий опыт разработки, согласн, должен быть.
У архитектора, для начала, должно быть понимание, что все существующие решения делались для какой-то благой цели умными людьми.
Когда он начинает проектирование, он исходит конечно из своего опыта и знаний. Но выбирает решение наиболее релевантное задаче. Те же очереди, классическая задача выбора решения. Их не так уж и много. Зарекомендовавших себя. Проведение глубокого сравнительного анализа дает представление об области применения. Каждый продукт стремится в своей миссии указать свои сильные стороны.
Чуть сложнее дело со слабыми сторонами. Тут нужно уже ресерчить по практикам.
В ходе этого мероприятия, у архитектора складывается вполне ясное представление о продуктах. Да, оно не обличено опытом. Но далее идет прототипирование. В нем принимают участие специалисты различных направлений от аналитиков до девопсов. И формируется заключение.
В период прототипирования происходит погружение в технологию. Вооруженный опытом, архитектор достаточно быстро способен ее принять в себя и стать наставником.
Только после прототипирования идет внедрение. Т.е. с уже сформированным багажом знаний и опыта.
Ну и когда у тебя несколько успешных проектов за спиной, почти все технологии известны. Редко встретишь настолько уникальные проекты, где нужны уникальные решения. А за новинками следишь.
Для примера, в своем опыте, мне встречались такие решения как Cache Intersystems, IBM Websphere, Apache Synapse и т.п. Эти продукты завозились для решения конкретных бизнес-потребностей. Хотя эти же потребности можно было решить и более известными решениями. Но эффективность этих продуктов, на тот момент времени, оказывалась выше.
Когда он начинает проектирование, он исходит конечно из своего опыта и знаний. Но выбирает решение наиболее релевантное задаче. Те же очереди, классическая задача выбора решения. Их не так уж и много. Зарекомендовавших себя. Проведение глубокого сравнительного анализа дает представление об области применения. Каждый продукт стремится в своей миссии указать свои сильные стороны.
Чуть сложнее дело со слабыми сторонами. Тут нужно уже ресерчить по практикам.
В ходе этого мероприятия, у архитектора складывается вполне ясное представление о продуктах. Да, оно не обличено опытом. Но далее идет прототипирование. В нем принимают участие специалисты различных направлений от аналитиков до девопсов. И формируется заключение.
В период прототипирования происходит погружение в технологию. Вооруженный опытом, архитектор достаточно быстро способен ее принять в себя и стать наставником.
Только после прототипирования идет внедрение. Т.е. с уже сформированным багажом знаний и опыта.
Ну и когда у тебя несколько успешных проектов за спиной, почти все технологии известны. Редко встретишь настолько уникальные проекты, где нужны уникальные решения. А за новинками следишь.
Для примера, в своем опыте, мне встречались такие решения как Cache Intersystems, IBM Websphere, Apache Synapse и т.п. Эти продукты завозились для решения конкретных бизнес-потребностей. Хотя эти же потребности можно было решить и более известными решениями. Но эффективность этих продуктов, на тот момент времени, оказывалась выше.
У архитектора, для начала, должно быть понимание, что все существующие решения делались для какой-то благой цели умными людьми.
Когда он начинает проектирование, он исходит конечно из своего опыта и знаний. Но выбирает решение наиболее релевантное задаче.
Логично. Архитектура по сути решение набора проблем наиболее оптимальным способом с точки зрения ресурсов (денег, времени, исполнителей и т.д). Чем больше ресурсов (деньги время исполнители и т.д.) использовано в минимальном объеме (меньше денег + меньше времени + и т.д.) — тем архитектура удачнее\выгоднее.
Те же очереди, классическая задача выбора решения.
Я пару лет назад довольно много времени потратил этот выбор. В написании кода я не участвовал, потому что еще не было кода, а «архитектуру» нужно было уже создавать.
С другой стороны, понятие «участие в разработке кода» можно трактовать достаточно широко, так что я могу сказать, что сейчас я «принимаю участие в разработке, в том смысле, что кое-где прорабатываю архитектуру более детально и смотрю, что получается в итоге. Ну и всякие benchmark гоняю иногда. Но вот так, чтобы я писал существенную по объему часть кода — этого нет.
Со всем не наработаешься.
Со всем не надо работать, надо знать что внутри, то есть алгоритмы и структуры данных. Не те, что на первом курсе, а штуки вроде MVCC, из которого вытекает vacuum, из которого вытекают интересные следствия для репликации, write amplification и т.д. Увидели MVCC и сразу знаем, что ещё идёт в комплекте, без необходимости тратить годы на освоение нюансов каждого продукта.
Встречал два типа архитекторов:
- Слуга: Давайте я просто зарисую, что вы там напридумывали
- Творец: А давайте я все же придумаю архитектуру: но, мы обязательно будем использовать контекст, микросервисы и сделаем фреймворк для динамических типов и форм ввода. Желательно, чтобы и БД состояла лишь из 3 таблиц: две для метаданных, а одна — для значений… стойте! Давайте сделаем две таблицы! Ох, я гениален! А вы криворукие разработчики — не можете вытянуть данные из моих таблиц для отчетов!
Есть и другие типы, но эти крайности встречаю каждый день.
Метко!
Есть у меня "один знакомый", который пошел по второму сценарию. Ну не совсем, но что-то типа ключ-значение он запилил в реляционной бд через три таблицы.
Для этого были причины. Корневая — исключение даунтаймов системы при изменении структуры бд.
Грубо говоря, колонки таблицы заменены строками. Если в схеме появляется новая колонка, не требуется изменение схемы БД. В мета заезжает новое поле. Если удаляется, соответствующее поле дизейбится.
Этот подход не тотальный. Т.е. касается только чувствительной области данных. Где бизнес-мутации очень высоки.
Этого "знакомого" часто, подчеркиваю, справедливо критикуют за нарушение реляционного принципа. Но, пока, лучшего решения предложено не было.
Пилить связанные таблицы на каждую мутацию это еще более ад, чем документировать мету. Хотя этот подход всерьез рассматривался.
Также рассматривался вариант с созданием рядом таблицы с новой структурой, миграции данных и последующим переключением на нее.
Тоже не взлетает по причине шардирования и использования оригинальной таблицы на запись в момент миграции данных.
Но, пока, лучшего решения предложено не было.
Json/xml ?
Не понял вопроса. В значениях полей JSON структура. Реализовано на pg. Прекрасной особенностью этой субд является способность идексировать такие структуры. Что утвердило в таком решении.
Грубо говоря, колонки таблицы заменены строками. Если в схеме появляется новая колонка, не требуется изменение схемы БД. В мета заезжает новое поле. Если удаляется, соответствующее поле дизейбится.
Это очень похоже на EAV и это очень плохая идея. В противовес этому можно сделать таблицу kv, с колонками «key: varchar», «value: jsonb»
Ну собственно такая таблица и есть.
Почти. Только в ней key не varchar а идентификатор типа. Типы перечислены в специальной таблице, которая пополняется/модифицируется миграциями. В ней же хранится описание типа, признаки обязательности и валидатор значения.
«key: varchar», «value: jsonb»
Почти. Только в ней key не varchar а идентификатор типа. Типы перечислены в специальной таблице, которая пополняется/модифицируется миграциями. В ней же хранится описание типа, признаки обязательности и валидатор значения.
Положили в БД описание типов и валидаторов, а в коде написали интерпретатор всего этого дела. Вопрос — зачем писать такой интерпретатор и программировать на этом DSL, почему нельзя на нормальном языке все тоже самое описать?
В БД положены типы, чтобы компенсировать недостаток прозрачности структуры. Это нужно аналитикам, тестировщикам да и разработчикам. Когда ты пишешь запрос, ты легко можешь получить сведения о типах полей в человеческом виде.
Плюс к этому, это контроль консистентности структуры этого решения.
Валидатор это регулярка. Позволяет быстро провалидировать фактические данные в БД с целевым шаблоном. Помимо этого, участвует в генерации нотаций в формате OpenAPI.
Плюс к этому, это контроль консистентности структуры этого решения.
Валидатор это регулярка. Позволяет быстро провалидировать фактические данные в БД с целевым шаблоном. Помимо этого, участвует в генерации нотаций в формате OpenAPI.
Вообще ярый противник таких должностей. Это рудименты «отсталой» российской разработки и бюрократического аппарата. Задача современного бизнеса — мотивировать разработчиков так, чтобы они «горели» проектом. Важно понять одно: если в проекте царит атмосфера стартапа (а это значит что каждый участник рискует своими финансами, впрочем как и профитами) — то сообщество команды начинает выстраиваться в саморегулируемое… и тогда «размывается» грань архитектор ты… или разработчик. В этом дух стартапа. В этом дух будущего! А должность «архитектор» придумана, как пережиток бюрократического устройства системы, когда есть некто, кто определяет курс и несёт за него ответственность. Минус подхода в том, что ответственность архитекторы в современной продакт-команде ведут как правило словесную и доказательную… они никак не рискуют финансами, и как следствие — не «живут» проектом, а превращаются в банальных менеджеров. Благо, я замечаю, что бизнес рано или поздно начинает это понимать.
И правильно, как сказали выше, архитектор, как правило перестаёт писать код… и превращается в менеджера. Происходит банальное управление командой на уровне слов… не вникая в детали проекта и не понимая «узких» мест разработки. И разработчики от этого, только демотивируются… доказывать словами — пустая трата времени для разработчика. А доказывать делами, тогда, когда есть кто-то, когда взял на себя обязанность «вести» проект — глупо. В общем на мой взгляд — это рудиментарная должность, которая исчезнет со временем.
P.s. сугубо личное мнение, основанное на опыте разработки. Никого не хочу обидеть или задеть, возможно я ошибаюсь.
И правильно, как сказали выше, архитектор, как правило перестаёт писать код… и превращается в менеджера. Происходит банальное управление командой на уровне слов… не вникая в детали проекта и не понимая «узких» мест разработки. И разработчики от этого, только демотивируются… доказывать словами — пустая трата времени для разработчика. А доказывать делами, тогда, когда есть кто-то, когда взял на себя обязанность «вести» проект — глупо. В общем на мой взгляд — это рудиментарная должность, которая исчезнет со временем.
P.s. сугубо личное мнение, основанное на опыте разработки. Никого не хочу обидеть или задеть, возможно я ошибаюсь.
Небольшой дисклеймер. Я также не перехожу на личности. Я не вкладываю эмоции в ниже написанный текст.
Стартапы на то и стартапы, чтобы все делать не так. Их начинают либо зрелые бизнесмены, четко понимающие для чего это все и как он выстрелит. Назовем их быками. Либо, ребята с амбициями и решимостью. Этакие бизнес-люди-снежинки. Назовем их зайцами.
Так вот, быки действуют размеренно. Они сами уже архитекторы бизнеса. И хочешь ты этого или нет, но они приведут в команду человека с опытом. С успешным опытом, который знает как это сделать. Либо, купят состоявшийся стартап.
Зайцы берут не опытом. Они берут скоростью. Тут взял лару, тут раскатал рабит, тут запилил свой крончик. Все быстро и вот, уже через неделю ты готов продвигать свой бизнес.
Нужен ли тут архитектор? Да он все похоронит. Он постоянно будет зайца держать за хвост. Потому, что он понимает, что срок жизни у такого решения очень и очень краткий. Но объяснить это зайцу невозможно. Заяц не имеет тот же пул ценностей что и архитектор. Он же видит «дерево» и знает, что до него можно добежать за 10 секунд. А архитектор видит, что справа куст ракиты, слева волк, а сверху ворон. Но заяц пока молодой и не постиг боли. Он быстрый и уверенный в себе.
Даже не собираюсь защищать тут архитектора. Считаю, что заяц должен для начала выжить в этом суровом, суровом, суровом, суровом мире. Т.е. природа должна взять свое. Идти на проект где реализуется принцип заца — последнее дело для архитектора.
Как видите, в этом случае существует баланс. Стартапы не портят всякие архитекторы потому, что они туда не пойдут. С другой стороны, стартап можно испортить архитектором, если заяц раньше времени подумает, что он бык.
Стартапы на то и стартапы, чтобы все делать не так. Их начинают либо зрелые бизнесмены, четко понимающие для чего это все и как он выстрелит. Назовем их быками. Либо, ребята с амбициями и решимостью. Этакие бизнес-люди-снежинки. Назовем их зайцами.
Так вот, быки действуют размеренно. Они сами уже архитекторы бизнеса. И хочешь ты этого или нет, но они приведут в команду человека с опытом. С успешным опытом, который знает как это сделать. Либо, купят состоявшийся стартап.
Зайцы берут не опытом. Они берут скоростью. Тут взял лару, тут раскатал рабит, тут запилил свой крончик. Все быстро и вот, уже через неделю ты готов продвигать свой бизнес.
Нужен ли тут архитектор? Да он все похоронит. Он постоянно будет зайца держать за хвост. Потому, что он понимает, что срок жизни у такого решения очень и очень краткий. Но объяснить это зайцу невозможно. Заяц не имеет тот же пул ценностей что и архитектор. Он же видит «дерево» и знает, что до него можно добежать за 10 секунд. А архитектор видит, что справа куст ракиты, слева волк, а сверху ворон. Но заяц пока молодой и не постиг боли. Он быстрый и уверенный в себе.
Даже не собираюсь защищать тут архитектора. Считаю, что заяц должен для начала выжить в этом суровом, суровом, суровом, суровом мире. Т.е. природа должна взять свое. Идти на проект где реализуется принцип заца — последнее дело для архитектора.
Как видите, в этом случае существует баланс. Стартапы не портят всякие архитекторы потому, что они туда не пойдут. С другой стороны, стартап можно испортить архитектором, если заяц раньше времени подумает, что он бык.
Доля правды есть в ваших словах. Я уверен, что, к примеру в таких компаниях, как Google или Amazon — архитекторы тоже есть, и тоже двоякое мнение по поводу них у разработки) И я уверен, что у них те же проблемы… Что и у нас. Более того, после просмотра фильма Дудя про силиконовую долину я в принципе расстроился во всём :)
НО. Например, возьмём принципы разработки ПО. В какой то момент, вдруг все поняли, что монолит можно разбить на мелкие части и поддержка будет проще. Далее, тоже самое делается и с бизнесом — вдруг гиганты начинают понимать, что микрокоманды — приносят профит лучше, чем огромная машина. Едем дальше. Ковид показал, что удалённая разработка — ничем не хуже, чем офисная… И гиганты в этом убедились. И сейчас удалённой разработкой уже никого не удивишь.
Я уверен, следующим этапом — будет переход к более свободному духу разработки. Свободный — это когда нет жёстких требований и жёстких указаний. Когда фриланс может быть полезнее, чем несколько архитекторов. Про то, что конкурсные основы (по типу таких, которые устраивает Паша Дуров) — принесут профита больше, чем содержание штата ну и т.д. Когда ответственность несёт команда, а не отдельные должности, и команда же и рискует, предлагает решения, самоорганизовывается… Развивать мысль далее, я не буду. Но смысл в том, что всё меняется…
Наверняка хороший архитектор будет в цене. Но «хорошесть» должна базироваться на фактическом опыте выполнения проектов. На том, что реально было сделано и принесло ли профит.
НО. Например, возьмём принципы разработки ПО. В какой то момент, вдруг все поняли, что монолит можно разбить на мелкие части и поддержка будет проще. Далее, тоже самое делается и с бизнесом — вдруг гиганты начинают понимать, что микрокоманды — приносят профит лучше, чем огромная машина. Едем дальше. Ковид показал, что удалённая разработка — ничем не хуже, чем офисная… И гиганты в этом убедились. И сейчас удалённой разработкой уже никого не удивишь.
Я уверен, следующим этапом — будет переход к более свободному духу разработки. Свободный — это когда нет жёстких требований и жёстких указаний. Когда фриланс может быть полезнее, чем несколько архитекторов. Про то, что конкурсные основы (по типу таких, которые устраивает Паша Дуров) — принесут профита больше, чем содержание штата ну и т.д. Когда ответственность несёт команда, а не отдельные должности, и команда же и рискует, предлагает решения, самоорганизовывается… Развивать мысль далее, я не буду. Но смысл в том, что всё меняется…
Наверняка хороший архитектор будет в цене. Но «хорошесть» должна базироваться на фактическом опыте выполнения проектов. На том, что реально было сделано и принесло ли профит.
В ваших выводах наблюдается проблема первичности. Простой пример — почему деревья качаются? Потому, что ветер или ветер потому, что деревья качаются?
Действительно, удаленка много что показала. И хорошее и плохое. Есть такое хорошее утверждение — звездный час менеджера тогда, когда все плохо. А тут были целые недели. Многие зайцы сдохли. Быки выживали за счет жирка. Но народились новые зайцы, для которых этот «постапокалиптический» мир все, что они знают. Ладно, довольно метафор.
До ковида удаленка была. Но кто на нее шел? те, кто ее искал. Вопрос — зачем? Потому, что он имел некоторые цели ее получения. И в общем-то всегда они были шкурными. Удаленка не просто была, удаленщик хотел еще и быть свободным в графике.
Так кто ее искал? Оооочень часто люди мало организованные, ставящие в приоритеты не работу, а свои цели. Это я не теоретизирую, а лично работал с удаленными командами.
Что изменилось в ковид? На удаленку ушли люди которые собирались работать. Т.е. тот самый офисный планктон. И ничего удивительного в том, что он так же эффективно работал и удаленно. Совершенно ничего удивительного.
Теперь о том, что корпорации что-то там поняли. Удаленку рассматривали всегда. Ровно так же, из моего жизненного пыта этот вопрос всплывал регулярно. Но от него отказывались. Почему?
В крупной компании есть процессы, которые очень затруднительно вынести на удаленку. И это не совещания. С ними как раз все норм. Это документооборот. А также работа с персональными данными, коммерческой тайной и т.п.
Когда оценивались накладные расходы на обеспечение этих процессов, элементарная калькуляция говорила о том, что это неприемлемо.
Так что изменил ковид? И опять все просто. Он не дал иных путей как меняться. Все ли изменилось? Нет конечно. Огромная кипа документов ждет людей в офисах. Даже в период жесткого карантина не было тотальной удаленки. Ключевые люди завязанные на эти процессы ходили в офис. А многие процессы остановились до лучших времен.
Т.ч. радикального изменения не произошло. Будет все также. Проведут оценку и посмотрят результат. Если компания действительно смогла перестроиться и получила от этого выгоду (например экономия в аренде), то почему нет? Но подавляющее большинство вернется на начало. Собственно, достаточно выйти на улицу чтобы убедиться.
Я взял этот пример для наглядной демонстрации того, что глубинное понимание причин является необходимым. Такая роль, хочешь или нет будет. Но ее качество может быть различным.
Действительно, удаленка много что показала. И хорошее и плохое. Есть такое хорошее утверждение — звездный час менеджера тогда, когда все плохо. А тут были целые недели. Многие зайцы сдохли. Быки выживали за счет жирка. Но народились новые зайцы, для которых этот «постапокалиптический» мир все, что они знают. Ладно, довольно метафор.
До ковида удаленка была. Но кто на нее шел? те, кто ее искал. Вопрос — зачем? Потому, что он имел некоторые цели ее получения. И в общем-то всегда они были шкурными. Удаленка не просто была, удаленщик хотел еще и быть свободным в графике.
Так кто ее искал? Оооочень часто люди мало организованные, ставящие в приоритеты не работу, а свои цели. Это я не теоретизирую, а лично работал с удаленными командами.
Что изменилось в ковид? На удаленку ушли люди которые собирались работать. Т.е. тот самый офисный планктон. И ничего удивительного в том, что он так же эффективно работал и удаленно. Совершенно ничего удивительного.
Теперь о том, что корпорации что-то там поняли. Удаленку рассматривали всегда. Ровно так же, из моего жизненного пыта этот вопрос всплывал регулярно. Но от него отказывались. Почему?
В крупной компании есть процессы, которые очень затруднительно вынести на удаленку. И это не совещания. С ними как раз все норм. Это документооборот. А также работа с персональными данными, коммерческой тайной и т.п.
Когда оценивались накладные расходы на обеспечение этих процессов, элементарная калькуляция говорила о том, что это неприемлемо.
Так что изменил ковид? И опять все просто. Он не дал иных путей как меняться. Все ли изменилось? Нет конечно. Огромная кипа документов ждет людей в офисах. Даже в период жесткого карантина не было тотальной удаленки. Ключевые люди завязанные на эти процессы ходили в офис. А многие процессы остановились до лучших времен.
Т.ч. радикального изменения не произошло. Будет все также. Проведут оценку и посмотрят результат. Если компания действительно смогла перестроиться и получила от этого выгоду (например экономия в аренде), то почему нет? Но подавляющее большинство вернется на начало. Собственно, достаточно выйти на улицу чтобы убедиться.
Я взял этот пример для наглядной демонстрации того, что глубинное понимание причин является необходимым. Такая роль, хочешь или нет будет. Но ее качество может быть различным.
Действительно, удаленка много что показала. И хорошее и плохое. Есть такое хорошее утверждение — звездный час менеджера тогда, когда все плохо. А тут были целые недели. Многие зайцы сдохли. Быки выживали за счет жирка. Но народились новые зайцы, для которых этот «постапокалиптический» мир все, что они знают. Ладно, довольно метафор.
Быки всегда выживают, за счёт жирка. И за счёт коррупции в стране.
Так что изменил ковид? И опять все просто. Он не дал иных путей как меняться. Все ли изменилось? Нет конечно. Огромная кипа документов ждет людей в офисах. Даже в период жесткого карантина не было тотальной удаленки.
Вспомнилась шутка: «В России даже, если внедрят электронный чип, при приходе куда-то всё равно потребует бумажную копию этого чипа».
Проведут оценку и посмотрят результат. Если компания действительно смогла перестроиться и получила от этого выгоду (например экономия в аренде), то почему нет? Но подавляющее большинство вернется на начало.
Опять с этим не поспоришь. Более того, выгоду получили компании, которые завязаны на должностях, бумажной волоките и прочим коррупционным составляющим. А настоящий бизнес — «малый и средний», не зависящий от званий, выслуги лет и гособеспечений — меняет вектор бытия) Т.к. пункт выше.
В крупной компании есть процессы, которые очень затруднительно вынести на удаленку. И это не совещания. С ними как раз все норм. Это документооборот. А также работа с персональными данными, коммерческой тайной и т.п.
Всё давно решаемо. Самое главное, чтобы все это понимали. Включая людей, от которых зависит принятие решений. К сожалению, в большинстве — эти решения далеки от реальности.
Подитоживая: я просто высказал своё мнение. Возможно оно «недальновидное», но поживём — увидим. Ни в коим случае своими рассуждениями никого не хотел обидеть. Это всего лишь субъективное мнение. Да к тому же, возможно, неверное (ибо я не архитектор).
Вспомнилась шутка: «В России даже, если внедрят электронный чип, при приходе куда-то всё равно потребует бумажную копию этого чипа».
Хорошо, давайте другой пример приведу. Из реальной жизни. Смотрите. Трейдер. Он же через Интернет торгует? Какая ему разница откуда из дома или из офиса? Я даже больше скажу, очень многие трейдеры торгуют из дома. Роль идеально ложится в удаленщика.
Но, внезапно, их сгоняют в офис. Зачем?
Все дело в том, что действительно «взрослая» компания обеспечивает надежные каналы связи с биржей. Если вы торгуете из дома, проблемы с Интернет могут привести к завешиванию ваших позиций и к огромным убыткам.
Управляющие компании имеют каналы резервирования. И конечно, они подводятся в офис.
Вуаля. Российская коррупция тут не при делах. И такого, действительно много.
Но, внезапно, их сгоняют в офис. Зачем?
Требования регуляторов в первую очередь. Трейдеру не так сложно выдать роутер, который бы использовал мобильную связь в качестве резервного канала.
А вот факт того, что трейдеру слишком легко стало сливать свою позицию налево, крайне беспокоит как внутренний аудит банков, так и внешних регуляторов.
Абсолютно аналогично с юристами и их бумагами — просто регулятор требует, чтобы определенные вещи не выходили из офиса.
Подитоживая: я просто высказал своё мнение. Возможно оно «недальновидное», но поживём — увидим. Ни в коим случае своими рассуждениями никого не хотел обидеть. Это всего лишь субъективное мнение. Да к тому же, возможно, неверное (ибо я не архитектор).
А вот это делать нужно всегда. Если ты не спросишь, тебе не ответят. И ты не узнаешь.
Единственное, что стоит учитывать, это форму подачи. Даже с спустя 10ки лет в профессии ты гарантированно будешь ошибаться в чем-то и узнавать что-то новое. Поэтому, всегда нужно рассмотреть чужие аргументы. В подавляющем большинстве случаев находится что-то, что ты не знал.
С Вашей подачей все нормально.
А должность «архитектор» придумана, как пережиток бюрократического устройства системы, когда есть некто, кто определяет курс и несёт за него ответственность. Минус подхода в том, что ответственность архитекторы в современной продакт-команде ведут как правило словесную и доказательную… они никак не рискуют финансами, и как следствие — не «живут» проектом, а превращаются в банальных менеджеров. Благо, я замечаю, что бизнес рано или поздно начинает это понимать
Архитектор это инструмент понижения бизнес рисков с помощью которого решаются конкретные проблемы: Координация направления решения, поддержание базы знаний решения (ведение проектной документации), аудит реализации решения.
Кто-то должен дать банальный ответ на вопросы: а сколько будет стоить в разработке? а сколько будет стоить в эксплуатации, а сколько будет стоить в сопровождении? а какой жизненный цикл этого решения? И такие данные должены быть по нескольким вариантам решений, поскольку бизнесу надо планировать свои финансовые потоки и риски. Разработчик этим будет заниматься? Проектный менеджер? у них просто нет таких компетенций.
Некоторые компании реализуют что-то вроде «архитектурного комитета» — в котором несколько архитекторов по нескольким направлениям. Небольшие компании могут делать что-то вроде внутреннего публичного рецензирования архитектурных решений.
С этим я не поспорю. Я к тому, что для того, чтобы архитектору дать временную оценку и все прочие оценки, ему надо иметь чёткое представление о том, как это лучше сделать. Зачастую, этих представлений нет в связи с ограниченностью времени архитектора, которое он тратит на корректировку таких оценок :)
Посмотрите вот этот комментарий: habr.com/ru/post/517442/#comment_22022990
Человек, мудро описывает решение данной ситуации.
Посмотрите вот этот комментарий: habr.com/ru/post/517442/#comment_22022990
Человек, мудро описывает решение данной ситуации.
Зачастую, этих представлений нет в связи с ограниченностью времени архитектора, которое он тратит на корректировку таких оценок :)
Зависит от бюджета проекта и степени риска.
Для проектов с шестизначными суммами — это правило может и сработает. Для семизначных бюджетов и выше — время найдется. +- неделя на оценку точно будет, если это не тендерное предложение, если государственное или критическое для бизнеса — то там только требования будут месяца два… три собирать для подписания контракта и первичного бюджетирования.
del
Все архитекторы смешались в кучу — энтерпрайз, систем, солюшн и т.д.
Но мое мнение — эта должность очень сильно себя дискредитировала. Особенно в крупных компаниях от 20 тысяч человек и более. Рисовальщики картинок и схемок, которые не хотят и не могут разбираться в системах, для которых предлагают решения, с известными только себе одним целями (вставить корпоративную систему аутентификации в мелкий проект через прослойку, которую не умеет ни одна, ни другая система — запросто).
Подсветить риски и помочь в выборе технологий продуктам? Держи карман шире.
И когда дело касается бюджетов с 7, 8, 9 нулями все становится только хуже и хуже.
Техлид — ок, архитектор — не ок.
Но мое мнение — эта должность очень сильно себя дискредитировала. Особенно в крупных компаниях от 20 тысяч человек и более. Рисовальщики картинок и схемок, которые не хотят и не могут разбираться в системах, для которых предлагают решения, с известными только себе одним целями (вставить корпоративную систему аутентификации в мелкий проект через прослойку, которую не умеет ни одна, ни другая система — запросто).
Подсветить риски и помочь в выборе технологий продуктам? Держи карман шире.
И когда дело касается бюджетов с 7, 8, 9 нулями все становится только хуже и хуже.
Техлид — ок, архитектор — не ок.
Я бы еще добавил — коллега из американского банка в свое время рассказал, что там должность архитектора — это что-то вроде вахтера была (конкретно в его отделе, правда, пару лет назад).
Ну то есть основная задача была следующая: прийти, оценить проект; сходить к начальству и узнать свою точку зрения; вернуться в проект и озвучить сомнения.
Уже моё додумывание — если выдать должность "секретарь" или "ПМ", то не получится говорить "авторитетно", придется доказывать свою точку зрения, а здесь подобному человеку было бы сложно общаться с командой, которая уже несколько лет как в теме. А должность "архитектор" прекрасно подходит под данный сценарий.
Как я сказал выше — не стоит принимать подобный частный случай за правило, это всего лишь еще один пересказ ситуации, да еще и не от очевидца.
На мой взгляд роль архитектора в проекте можно определить как переводчик с языка предметной области на язык программистов и обратно. И так как предметная область и область программирования оперируют практически непересекающимися сущностями, то качественный перевод предполагает конструирование сущностей для каждой стороны исходя из задаваемых противоположной стороной рамок в виде пожеланий или недовольства.
Данный тезис можно продемонстрировать на примере задач, выполняемых мной в в качестве архитектора в проекте создания программного обеспечения для экономических подразделений крупной промышленной Компании. В проекте было задействовано помимо меня в разное время от 1 до 3 программистов и от 2 до 3 специалистов предметных областей. На начальном этапе количество пользователей составляло около 100 человек, в настоящее время количество активных пользователей превышает 1000 человек. Проект разрабатывался с 2009 по 2016 год.
Итак, функции архитектора специализированного программного обеспечения (далее ПО):
1. Разработка и развитие модели хранения данных и расчетной модели.
2. Настройка и расширение структуры данных ПО (объекты учета, типы и классы объектов учета, системные справочники).
3. Настройка компонентов подсистемы бизнес-транзакций ПО (бухгалтерские счета, проводки, документы, связи документов, фильтры счетов и проводок).
4. Расширение возможностей архитектуры действующей версии ПО и новой версии ПО 2.0 под новые задачи подразделений.
5. Организация перевода работы строительного подразделения Компании из замороженной версии ПО-Строительство на типовую модель данных ПО-Экономика, используемой экономическим подразделением Компании.
6. Постановка задач по развитию функциональности подсистемы бизнес-транзакций ПО и переносу форм устаревшей архитектуры на новую модель бизнес-транзакций.
7. Постановка задач перед внешними подрядчиками по разработке отдельных функций в новой версии ПО 2.0.
8. Адаптация настроек действующей версии ПО под требования программы переноса данных из действующей версии ПО в новую версию ПО 2.0.
9. Настройка автоматической прокачки данных документов на уровне базы данных MS SQL на языке Transact SQL и встроенного языка формул ПО с помощью подключаемого расчетного модуля в действующей версии ПО.
10. Создание и настройка форм пользовательских документов посредством конфигурационных файлов на Python-подобном упрощенном синтаксисе с последующей их компиляцией в конфигурационные файлы ПО в формате XML.
11. Создание колонок документов в базе данных и настройка формул для формульных колонок.
12. Помощь сотрудникам экономического подразделения Компании в настройке формул строк документов с особо сложной предметной логикой.
13. Поиск и исправление логических ошибок в расчетной системе ПО.
14. Предоставление прав доступа к ПО сотрудникам Компании.
15. Настройка расширенных прав доступа и предоставление в ним доступа сотрудникам предприятий Компании для решения специфических задач.
16. Консультирование подразделений Компании, применяющих ПО в своей работе, по эффективному применению ПО.
17. Контроль и координация деятельности сотрудников отдела информационного обеспечения в рамках текущего сопровождения ПО.
18. Контроль и координация деятельности всех сотрудников Компании, задействованных в процессе настройки и использования ПО, через трекер задач.
19. Разработка и проведение курсов подготовки пользователей ПО на площадке учебного центра Компании.
20. Арбитраж сложных организационных ситуаций, возникающих в процессе эксплуатации ПО между сотрудниками предприятий Компании, подразделений Компании и отдела информационного обеспечения.
Данный тезис можно продемонстрировать на примере задач, выполняемых мной в в качестве архитектора в проекте создания программного обеспечения для экономических подразделений крупной промышленной Компании. В проекте было задействовано помимо меня в разное время от 1 до 3 программистов и от 2 до 3 специалистов предметных областей. На начальном этапе количество пользователей составляло около 100 человек, в настоящее время количество активных пользователей превышает 1000 человек. Проект разрабатывался с 2009 по 2016 год.
Итак, функции архитектора специализированного программного обеспечения (далее ПО):
1. Разработка и развитие модели хранения данных и расчетной модели.
2. Настройка и расширение структуры данных ПО (объекты учета, типы и классы объектов учета, системные справочники).
3. Настройка компонентов подсистемы бизнес-транзакций ПО (бухгалтерские счета, проводки, документы, связи документов, фильтры счетов и проводок).
4. Расширение возможностей архитектуры действующей версии ПО и новой версии ПО 2.0 под новые задачи подразделений.
5. Организация перевода работы строительного подразделения Компании из замороженной версии ПО-Строительство на типовую модель данных ПО-Экономика, используемой экономическим подразделением Компании.
6. Постановка задач по развитию функциональности подсистемы бизнес-транзакций ПО и переносу форм устаревшей архитектуры на новую модель бизнес-транзакций.
7. Постановка задач перед внешними подрядчиками по разработке отдельных функций в новой версии ПО 2.0.
8. Адаптация настроек действующей версии ПО под требования программы переноса данных из действующей версии ПО в новую версию ПО 2.0.
9. Настройка автоматической прокачки данных документов на уровне базы данных MS SQL на языке Transact SQL и встроенного языка формул ПО с помощью подключаемого расчетного модуля в действующей версии ПО.
10. Создание и настройка форм пользовательских документов посредством конфигурационных файлов на Python-подобном упрощенном синтаксисе с последующей их компиляцией в конфигурационные файлы ПО в формате XML.
11. Создание колонок документов в базе данных и настройка формул для формульных колонок.
12. Помощь сотрудникам экономического подразделения Компании в настройке формул строк документов с особо сложной предметной логикой.
13. Поиск и исправление логических ошибок в расчетной системе ПО.
14. Предоставление прав доступа к ПО сотрудникам Компании.
15. Настройка расширенных прав доступа и предоставление в ним доступа сотрудникам предприятий Компании для решения специфических задач.
16. Консультирование подразделений Компании, применяющих ПО в своей работе, по эффективному применению ПО.
17. Контроль и координация деятельности сотрудников отдела информационного обеспечения в рамках текущего сопровождения ПО.
18. Контроль и координация деятельности всех сотрудников Компании, задействованных в процессе настройки и использования ПО, через трекер задач.
19. Разработка и проведение курсов подготовки пользователей ПО на площадке учебного центра Компании.
20. Арбитраж сложных организационных ситуаций, возникающих в процессе эксплуатации ПО между сотрудниками предприятий Компании, подразделений Компании и отдела информационного обеспечения.
Вы меня искренне простите, но я не могу даже примерно определить Вашу роль в компании. В ваших функциях грубые нарушения областей компетенций. А также грубые нарушения корп. безопасности.
Приведу пример:
vs
Эти два пункта говорят о том, что Вы тот самый честный человек на ком стоит все предприятие. Вы сами и пилити системы и эксплуатируете, да еще и доступы предоставляете. Если завтра вы станете немного менее честным и более хитрым… или что более вероятно — на ваше место придет такой человек, то предприятие может в одночасье исчезнуть или сильно пострадать.
Это далеко от хороших практик. И не отвечает роли архитектора никак. Еще раз простите меня (думаю, что Вас всем этим «наградили» особо не согласуя), но это роль больше похожа на аникейщика в глобальных масштабах.
Остается лишь надеяться, что Вам это нравится.
Приведу пример:
1. Разработка и развитие модели хранения данных и расчетной модели.
…
9. Настройка автоматической прокачки данных документов на уровне базы данных MS SQL на языке Transact SQL и встроенного языка формул ПО с помощью подключаемого расчетного модуля в действующей версии ПО.
vs
15. Настройка расширенных прав доступа и предоставление в ним доступа сотрудникам предприятий Компании для решения специфических задач.
Эти два пункта говорят о том, что Вы тот самый честный человек на ком стоит все предприятие. Вы сами и пилити системы и эксплуатируете, да еще и доступы предоставляете. Если завтра вы станете немного менее честным и более хитрым… или что более вероятно — на ваше место придет такой человек, то предприятие может в одночасье исчезнуть или сильно пострадать.
Это далеко от хороших практик. И не отвечает роли архитектора никак. Еще раз простите меня (думаю, что Вас всем этим «наградили» особо не согласуя), но это роль больше похожа на аникейщика в глобальных масштабах.
Остается лишь надеяться, что Вам это нравится.
Согласен, что многие вещи действительно «далеки от хороших практик». Тем не менее, это был проект, в основном завершенный в 2016 году, после чего многие организационные вещи были приведены в классический вид, в том числе вопросы предоставления прав доступа. Кроме того, многие технические и организационные проблемы, напрямую не связанные с проектом, были оптимизированы под его влиянием.
Данный перечень был приведен как пример того, что на момент создания нового продукта существуют не только технические, но и организационные трудности, решать которые, на мой взгляд, лучше всего архитектору как специалисту, имеющему целостное видение конечного результата и препятствий по его достижению.
При этом, как это часто бывает в жизни, некоторые задачи либо приходится делать самому, так так альтернативой этому является откладывание их решение до лучших времен. Как пример, это реализованное в самом начале проекта временное решение по прокачке данных на уровне MS SQL, альтернатива которому была сформирована только к концу проекта. А до этого времени приходилось делать это самому, так как программисты не понимали бизнес-логику, а экономисты не имели опыта работы с SQL-базами.
Еще одно важное замечание связано с тем, что некоторые организационные решения являются гораздо более эффективной альтернативой программной разработке некоторого функционала. И такие вопросы опять же могут быть решены только архитектором, обладающим видением конечного результата и критериев его эффективности.
Данный перечень был приведен как пример того, что на момент создания нового продукта существуют не только технические, но и организационные трудности, решать которые, на мой взгляд, лучше всего архитектору как специалисту, имеющему целостное видение конечного результата и препятствий по его достижению.
При этом, как это часто бывает в жизни, некоторые задачи либо приходится делать самому, так так альтернативой этому является откладывание их решение до лучших времен. Как пример, это реализованное в самом начале проекта временное решение по прокачке данных на уровне MS SQL, альтернатива которому была сформирована только к концу проекта. А до этого времени приходилось делать это самому, так как программисты не понимали бизнес-логику, а экономисты не имели опыта работы с SQL-базами.
Еще одно важное замечание связано с тем, что некоторые организационные решения являются гораздо более эффективной альтернативой программной разработке некоторого функционала. И такие вопросы опять же могут быть решены только архитектором, обладающим видением конечного результата и критериев его эффективности.
в крупных компаниях много бумагомарания, большие бюджеты выделяются только пройдя через бесчисленные комитеты и митинги, и для таких целей подойдет Архитектор.
Человек который создает L0/L1 диаграмму всего проекта — набросок архитектурного решения и поддерживает ее в актуальности. Большой софт обычнл имеет кучу взаимосвязей и интеграций, и индивидуальные вещи могут аутсорситься на галеры, и Архитектор помогает разбить предметную область на домены и очертить границы — гдя чья ответственность, а также как будет вырисовываться интеграция.
простой пример: Компании нужен интранет-сайт для сотрудников для планирования отпусков. Разработчик-формошлеп модет сказать: да щас я забацаю это на реакте за неделю.
А архитектор скажет, так тут нужен модуль SSPI авторизация через AD, чтобы не спрашивать пароль, также standby база и сервак нужны в другом датацентре как hot standby на слуяай disaster recovery, согласно стандартам компании, а данные по отпускам нужно подсасывать из системы учета кадров/data warehouse, а вот функции аппрувала отпусков нужно делегировать двум вышестоящим менеджерам, на члуяай если один из них в отпуске и т.д и т.п
со временем эта идея "давайте забайаем сайт с двумя формами" превращается в типичное ентерпрайзное решение благодаря архитекторам (гуглите FizzBuzz Enterprise Edition для примера)
А архитектор скажет, так тут нужен модуль SSPI авторизация через AD, чтобы не спрашивать пароль, также standby база и сервак нужны в другом датацентре как hot standby на слуяай disaster recovery, согласно стандартам компании, а данные по отпускам нужно подсасывать из системы учета кадров/data warehouse, а вот функции аппрувала отпусков нужно делегировать двум вышестоящим менеджерам, на члуяай если один из них в отпуске и т.д и т.п
+100, так и скажет. Но он еще скажет почему.
В первую очередь архитектор, и в том числе программный архитектор должен обладать прокачанным системным мышлением. Не просто «системным мышлением» а научными знаниями, усвоенными и переваренными, которые накоплены в научной дисциплине — «системное проектирование», как более узкоспециализированной областью системного мышления.
Могу порекомендовать отличный курс от Анатолия Левенчука на курьсере от МФТИ www.coursera.org/learn/system-thinking, не сочтите за рекламу, но я просто не понимаю, как можно что-либо проектировать, не обладая этим базовым минимумом.
Могу порекомендовать отличный курс от Анатолия Левенчука на курьсере от МФТИ www.coursera.org/learn/system-thinking, не сочтите за рекламу, но я просто не понимаю, как можно что-либо проектировать, не обладая этим базовым минимумом.
Не холивара ради. Попробую объяснить.
Т.е. любой академический курс основывается на практиках. Ценность курса заключается в консолидации лучших практик. Курс основанный исключительно на теории не функционирует нигде за исключением самого института, где его выдумали.
Это не обесценивает курс. Он действительно позволяет получить общие знания о предмете. Но полученные знания будут искаженными. Дело в том, что не имея опыта, получая знания, ты расставляешь маркеры на входящую информацию исходя из своего опыта. А его нет. И запоминаешь только то, что тебе кажется важным.
В итоге, к сожалению, приходя на работу студент вынужден полностью переучиваться.
Повторюсь, с очень большой вероятностью ему читали толковый курс. Но он запомнил из него не то, что нужно было. И не смог построить правильные связи. Не научился использовать.
Гораздо более эффективен обратный процесс. Когда у человека уже есть опыт и он проходит курс, которые структурирует уже имеющиеся знания. Получая новые, такой абитуриент хватается за них, понимая, как они ему пригодятся в жизни. И тут же использует.
Поэтому, еще в институте студенты делятся на две категории: теоретики и практики. Теоретики в среднем учатся хорошо по всем предметам. А практики автоматом получают оценки по конкретным предметам и имеют раскошные хвосты по другим. Просто потому, что они не видят ценности в этих предметах.
Нау́ка — область человеческой деятельности, направленная на выработку и систематизацию объективных знаний о действительности
Т.е. любой академический курс основывается на практиках. Ценность курса заключается в консолидации лучших практик. Курс основанный исключительно на теории не функционирует нигде за исключением самого института, где его выдумали.
Это не обесценивает курс. Он действительно позволяет получить общие знания о предмете. Но полученные знания будут искаженными. Дело в том, что не имея опыта, получая знания, ты расставляешь маркеры на входящую информацию исходя из своего опыта. А его нет. И запоминаешь только то, что тебе кажется важным.
В итоге, к сожалению, приходя на работу студент вынужден полностью переучиваться.
Повторюсь, с очень большой вероятностью ему читали толковый курс. Но он запомнил из него не то, что нужно было. И не смог построить правильные связи. Не научился использовать.
Гораздо более эффективен обратный процесс. Когда у человека уже есть опыт и он проходит курс, которые структурирует уже имеющиеся знания. Получая новые, такой абитуриент хватается за них, понимая, как они ему пригодятся в жизни. И тут же использует.
Поэтому, еще в институте студенты делятся на две категории: теоретики и практики. Теоретики в среднем учатся хорошо по всем предметам. А практики автоматом получают оценки по конкретным предметам и имеют раскошные хвосты по другим. Просто потому, что они не видят ценности в этих предметах.
спасибо за ссылку. как раз та такие комменты и люблю хабр
Ох, смешались в кучу… Если мы возьмем тот же тогаф за глоссарий, то видимо мы говорим про applicatons с примесью technology. Неплохо было бы рассказать, хотя бы вскользь, что есть и другие роли, и хотя бы верхнеуровневые отличия. Еще момент, который наверное бы стоило отметить что границы эти довольно зыбкие и роль applications может выполнять аналитик, а technology — qa. Да, и совсем не зашел посыл про «должен-не должен». Архитектор — это человек который имеет богатый опыт ошибок, а также желание на основе опыта и навыков принимать вместе с командой более осмысленные решения в процессе реализации идей. Без желания ничего не сработает на мой взгляд.
После "кажется" в заголовке нужна запятая
Давайте создадим образ «идеального творца», перечислим все положительные качества и как он их реализует, конечно это я сам хочу таким быть, а что… Назовём наш идеал как? АРХИТЕКТОР!
Sign up to leave a comment.
Мама, кажется я архитектор