Size: a a a

Архитектура ИТ-решений

2020 October 12

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Ivan
Совершенно верно. Я там где-то и говорил, что это дело системной архитектуры.
Ну вот, а тут чат про другую профессию, ващет
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Ivan
Ну не могут же они экспоненциально бездельничать)
Так почему бездельничать-то? Расстроенные, искренне тупят, ошибаются и переделывают.

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

I

Ivan in Архитектура ИТ-решений
Alexey Pryanishnikov
Ну вот, а тут чат про другую профессию, ващет
Я не говорил, что этим должен заниматься солюшн. Я говорил только о том, что это задача архитектуры. И я не говорил, что архитектор должен кодить. Но он должен уметь кодить, или, по крайней мере, понимать потребности команды и обеспечить эти потребности нужной информацией.

За ссылку на чат системных архитекторов был бы признателен.
источник

I

Ivan in Архитектура ИТ-решений
Denis Zarin
Так почему бездельничать-то? Расстроенные, искренне тупят, ошибаются и переделывают.

У меня однажды супер опытный, но расстроеный тим лид отверткой в сервер ткнул. Все живы, к счастью, просто блок питания взорвался. Сервер был с исходниками, это ещё до облаков.
Ну да, я об этом не подумал. Если протыкать системники отверткой, то экспоненту достигнуть таки можно 🙂))
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Ivan
Ну да, я об этом не подумал. Если протыкать системники отверткой, то экспоненту достигнуть таки можно 🙂))
Звучит сюрно, но я как менеджер многому научился на этом кейсе.

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

Это я к тому, что как у нас люди появляются в рассмотрении, сразу все невиданную глубину обретает. Да что я, ДеМарко все сказал..
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Ivan
Я не говорил, что этим должен заниматься солюшн. Я говорил только о том, что это задача архитектуры. И я не говорил, что архитектор должен кодить. Но он должен уметь кодить, или, по крайней мере, понимать потребности команды и обеспечить эти потребности нужной информацией.

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

I

Ivan in Архитектура ИТ-решений
Denis Zarin
Звучит сюрно, но я как менеджер многому научился на этом кейсе.

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

Это я к тому, что как у нас люди появляются в рассмотрении, сразу все невиданную глубину обретает. Да что я, ДеМарко все сказал..
Согласен. Но есть и другая сторона. Разработчик 90% времени читает код и получает представление о том, как устроена система, и это в том случае, если программа обладает хорошим внутренним качеством. Я в свое время писал на emacs, и многие мои друзья писали на emacs, и там по логу можно легко в этом убедиться.

Иными словами, 90% времени осуществляется достижение коллективного понимания того, как устроена система. А именно в этом и заключается архитектура, как утверждал Рольф Джонсон, - в коллективном понимании того, как устроена система.

Таким образом, архитектура на 90% оказывает влияние на velocity. Дальше можно долго рассказывать про Coupling&Cohesion, управление сложностью, пределы краткосрочной человеческой памяти, роли типовых решений в коллективном понимании устройства системы, системном мышлении, цикломатической сложности и т.п.

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

В общем, если с velocity беда - то это проблема архитектуры, ну, если только дело не в отвертке в системнике. Системной архитектуры, разумеется.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
У меня просто немножко пригорает, что в чате с определённого момента слишком много про кодинг, как будто свет клином на нём сошёлся
источник

I

Ivan in Архитектура ИТ-решений
Alexey Pryanishnikov
У меня просто немножко пригорает, что в чате с определённого момента слишком много про кодинг, как будто свет клином на нём сошёлся
Значит, назрел чат по системной архитектуре. Я, кстати, просил ссылку на него, если он есть.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Ivan
Согласен. Но есть и другая сторона. Разработчик 90% времени читает код и получает представление о том, как устроена система, и это в том случае, если программа обладает хорошим внутренним качеством. Я в свое время писал на emacs, и многие мои друзья писали на emacs, и там по логу можно легко в этом убедиться.

Иными словами, 90% времени осуществляется достижение коллективного понимания того, как устроена система. А именно в этом и заключается архитектура, как утверждал Рольф Джонсон, - в коллективном понимании того, как устроена система.

Таким образом, архитектура на 90% оказывает влияние на velocity. Дальше можно долго рассказывать про Coupling&Cohesion, управление сложностью, пределы краткосрочной человеческой памяти, роли типовых решений в коллективном понимании устройства системы, системном мышлении, цикломатической сложности и т.п.

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

В общем, если с velocity беда - то это проблема архитектуры, ну, если только дело не в отвертке в системнике. Системной архитектуры, разумеется.
Иван, сорри, что я через 3 уровня сейчас прыгну.

Меня вот что беспокоит, когда появляется твердая цепочка рассуждений вроде архитектура >>velocity >>экономика.

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

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

I

Ivan in Архитектура ИТ-решений
Denis Zarin
Иван, сорри, что я через 3 уровня сейчас прыгну.

Меня вот что беспокоит, когда появляется твердая цепочка рассуждений вроде архитектура >>velocity >>экономика.

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

И уже невозможно такие прямые цепочки каузальные построить, а получается балансировка невероятная. Вот в это как-то больше верится, глядя на мир вокруг.
Включает != ограничивается этим. Есть более 150 определений архитектуры, и даже стандартизованное определение периодически изменяется.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Ivan
Согласен. Но есть и другая сторона. Разработчик 90% времени читает код и получает представление о том, как устроена система, и это в том случае, если программа обладает хорошим внутренним качеством. Я в свое время писал на emacs, и многие мои друзья писали на emacs, и там по логу можно легко в этом убедиться.

