Ну вот, а тут чат про другую профессию, ващет

Так почему бездельничать-то? Расстроенные, искренне тупят, ошибаются и переделывают.

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

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

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

Ну да, я об этом не подумал. Если протыкать системники отверткой, то экспоненту достигнуть таки можно 🙂))

Звучит сюрно, но я как менеджер многому научился на этом кейсе.

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

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

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

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

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

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

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

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

У меня просто немножко пригорает, что в чате с определённого момента слишком много про кодинг, как будто свет клином на нём сошёлся

Значит, назрел чат по системной архитектуре. Я, кстати, просил ссылку на него, если он есть.

Иван, сорри, что я через 3 уровня сейчас прыгну.

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

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

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

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

Примеры без отвертки --

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

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

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

Ну так кто мешает создать? Вперёд

1. Это хороший заход, но нет))
Так можно до чего угодно довести, хоть до изъянов в западной модели цивилизации

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

Идея тестировать на психическое состояние при выдаче доступа настолько богатая, что я пожалуй не хотел бы дожить до некоторых вариантов её реализации )

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

Доживем. По поведению объекта в кадре уже тестируют выдачу допуска, по заказ нарядам, в зону производства работ. Пока только при производстве danger работ, голубых воротничков. Потом и в офисы завезут.

Я не очень понимаю, как вы без контекста делаете заключение, что это неправильно.

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

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

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

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