IT Hurtz

В этом кстати есть не только минусы. Но главный - тот же, что и был у технодрочеров таких людей до ИИ: они начинают заниматься не своей работой, а своей заниматься перестают🤷
Оно и понятно, поиграться в «более сложные задачи» все хотят

З.Ы. Всем, кроме разработчиков, ИИ и «агентская разработка» дали возможность еще больше поиграться в техничку. Если раньше аналитикам приходилось рассказывать, что они ну совершенно точно должны уметь настраивать кафку или придумывать новые микросервисы, а менеджерам нужно было как-то оправдывать, что они хотят в презентации рисовать базу данных, интеграционные сервисы и компоненты, а не функциональные блоки и подсистемы, то теперь можно с чистой совестью рассказывать, что всем очень нужно лезть в репозитории исходного кода, «генерировать архитектуру» и что-то прастихоспади поставлять в прод)))

З.Ы.Ы. Отвечать на вопросы, что такое архитектура, и зачем им нужно лезть в код, ИИ-шка до сих пор не помогает)

Будучи искренним ИИ-оптимистом в сложных «трудовых функциях» ИТ-деятельности, не могу не заметить прикол.
• аналитики на своих докладах про «ИИ для аналитиков» рассказывают, что аналитики с помощью ИИ будут делать всё, вплоть до вывода в прод, но «аналитики, конечно, останутся»
• разработчики на своих докладах рассказывают, что разработчики могут делать всё с помощью ИИ, но «разработчики, конечно, никуда не денутся»
• архитекторы/ продакты/ менеджеры рассказывают…
Ну вы поняли.

А я скромно напоминаю…

Что такое "преждевременная оптимизация" наглядно в реальном мире?

Это например скоростной лифт в 8-этажном офисном здании, где люди сидят почти на каждом этаже. В итоге лифт по пути с первого до последнего этажа стабильно останавливается несколько раз через 2-3 этажа, а то и на каждом этаже в начале и конце рабочего дня. А так как лифт скоростной, то с каждым таким стартом и остановкой пассажиры испытывают шикарные ощущения🤮. И всё это ради того, чтобы между этажами лифт ехал не две секунды условно, а половину секунды (что вообще не имеет смысла в большинстве случаев).

Вы можете возразить, что аналогия некорректная, потому что здание из 8-этажного не станет в будущем 50-этажным, а вот в случае с оптимизацией информационной системы такое может произойти легко. На это я вам отвечу, что:
▪️ Во-первых, в информационной системе и "лифт" с обычного на скоростной можно было бы в будущем поменять, в отличие от здания. Нуу и проектировать надо так, чтобы лифт можно было действительно поменять в будущем, а не сносить для этого половину несущих конструкций.
▪️ А во-вторых, у меня от этих покатушек на лифте голова разболелась, что вы мне сделаете, я в другом городе и т.д.😁

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

С одной стороны сейчас из каждого утюга и от каждого работодателя летит, что мы все должны поголовно использовать ИИ для решения профессиональных задач, чтобы «оптимизировать свою работу» (как будто на перенасыщенном ИТ-шниками рынке, который резко схлопывается от отсутствия бюджетов и как следствие задач, есть необходимость оптимизировать загрузку этих ресурсов, ага). То есть как бы работодатель - осознанно или на волне хайпа - ждет, что все будут использовать ИИ в работе ЛЕГАЛЬНО. И в целом разве плохо, когда соискатель условный разраб придет и скажет, что он тестовое задание написал с помощью какого-нибудь Claude Code и действовал так и эдак? Ну при условии, что это не было задание в стиле классических заданий экзамена на сертификацию по ЯП, проверяющих, насколько программист хороший компилятор, и не допускает ли он синтаксических ошибок в блокноте, которых он бы никогда не допустил, если бы писал в нормальной IDE. И, конечно, если «выполнять задание строго естественным интеллектом» не было условием задания.

