Pull to refresh
49
0
Яков @XaBoK

Enterprise Architect

Send message

Фейл архитектора - это такая редкость, что больше похоже на черного лебедя, чем на риск для проекта. Архитектор обычно специалист с богатым опытом. И решение которое он предлагает - не единственно верное, а оптимальное в плане сложности и затрат в конкретном контексте и требованиях. Успех же проекта - усилия всей команды и прозрачность процессов.

Чтоб не вращать коней в вакууме: заказчик хочет микросервисы в облаках и чтоб всё на mssql. Архитектор из консалтинга даёт типичное решение, но предлагает заменить дорогущие инстансы ms на монгу. "Экономия денег? Конечно мы за!" - говорит управляющий со стороны заказчика. Потом, конечно, выясняется, что надо обучить нюансам х разработчиков. Но опыт и команда у консалтеров есть, так что немного денег и времени - всё равно экономия огромна. Когда проект почти готов, выясняется, что у них есть отдел с тоннами инструментария и внутренних продуктов именно под ms sql enterprise. Так что либо переделывать проект либо всю их внутреннюю кухню. Официально требования в контракте никто не менял, так что "нас обманули" и вся фигня. В моей практике это не единичный случай, так что важно чтоб принятие альтернативы исходило от заказчика формально и архитектура соответствовала задокументированным решениям.

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

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

Тоже самое с тестами - их пишут как говнокод, а там тоже можно дать дизайн и создать фреймворк. Разработчик смотрит на свою задачу, а архитектор на весь проект целиком.

Очень странный опрос. Серии которые издавались десятками лет, как например МК с 1992 и по сей день. Где-то в возрасте 30+ можно выделить всё.

Пусть борются с глобальным потеплением! Используют машины для производства льда и вентиляторы чтоб охлаждать землю!

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

Мне кажется у вас очень оптимистичный взгляд на вещи. Инфляция, засухи, вирусы и войны пошатнули мировую экономику. Лишних денег на рисковые инвестиции не стало - всё остальное лишь следствие из этого.

Всё тупо упирается в деньги. Пока рекламодатели платят много, а пользователи стриминга мало, будет возникать вопрос окупаемости и перетягивания ползунка от удобства к прибыли. Ведь нетфликс и издатель и производитель контента, а не просто стриминг. Иными словами - они много тратят. Это риск, за который они предлагают платить пользователям.

Ну тут ещё и цена на эфир сильно упала, а цена на электричество только растёт...

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

Конечные автоматы и юнит тесты как раз и есть варианты 1 и 2 из поста. Юнит тест обязан перебрать все варианты для 100% покрытия. Описания состояний и переходов между ними - state machine. Не понятно только, почему предлагают выбирать между ними...

Точно, помню рекламщики наружку в полиграфию на них носили.

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

Ваши предложения по ситуации, когда одного руководителя нет? Вот пара примеров:

  • общая инфосистема 5 разных компаний - у каждой свой представитель в проекте и часть бюджета. Заказчика как бы и нет - законодатель обязал.

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

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

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

А вот что делать на старте без чёткого понимания куда нужно строить путь и без команды менеджмента? С набором эгоцентричных одиночек можно ломать, а не строить. Нулевой спринт и есть самая проблема - когда надо заложить основу. Потом уже можно жевать по ложечки за раз. Как заставить стадо собраться и сделать выбор? Какой набор инструментов и практик есть у архитектора в данной ситуации? Я ожидал прочитать именно про это...

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

1. Изначально невнятно поставленные цели и задачи.

2. Необходимость коммуникации с большим количеством стейкхолдеров.

3. Размывание ответственности за конечный результат в целом по проекту.

Какой совет архитектору то? Agile? Каждый директор-рак-лебедь-щука не знает точно куда ему тянуть свою часть, не говоря уже об общей картине. И тут архитектор говорит: "а давайте по чуть-чуть" и сразу всё наладилось? Они так и не сдвинутся с места (проверенно и не раз). И второе, что нас интересует - это CI-CD? Если б было так сказочно, то и архитектор не нужен. Коучей хватает, а вот заводы стоят.

Единственное, что верно подмечено - это ИБ. Все эти важные держатели стейков всегда забывают спросить безопасников. А те в свою очередь будут тешить своё ЧСВ, заявляясь нежданно в середине процесса и требуя всё переделать, остановить и сертифицировать.

Я думаю, что реальной альтернативой лицензионной версии Adobe станет пиратская версия. Хотя я не знаю насколько пользователи зависят от онлайн и облачных сервисов.

V2X (vehicle-to-everything) определяет вибрационное воздействие от
пешеходов, дорожных препятствий, открытых люков и других машин.

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

Ну так ответ прост до невозможности - перестать использовать микросервисы там, где им не место. Остальное решается на уровне бизнеса. Много версий не хотите - в соглашений Х поддерживаемых и автоапгрейд или заморозка. 1-3 секунды пару раз в день - прописываем в рамки SLA "95% запросов" и т.д.

Information

Rating
Does not participate
Location
Тель-Авив, Израиль
Date of birth
Registered
Activity