Иными словами, 90% времени осуществляется достижение коллективного понимания того, как устроена система. А именно в этом и заключается архитектура, как утверждал Рольф Джонсон, - в коллективном понимании того, как устроена система.

Таким образом, архитектура на 90% оказывает влияние на velocity. Дальше можно долго рассказывать про Coupling&Cohesion, управление сложностью, пределы краткосрочной человеческой памяти, роли типовых решений в коллективном понимании устройства системы, системном мышлении, цикломатической сложности и т.п.

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

В общем, если с velocity беда - то это проблема архитектуры, ну, если только дело не в отвертке в системнике. Системной архитектуры, разумеется.
Примеры без отвертки --

-- ИБ продавили новую политику утверждения деплоев
-- внедрили новую систему заполнения таймшитов и всех заставили заполнять по 15 минутным слотам
-- перевели на удаленку, но конфколлы через сервера компании, все тормозит / отваливается
-- новая политика по кадрам -- нанимаем только условно бесплатных интернов ближайший год
-- etc

Это все про архитектура >> velocity.
источник

F

Fagor in Архитектура ИТ-решений
1) разве системник и возможность лида ткнуть туда отверткой не есть часть архитектуры решения? Да и вообще заказ наряд (допуск лида) в состоянии аффекта не есть как раз таки проблемой в архитектуре решния. Ведь явно "Что то пошло не так"
2) Кодеры сейчас очень токсичны, от того и появляется перекосы, они слишком агрессивны, в части что код это все в информационной среде. Это влияет и на другие сферы.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Ivan
Значит, назрел чат по системной архитектуре. Я, кстати, просил ссылку на него, если он есть.
Ну так кто мешает создать? Вперёд
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Fagor
1) разве системник и возможность лида ткнуть туда отверткой не есть часть архитектуры решения? Да и вообще заказ наряд (допуск лида) в состоянии аффекта не есть как раз таки проблемой в архитектуре решния. Ведь явно "Что то пошло не так"
2) Кодеры сейчас очень токсичны, от того и появляется перекосы, они слишком агрессивны, в части что код это все в информационной среде. Это влияет и на другие сферы.
1. Это хороший заход, но нет))
Так можно до чего угодно довести, хоть до изъянов в западной модели цивилизации

2. Не совсем понял, сорри
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Fagor
1) разве системник и возможность лида ткнуть туда отверткой не есть часть архитектуры решения? Да и вообще заказ наряд (допуск лида) в состоянии аффекта не есть как раз таки проблемой в архитектуре решния. Ведь явно "Что то пошло не так"
2) Кодеры сейчас очень токсичны, от того и появляется перекосы, они слишком агрессивны, в части что код это все в информационной среде. Это влияет и на другие сферы.
Идея тестировать на психическое состояние при выдаче доступа настолько богатая, что я пожалуй не хотел бы дожить до некоторых вариантов её реализации )
источник

F

Fagor in Архитектура ИТ-решений
1) как посмотреть, но допуск лида к системнику это нарушение. А решение системника под ногами лида, это просчет архитектуры. 2) код это имплементация, кирпич хороший материал, но он не есть здание, он лишь материал. А кодеры сейчас в стадии "возведения кирпича до уровня среды обитания", примерно так. 2.1) их винить не стоит, так больше платят, почему бы и не продавить. Ну рынок откинет их назад, но это будет чуть позже и они этого не заметят.
источник

F

Fagor in Архитектура ИТ-решений
Alexey Pryanishnikov
Идея тестировать на психическое состояние при выдаче доступа настолько богатая, что я пожалуй не хотел бы дожить до некоторых вариантов её реализации )
Доживем. По поведению объекта в кадре уже тестируют выдачу допуска, по заказ нарядам, в зону производства работ. Пока только при производстве danger работ, голубых воротничков. Потом и в офисы завезут.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Fagor
1) как посмотреть, но допуск лида к системнику это нарушение. А решение системника под ногами лида, это просчет архитектуры. 2) код это имплементация, кирпич хороший материал, но он не есть здание, он лишь материал. А кодеры сейчас в стадии "возведения кирпича до уровня среды обитания", примерно так. 2.1) их винить не стоит, так больше платят, почему бы и не продавить. Ну рынок откинет их назад, но это будет чуть позже и они этого не заметят.
Я не очень понимаю, как вы без контекста делаете заключение, что это неправильно.

А сервер на тигра выменивать, к слову, это ложится в стандартные практики?
источник

I

Ivan in Архитектура ИТ-решений
Denis Zarin
Примеры без отвертки --

-- ИБ продавили новую политику утверждения деплоев
-- внедрили новую систему заполнения таймшитов и всех заставили заполнять по 15 минутным слотам
-- перевели на удаленку, но конфколлы через сервера компании, все тормозит / отваливается
-- новая политика по кадрам -- нанимаем только условно бесплатных интернов ближайший год
-- etc

Это все про архитектура >> velocity.
То, о чем вы говорите, больше относится не к velocity, а к фокус-фактору.

Я приведу другую ситуацию. Прихожу я как-то на один проект из NYC, а там 90% бюджета - багфикс. Баг на баге. Раз восемь я наблюдал там взаимно-компенсирующие баги. При этом все разработчики из кожи вон лезли, и никто не отлынивал от работы. За 4 месяца ели-ели выплюнули только одну фичу, сорвав сроки на 2 месяца. Команде просто банально не хватало знаний в области системной архитектуры, а доменная область была достаточно сложной.

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