С другой стороны если мы говорим о более комплексных задачах (это наверное уже не к собеседованиям разработчиков, больше сисдизайнеров или типа того, но может быть и синьоров тоже), то ИИ в этих задачах может закрыть некоторые «рутинные» куски и опять же вполне легально усилить кандидата, а нам как собеседующим подсветить именно нужные качества, уведя в фон те, которые нам не так и важны.

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

Ну это как тебя учили проводить математические вычисления в уме, потому что «не будешь же ты носить с собой везде калькулятор» - а в итоге калькулятор есть сейчас везд, и проверять умение складывать в уме пятизначные числа не имеет практического смысла. Или более жизненный пример - всякие справочники, которые тоже как бы надо было заучивать, только зачем, если в реальной работе у тебя они есть условно под руками (теперь вот - в виде условных ИИ-чатов), и твоя главная задача - знать, где искать, и знать, что искать. Так-то я и без ИИ считаю, что спрашивать на собесах алгоритмы сортировки, условно, стоит только чисто ради спортивного интереса🤷

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

Вообще тема «читтерства с помощью ИИ» ИМХО - это проблема именно «устаревшего» мышления в восприятии задач.
Если задачу легально (подчеркиваю - легально, эффективно и безопасно) можно решить с помощь ИИ, то проверять, что человек может решить ее без ИИ, конечно, можно. Но скорее всего такие знания и умения уже не должны создавать большого конкурентного преимущества перед человеком, который может решить задачу с помощью ИИ. Пример с вычислениями в уме или заученными справочными данными из моего сообщения ниже - как раз про это.

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

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

А я думал, что времена, когда добавление в описание ИТ-системы/ продукта фразы "микросервисное <anything>" было востребовано, уже прошли...

Одним из деятелей, за которыми я слежу, как я их называю, "ИТ-инфлюенсеров" в области архитектуры для меня определенно является Саймон Браун. Это эксперт в области программной инженерии, автор книги "Software Architecture for Developers" и нотации моделирования программной архитектуры C4. Оставляя за скобками персональное (мои или чье либо еще) отношение к этому способу визуализации архитектуры, можно точно утверждать, что он сделал и делает очень много для вовлечения технических специалистов в программную архитектуру и для распространения ее концепций среди так называемых "практических специалистов". Пускай и через "сделаем какие-то картинки для менеджеров" (даром, что и этим картинки нужны не только и не столько менеджерам, и картинки конкретно в C4 для менеджеров подходят хуже всего).

Активнее всего Браун публикуется в LinkedIn (кто угадает, почему?). И недавно мне там на глаза попалось относительно свежее его выступление на конференции 25го года (которое стало доступно на ютуб канале буквально пару недель назад). Мне показалось интересным, рекомендую посмотреть и тем, кто интересуется C4 и использованием его в работе (как инструментом описания архитектуры для любых задач, см. мой пост по второй ссылке), и тем, кто в целом интересуется темой программной архитектуры.

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

Тезисно интересные мысли подобью тут:
🔹 контейнеры (не путать с контейнерными технологиями, типа Docker, Браун этот термин стал использовать раньше, может доказать) - это абстракция для БД и приложений, взаимодействие между которыми всегда будет межпроцессным. Это хороший критерий для определения границ контейнера - изоляция процессов и взаимодействие между ними. Например, контейнером не может быть некий "сервис", состоящий из Java-кода и MySQL БД, потому что это два разных процесса - следовательно, два разных контейнера.
🔹 кстати про технологии - их на диаграмме контейнеров указывать стоит обязательно, потому что так можно валидировать архитектуру. Например, если нарисовать контейнер с JS, который интегрирован с контейнером с БД, это не может быть реализовано, значит эта архитектура некорректна. Без технологий валидировать арх решение будет сложнее.
🔹 каждый контейнер - это деплоймент-модуль (то, что должно быть развернуто в среде исполнения), но не каждый деплоймент-модуль должен порождать контейнер. Особенно это актуально для инфраструктурных элементов, которым а) не место на структурной архитектурной диаграмме (а диаграмма контейнеров - именно такая), и б) которые "ломают" визуализацию связей и делают диаграмму бессмысленной. Например, рисовать на диаграмме контейнеров брокер сообщений нерационально, так как он убирает визуально полезные связи между приложениями и заменяет их несомненно более точными, то абсолютно бесполезными связями всех с брокером.
🔹 микросервисы - это программные системы или группы контейнеров. Критерий "выделять ли микросервис в систему" по сути такой же, как и в принципе для системы - отдельная команда, отдельный цикл поставки в среду исполнения, отдельная зона ответственности и т.д. (тут с границами системы в целом интересный пойнт, расскажу попозже отдельно)
🔹 вообще в целом границы в моделях C4 - очень полезная штука, с учетом того, что C4 не дает менять состав уровней абстракции (что является и его слабостью для некоторых задач, но и его силой для тех задач, для которых он был создан).

Тему C4 еще зацеплю, не разбегайтесь!

Happy tuesday!

На майских праздниках наши коллеги находятся в одному из двух состояний:
• «до 12го не кантовать»
• «какие праздники, мы 12го в прод идем!»

В каком бы состоянии вы не были (я лично в первом, но так совпало), у вас времени вчитываться во что-то длинное не будет, а у меня - писать (хотя мыслей много есть интересных, отложу). Поэтому закину пока короткий тейк, который считаю интересным раскрутить позднее.

Последний месяц-два в архитектурных онлайн-тусовках (типа чатов архитекторов в телеге) активизировалась рефлексия на тему ИИ. Как обычно в таких случаях, обсуждают, заменит ли ИИ архитектора, меряются болтами, кто какие задачи уже поручает ИИ, кто там за пять минут в клодЭ уже генерит архитектуру небольшого нетфликса яндекса, кто тролль, кто х*й и кто чью мамку *бал. В общем стандартный набор битвы ИИ-филов против ИИ-фобов. Если набраться сил и перечитать эти треды хотя бы по диагонали, несколько интересных мыслей и идей для себя выцепить можно. Я в целом со многими из них согласен, и какие-то на своём «колхозном» уровне даже эксплуатирую (например, писал тут и тут). Но не могу не заметить, что опыту моему и многих моих коллег и друзей/ знакомых на смежных задачах, проблемы в проектах, продуктах и процессах обычно из-за:
• некомпетентного управления людьми (буквально, на роли ИТ-управленцев разного уровня, от конкретных инициатив до стратегического, попадают люди с нулем опыта и системного мышления)
• неадекватного процесса принятия важных (читай - архитектурных) решений, из-за чего условный техдолг настигает не «когда-нибудь в будущем», а прям буквально в следующей итерации
• потери информации
Среди архитектурных задач до сих актуальны задачи типа «выбрать кафку или рэбит», «постгрес лох vs постгрес бох» и «где найти актуальное описание (ХОТЯ БЫ) архитектуры». И никакой ИИ тут не поможет.

Всем интернета!🤟 Скелетор вернется позже с еще одним набором интересных букв

IT Hurtz pinned «Это вторник и на дворе рубрика «пятиминутка рефлексии и нытья»)) Не так давно в очередной раз наткнулся на мысль, что «архитектор это минимум сИньорный разработчик, поэтому техинтервью должен проходить как разработчик, а еще сисдизайн рулит» и словил рефлексию…»

На эту тему у меня есть имхо шикарная история из тех же времен, когда я работал тем самым «инженером-программистом».

На моей кафедре (напоминаю, что я ИБ-шник по образованию) в какой-то момент стали студентов сразу учить C#, вместо Си и ассемблера, который учили мы. Так как кафедра у нас ИБ-шная, то и задачи в курсовых работах даже по программированию были с ИБ-шной спецификой. То есть всякие алгоритмы шифрования, хеширования и прочего (например, я на первом курсе программировал, как сейчас помню, кодировку Quoted Printable, а на третьем - генератор псевдослучайных чисел, либа на Си, Ring-3-приложение - уже загуглили, что это? - на С#).

А я, уже закончив универ, - уже прошло 15 лет, можно открыть секрет Полишинеля - помогал младшим товарищам делать всякие курсовые проекты по программированию, в том числе на C# (потому что изучал его уже самостоятельно - ибо системное мышление и умение обучаться - это вам не хер собачий и «а какой у вас опыт промышленной разработки???»). Помогал - не значит «всегда делал за них», иногда еще задавал каверзные вопросы и заставлял думать самих (да, был душным уже тогда)

И вот значит студенту третьего курса моей специальности дают задачу запрограммировать какой-то алгоритм преобразования чего-то во что-то, где в структуре результата в первых четырех байтах нужно закодировать размер исходного файла. И он ко мне приходит и говорит «а я правильно понимаю, что с помощью этого алгоритма можно обрабатывать файлы меньше 10000 байт?». Я его спрашиваю, почему? Ведь 4 байта - это 2^32, то есть размер файла может быть до 4 Гб (ставь 🤔, если надо объяснить почему). А студент говорит «ну как… 4 байта - это 4 символа, то есть максимальный размер, который можно записать - это 9999…. 10000 уже не влезет»

🤷

Если вы вдруг забыли или не очень интересовались в свое время информатикой, или по статусу неположено, то вот объяснение ситуации. Изучая базовые принципы информационных технологий, устройства памяти и некоторые языки программирования, которые заставляют вас работать напрямую с памятью - и Си и ассемблер к ним относятся - мы понимаем, что на самом деле означает значение байтов памяти и как через них передавать и кодировать информацию. А студенты, которые пропустили эту часть, не пощупали ее руками и сразу стали работать с визуальными технологиями (которые уже тогда предоставлял C#), воспринимали байты только как способ переносить символы. Поэтому для нас 4 байта - это 2^32 степени, а для них - 4 символа, то есть «9999»

Это вторник и на дворе рубрика «пятиминутка рефлексии и нытья»))

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

Уважаемые технодрочеры и фанаты сисдизайна и «show me your code» - а не слишком ли дохера чести гордиться «опытом программирования» в современных ынтырпрайзных фреймворках на этих ваших джавах и тайпскриптах с горой бойлерплейт-кода, готовых модулей и stackoverlow?

Я начинал свою полноценную ИТ-шную карьеру с работы инженером-программистом систем работы с драйверами сетевых интерфейсов в Windows-подобных системах, писал полностью такие системы с системной и пользовательской частью («Имя Ибрагим приложение Ring-0 и Ring-3 вам о чем-нибудь говорит?»), собирал (придумывал) системные требования, проектировал и реализовывал это полностью в одно лицо, и потом документировал руководство пользователя и руководство администратора со скринами - то есть был и аналитиком, и архитектором, и разработчиком, и техническим писателем, еще не зная таких слов. Искал в одной такой системе утечку памяти (когда для разработчиков это было еще важно), считая пары malloc-free по коду. Или разбирался, почему на американской сетевой карте стоит ограничение скорости (спойлер - надо было изменить контрольный БИТ в конфигурации, которая была очень неявно описана в документации).

Я ни в коем случае не считаю, что современная enterprise-разработка - фигня, а тру-разработка - это знать, что такое указатель на указатель. Но нельзя не заметить, что выполнять некоторые «практические» задачи сейчас можно, обладая гораздо меньшей компетенцией, меньшим (или отсутсутвующим) системным мышлением и базовыми знаниями. Да, условный «кодер» пройдет техинтервью сильно лучше, чем архитектор или системный аналитик, потому что он каждый день пишет какой-то код, и возможно, прочитав несколько статей по сисдизайну перед этим интервью, он даже сымитирует «проектирование» гугла с помощью микросервисов на гошечке. Только архитектурные или даже около-архитектурные задачи он от этого решать не начнет, а его «практичность» в итоге приведет к тому, что он будет сам писать 80% кода, который будет «проектировать» (и скорее всего - херово). И будет в лучшем случае средний разработчик там, где нужен архитектор/ системный аналитик. Не похоже, что это то, что нужно современному энтерпрайзу, особенно когда части этих 80% планируют заменить «ИИшкой».

Monday vibes!

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

🔹 starter pack описаний архитектуры, и почему от них никак не избавиться (сильно пересекается с периодом Just decisions из моей презы, см. тут)
🔹 про исключения, подтверждающие правила, при принятии арх решений (немного про вот это)

А еще - никак не связанное с арх решениями (наконец-то) - немного поныть о подходах некоторых специалистов (особенно аналитиков) к надежности, и почему там не всё так просто.

И я еще торчу рассказ про сайзинг (и даже уже придумал к ней шикарную иллюстрирующую картинку).

В общем, я тут

Опубликовали запись вебинара Максима Шаломовича на тему «Не хочу ничего решать — хочу архитектуру!»

Последнее время все говорят о каких-то архитектурных решениях. Ну как «все»… Я говорю 🙂 . Но непонятная задача проектирования архитектуры становится, казалось бы, еще более непонятной.

На вебинаре попробовал собрать в кучу всю основную информацию об архитектурных решениях (design decisions) — что это, как появилось, почему важно и почему недостаточно просто «нарисовать архитектуру», когда об этом просит руководитель проекта или заказчик (а если вы РП или заказчик — разберемся, что именно просить).

Тайм-код вебинара:
00:00 Вступление
00:54 О чем поговорим
02:17 О спикере
03:53 Пара дисклеймеров
07:32 Небольшая предыстория
09:27 Первый этап Just design
15:02 Второй этап Design + decisions
29:46 Третий этап Decisions + design
45:09 Ключевые характеристики архитектурного решения
52:02 Критерии архитектурного решения
54:27 Примеры архитектурно-значимых решений
54:53 Что важно знать об архитектурном решении
56:08 ADR. Типовые шаблоны ADR
59:48 Предварительные итоги
01:02:27 Куда идём дальше? Концепция Just decisions
01:06:39 Рекомендуемый воркшоп
01:09:28 Заключение
01:10:09 Вопросы и ответы

Посмотреть запись можно на нашем YouTube канале

Воркшоп школы SE, который может быть вам интересен:
Структуризация и рационализация архитектурных решений

📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

#вебинары@systems_education

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

Хороших выходных💪💪

Ну и вот вам немного фото из отпуска для привлечения внимания. Байкал не лизал, каюсь

Давайте на примере:

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

Поставь эту задачу группе технически подкованных людей - и они через 15 минут прибегут к тебе с вариантами решений: "шардировать БД, нет, перевести всё на микросервисы, нет, заменить РСУБД на NoSQL, нет, выкинуть БД и перенести всё в облако...". Затем на каждый такой вариант они начнут сами себе задавать вопросы, погружаясь в пучину разветвленного дерева решений - если заменить всё на микросервисы, то какие это будут микросервисы? Может тогда часть БД всё-таки заменить на NoSQL? А если нет, то может это можно шардировать? Но по какому ключу? А что если мы наймем еще 30 новых разработчиков? Обязательно кто-то задаст вопрос "а сколько у нас вообще CPU и RPS?", и скажет, что без этого решить ничего абсолютно невозможно.

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

Скажем, в нашем примере первое решение - выбор стратегии или подхода - или как хотите назовите - по решению задачи "сделать так, чтобы база могла обрабатывать больше запросов без вертикального масштабирования". Все остальные детали - ключ шардирования или количество микросервисов - будут уже потом, сперва надо решить главное (на сейчас).

Или, например, задача "импортозамещения БД", которая часто воспринимается как задача "замена импортной БД на другую", на самом деле чаще звучит как "избавиться от импортной БД" со всем остальным контекстом.

От умения ограничить задачу (problem в структуре любого ADR) и границы (scope/ context) зависит, удастся ли выстроить процесс принятия архитектурно-значимых решений. Это же позволит многие "важные" решения (которые на самом деле - составляющие части других, более поздних решений) отложить на потом, писал об этом тут.

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