Изменения

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

* Стейкхолдеры — при измениях изменениях надо информировать всех заинтересованных

И взяли EAoaP — Enterprise Architecture on a Page, который родился из критического взгляда на большие фреймворки с 2 м 2м артефактов. В нем всего 6 блоков и 24 артефакта, из них 8 обязательных. И он пытается не делить слои артефактов, а сохраняет смесь бизнеса и ИТ — это важно.

Блокам Vision, Outlines (бизнес-идеи), Lanspape Landscape (ландшафты) и Design явно нужна иерерхияиерархия, для Standards и Consideration она не критична. В лоб поддерживать иерархию, связывать — утопично. Поэтоу Поэтому их идея — создавать Inventory — хранилище, чтобы оно связывало артефакты. Отслеживаем связи и формируем представление на единых витринах, например business capability и реализация продукта. Для этого все артефакты — машиночитаемые. AsIs собираем с ландшафта, а мы описывает только ToBe.

* Концептуальная модель данных — стандартизованнастандартизована, в отличие от логической, потмоу потому что они менее детальны: какие объекты и кто владелец. Сделан inventory.

* Inventory business capability — бизнесовая? , делают еще упакованные

* Inventory CJs — на инициативы смотрим через ustomer customer journey* Cравнение Сравнение вариантов — для любых выводов ADR, для design тоже. Цели (критерии) выбора, варианты, результат выбора.

* Цели и capabilities — основаня основаная точка синхронизации Бизнес-ИТ.

В целом EAoaP — неплох, точно лучше TOGAF. Минусы — тоже есть. Они нивелируются машиночитаемым подходом. Inventory вам в помощь. Единые репозитории — чтобы все время было актуально, чтобы описание жило. Единый репозиторий всегда смотрит связки по горизонтали. И показывает картину на уровне домена, которой из отдельных систем не получишь. Трудозатраты на создание — побольше, потому что машиночитаемй машиночитаемый формат, а не на салфетках. А экономят — именно актуализацию и разбор по взаимосвязям.

Это история 2.5-3 года. Бизнес — сам пришел. Телеком как core классно, но дальше надо развиваться в разные стороны. Разговор про деньги и value, связь с целями. И когда инициатив, продуктов и проектов много, в этом надо как-то навигироваться. Наполнение — в процессе. 600 продуктов, всех заставить нельзя. Начали создавать quality gate в процессах, которые побуждают делать в обмен на профит — ускорение согласования и так далее. Сейчас 2/3 продуктов как-то пристуствуютприсутствуют.

Почему для разработчика взлом — странная деятельность? Потмоу Потому что у него другое мышление.

* Хакер независим (даже в команде работают индивидуально), а разрработчик разработчик работает в командем команде и есть взаимная зависимость результатовс коллегами* Хакеру достаточно найти один баг, разработчик должен недопустить не допустить ни одного

Дальше был кейс, на типовом api работы с пользователями: register, login, logout, change (account), reset_pwd. И для каждой выписаны варианты взлома, которые видит хакер: sql-инъекции там, где есть запись в БД, подбор паролей и так далее. По-сути, можно рассматривать его работу как программирование на вирутальном виртутальном вычислители, в роли которой выступает ваш софт, а его цель — написать программу, которая ломает приложение. Хакер ищет возможности, которые разработчик не предусматривал. Разработчик, когда пишет код, ориентируется на необходимость, и не проверяет, не сделал ли больше, чем нужно. Пример: интерпретатор арифметических выражений делаем через eval — калькулятор есть, но там много дополнительных возможностей, включая запуск произвольного кода. Уязвимости десерриализации — десериализации — передать им серриализованный сериализованный объект, так что десерриализация десериализация выйдет за пределы предусмотренного, вызывались какие-то методы. И так далее.

Этот доклад поначалу вызвал разочарование фокусом на сложностях поддержки на большом масштабе, а не на применяемых решениях. Возникло даже ощущение, что весь доклад может оказаться рассказом о том, как «наши космические корабли бороздят просторы Большорго Большого театра» (был такой мем эпохи застоя). Но потом стало видно, что Алексей раскрывает схемы многоуровневой эшелонированной обороны: мониторинг состояния приложений, призванный сигнализировать о проблемах до того, как они возникают; мониторинг обращений пользоателей пользователей как индикатор потенциального возникновения массовых проблем; support 24*7 для реакции на кризисные ситуации, механизмы предотвращения ситуаций, в которых служба поддержки захлебывается в решении проблем; единый календарь релизов со световорной светофорной моделью, позволяющей их приостановить и так далее. И в рассказе были средства, используемые для конкретных целей: Sage, FineDog, Kolobok и другие.

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

D докладе были подробно рассмотрены механизмы транзакций в Kafka и YDB, но это я пересказывать не буду. Смотрите слайлды слайды и документацию, разбирайтесь. По-хорошему тут нужны схемы, при чем такие, чтобы было понятно — что происходит в сложных случаях, например, при падении экземпляра. А их, увы, не блыобыло. Жаль. Но все равно, я послушал с большим интересом.

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

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

Почему сложность важна? Она определяет время добавления фичей и исправления багов, требованяи требования к квалификации разработчика. Сложность копится техническим долгом, ее легко повысить, но сложно понизить. Можно лишь сдерживать стандартами. Трехмесячные курсы тут не работают, работают код ревью, стайл гайд и линтеры. Но это — инвестиции.

И не похоже, что ИИ — это новое визуальное программирование, распространение реально идет снизу-вверх, хотя, как всегда, есть скептики. Правда, отмечу, что от человека требуется базовое понимание констркуцийконструкций. Императивные и объектные языки достаточно похожи, и тут возможно примерное понимание. Но вот функциональная парадигма отличается сильно, а ее сейчас можно использовать не только в специальных языках, типа xsl, Schema или Haskel, но и во вполне известном C#, куда ее в 2008 втащили вместе с реляционной, чтобы сделать linq. Асинхронные конструкции тоже требуют соответствующего мышления. И я сомневаюсь, что у ИИ получится понятно объяснить. То есть нужна некоторая база. В теории, ее надо выделить и учить именно ей, в небольшом объеме. На практике, вряд ли это сделают, образование — консервативно, а большие крусы продавать выгоднее — понятно, за что берешь много денег. Хотя есть те, кто занимается обучением детей — может, они сделают. Так что, думаю, стоит следить за этой веткой образования.

А еще, говорят, есть нюанс. Есть исследование UpLevel, что использование прораммистами программистами нейросетей дает +41 % багов и не увеличивает перемалывание тикетов. Я бы тут заметил, что это закономерно, если учитывать, что хорошие GPT появились недавно. Исследование говорит лишь о том, что работа в паре с нейросеткой тоже требует навыков. и эти навыки отличаются от работы в одиночнкуодиночку. Это как сравнивать эффективность разработки на новом языке или фреймворке и на давно знакомом. Для любого языка и фреймворка есть время наработки хороших практик. и оно тем больше, тем больше различие.

В конце доклада было награждение победителей конкурса красоты кода 2.0, который проводил Сбер. По-видимому, именно это дало название докладу, которое стало не соответтсвовать соответствовать содержанию: про красоту кода в нем не было, речь шла лишь про понимание и когнитивную сложность. А это — разное. Может быть простой и уродливый код, а может — сложный, но красивый — когда его, наконец, поймешь.

Это был технический рассказ про внутреннее устройство движка Picodata — открытой, распределенной in memory базы данных, написанной на rust. На каждом инстансе используется Tarantool, они сделали fork и его развивают, а задача picodata — Picodata — оркестрация этих инстансов и обеспечение согласованной работы.

Если же распределение различно, то join надо выполнять на узле-координаторе, и тут два варианта: можно сделать отдельные запросы. и потом сделать hash или merge join по выбранным данным, а можно сделать запрос по одной таблице, а потом использовать полученные значения ключей как условия для выполнения запроса по другой, это может быть эффективно, если епервый первый запрос вернул мало записей. Для этого в дерево вставляются motion-узлы передачи данных между узлами.

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

А теперь — конспект доклада. В ИТ Райффайзена 3700 отрудников сотрудников 262 команды и много сообществ. Матричная структура: команды распределены по бизнес-доменам, а сообщества объединяют специализации.

Основаня Основная метрика — pain index, мера, как мы делаем больно клиенту. Она показывает стабильность — развернули сырое, уронили качество.

В 2019—2021 они внедряли стандратыстандарты, а в 2022 перешли от стандартам к лучшим практикам и созданию инженерной культура.

В 2019 была создана Acceleration team? ее цель — внедрять dora-метрики и практики. Нужна цель и слоган, близкий командам, им стало развитие технологического совершенства. ИТ-стандарты — лучшие практики разработки и эксплуатации. А еще упрощение внутреннего рекрукментарекрутмента, подъем технической зрелости и повышение качества и стабильности кода.

Начали с continious continuous integration и автотестов. Процесс разработки построен на основе trunk based development с короткоживущими ветками. На pull request выполняется code review, проверяются критерии качества кода, выполняется сборка с прогоном автотестов. Всего 4 практики. Первый год внедрения: 58 % команд в статусе unknown. В остальных 2-3 из 4.

В 2020 был начали использовать continious continuous deployment projects, переходить на gitlab с attlasian и добавили фокус на логгирование логирование и мониторинг в продуктах. Тогда было 146 команд, использование практик увеличивалось.

В 2021 появилась внутренняя платформа разработки, на которой автоматы сборки и проверки, покрытие увеличилось, хотя команд тоже стало больше. Прогресс — за счет инструмента gitlab, и команды accelertion acceleration team, это из team topologies.

В состав практик добавили disaster recovery — восстанавление восстановление при падении. Проверка — тестируемый сценарий DRP, фактические знанения значения RTO и RPO, и тест.

* relibility reliability и resiliency (R&R), avalilability — availability — доступность сервиса.

Но для себя они по результатам исследования решили, что ориентация на культуру — верная. Культура: общества, организационная, инженерная. Культура влияет на эффективность. Для бизнеса эффективность — коммерческий успех. А еще некоменрческий не коммерческий успех, эффективность команд, благополучие людей — 4 ключевые метрики. Эффективность поддерживает: организационная культура, технологии, инженерная культура, и навыки. Все это накладывается на модель — есть маппинг.

Технические возможности и навыки взяли из модели SFIA, люди оценивают сами себя. Кто не в курсе — [https://sfia-online.org/ SFIA], Skill Framework of Information Age — модель, на которой образование договаривается с бизнесом: чему учить, какие есть специализации, что они содержат. Первоначально появилась в Великобритании, с ейчас сейчас используется в большом количестве стран и развивается. В ней более 120 навыков, по каждому из них описаны уровне владения, которые выровнены между собой по 7 большим уровням. И для каждого уровня — интегральное описание самостоятельности сотрудника, сложности решаемых задач, знаний, способности влиять на других и понимать бизнес.

Чтобы дерево выросло — надо его посадить. Культура необзательнанеобязательна, но надо настойчиво рекомендовать, показывать пользу. Трассировки практик до бизнес-показателей нет, это цель следующего года. Оно необходимо. Без этого есть мнение техлида (и других членов команды) против других мнений, а команды автономны.

В докладе было описание общих механизмов, сравнение разных технологий и хороший обзор конкретных средств, который я не буду пересказывать: если эта задача интересует вас в рамках конкретного проекта, то там важны детали, и надо смотреть доклад, а не конспект, и другие материалы. Из интересного хочу отметить сравнение доступа к внешним данным через включение редств средств внутрь приложения и исполнением в одном процессе против использования внешнего приложения. Первое явно быстрее, однако сильно снижает устойчивость, поэтому его нельзя рассматривать как однозначный плюс. А еще Виталий рассматривал возможности YDB как средства организации федеративного доступа к данным, без акцента на хранение в ней, и считает ее одним из лидеров, наряду с Trino и ClickHouse, если говорить о развертывании на своих серверах, а не в облаке.

Разработка YDB началась потому. что имеющиеся базы не справлялись. и Яндекс решил сделать свое. В ней смесь построчного и поколоночного хранения, управляемого пользователем, есть автоперекладка из плоской таблицы в поколоночную. И нужен был стоимостной анализатор для эффективного выполнения запросов. Павел рассказывал внутреннее устройство, с большим количеством технических подробностей про варианты используемых алгоритмов. Мне было интересно: я много лет работал с Oracle, и его оптимизатор неплохо представляю. Но пересказывать в конспекте я не буду, если интересно — смотрите доклад. Потмоу Потому что при пунктирной записи очень легко ошибиться.

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

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

Дальше усложнения. Вместо word индекс используют триграм-индекс — разбивка слова по три символа, это нужно для автоподсказок, он есть в Code Search, поэтому удобно перейти на него. Еще для файла строим локальный resolve index, чтобы показывать поплярные популярные имена, типва типа err. Языково-зависимые эвристики для улучшения результата, например, декларация в том же пакете, если она есть. Полный resolve-индекс для пакетов и типов. И так далее. И различные оптимизации: индекс деклараций позволяет не заглядывать в файлы. Можно не хранить полный индекс для каждой версии, а хранить его инкремент, но тогда при запросе надо добежать до снапшота, стратегия может быть различной. И так далее, много деталей о том, как постепенно усложняли функционал от MVP.

Это был очень нетипичный доклад. Катя много работает с финтехом. И он — везде одинаков, специфика стран и банков очень мала. И везде — одни и те же проблемные конструкции, которые вызывают раздражение. О них и был рассказ. Катя пробовала сменить домен, ушла в интернет-торговлю, но финтех ее там настиг: пришлось делать интеграцию со Сбер-спасибо. В общем, она продолжает оставться оставаться в финтехе и дальше.

Я хочу отметить, что сам уже почти 30 лет работаю с банками, и примерно 2/5 проектов с ними. Еще 2/5 — торговые компании, а остальное — другие домены. И конструкции, о которых говорила Катя, мне знакомы. Но ненависти не вызывают, для меня это просто особенности предметной области. которые надо учитывать. Тем более, что часть из них, например, с округлением, плохим интернетом, протоколами интеграции или тестовыми данными от домена не зависят. Их причины вообще не в домене, а в мышлении разработчиков, которые придумали какие-то кривые решения, а потом с ними надо жить. При чем бывает, что исходная система, от которой унаследовано кривое решение, уже много лет как выведена из эксплуатации, но поскольку это важно в протоколы интерации интеграции десятка других систем, потому что часть из них когда-то интегрирвоалась интегрировалась с той системой, то теперь решение живет, реинжиниринг — дорог и чреват ошибками.

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

СМЭВ — система межведомственного электронного взаимодействия в России. Почти унифицированный транспорт в России. Проблема: (а) иногда сервис падает и (б) понять как работает можно только эмпирически. Есть доки СМЭВ и отдельно — каждого ведомства. Есть лимиты на обращения от СМЭВ и от министерства, и вас могут случайно отключить до конца месяца за превышение. А еще СМЭВ работает с высокой доступностью, но не гарантирует, что все ведомства к ней подключены постоянно, это дело ведомств. При отсутствии доступа сервисы соответствующих ведомств не отвечают, и перестают отвечать некоторые интегральные сервисы, объединяющие несколько ведомств. напрмиер, например, проверки документов. И если ты хочешь автоматически обрабатывать документы, то помимо полной проверки надо дублировать функционал, выполняя частичные проверки.

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

Кривые решения по идентификации клиента, особенно человека. Люди меняют документы, правовой статус, номера телефонов, а когда-то давно меняли ИНН, связывая его с конкретной налоговой. Но смена телефона — вообще часто, а во многих системах телефон почему-то делают ключом со всеми вытекающими последствиями, а для бизнеса историю взаимоотношений сохранять — важно. А еще один человек — многоликий клиент, он открывает счета и депозиты, берет кредиты и ипотеку, оформляет страховки, пользуется депозитными ячейками, торгоует торгует через банк на финрынках. Разные услуги накладывают разные требования, и с этим надо корректно разбираться. А часто разбираются криво, особенно если часть услуг обеспечивают или когда-то обеспечивали legacy-системы. Тут еще засада, что когда вы перешли на новую систему депозитов, например, в которой решили хранить данные лучше прежневопрежнего, люди к вам не пришли заново, система должна работать с тем, что есть.

Retry на получение timeout, когда возможно повторное исполнение операции — это прикольно. Особенно, когда отправляешь платежи. а связь — ненадежна — можно заплатить много-много раз, пока у клиента есть деньги. При чем так поступить может банк клиентаи клиентами или платежная система, общаясь с корреспондентом. А клиент узнает по факту. У них это всплывало на платежах в Африку, там есть страны с ненадежным интернетом. Отмечу, что проблема общая. У нас протокол, по которому налоговая получает инфу от фискальных регистраторов, тоже не обеспечивает идемпотентность операций, а сами регистраторы управляются прошивками, в которой есть баги. И мы писали специальные эвристики и сложные протоколы, чтобы с этим разбираться. А еще я несоклько несколько раз развлекался в Сапсане, покупая билеты в театр через мерцающий интернет, которые не держит соединение — тоже прикольная задача.

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

Кэшбек. Если берете карточку, покупаете дорогую куртку, получаете кэшбек. Есть закон, что возврат можно запросить на другую карточку или нал. Да, так оно и есть, но лично я не вижу тут проблемы. НоОтмечу, кстати, что возврат на нал — это проблема еще и для торговой точки. потмоу , потому что есть нормативка, по которой нельзя возвращать наличные из кассы — просто чтобы этот способ не использовали для массового обналичивания. Это не значит, что вернуть нал вообще нельзя, это значит, что по бухгалтерии он проводится хитро, так что операцию не может выполнить кассир.

Надо оплатить в Турции по счету в юанях, но через Россию. Двойная конвертация, сумма отличается от прямого пересчета, что логично. А если карточка в долларах — то тройная. При этом применяются внутренние курсы банков, которые могут быть очень разные. Замечу, что юань тут не при чем, еще до этих событий во многих странах банкоматы или терминалы оплаты предлагали провести операцию в длолларахдолларах, а не в местной валюте, а их курс показывал их жадность. Хотя, возможно, в конкретном случае она была меньше жадности крупных международных банков, и клиент мог выбирать.

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

Бесмысленная Бессмысленная экономия. Вместо готового решения, например, по интеграции с налоговой или ЦБ, написали свое — потому что несложная задача. Но дальше протоколы-то меняются, и все это надо поддерживать — у вас продукт с командой сопровождения и никакой экономии. Тоже типовой случай не только в финтехе, 1С популярен именно потому, что поддерживает изменения законодательства, но он реализует типовые сценарии, и если у тебя что-то уникальное — изволь сам сопровождать. И это — баланс.

Куда расти дальше? Архитектор, тилид, стартапер. В крупном enterprise — ответственность за несколько проектов (staff enineerengineer), глава практики principal engineer, и есть мифические люди, которые драйвят отрасль.

Дальше было достаточно подробное описание скиллов для разных уровней, с расширением на смежные компетенции. Я записывал, но здесь воспроизводить не буду: Виталий говорил быстро, так что в записи — лакуны. А в презентации все есть, смотрите. При этом есть оговорка: матрицы из презентации — для бигтеха, где ситуация примерно одинакова. Он как консультант делает матрицы компетенций для небольших компаний, и там радикальные отличия. обуслваливаемые , обуславливаемые спецификой компании. Учтите это, если будете использвоать использовать для себя.

* рост запрплаты зарплаты по пользе

* и технику и софты — довести до автомтизмаавтоматизма, без проблем

* разбиратсья разбираться в процессах

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

* Быстрый рост проекта без архитектуры. Стартап сделаем быстро, выйдем на рынок, остановимся и отрефакторим — так не бывает, остановитсья остановиться нельзя, надо бежать за конкурентами.

ВообщеОтмечу, кстати, что Макс Дорофеев как-то пошутил, что ИТ — единственная детяльностьдеятельность, где на костылях быстрее, чем без них. Правда, у него дальше раскрывалось, что это — заблуждение, что реальная скорость требует достаточно продуманных решений просто потому, что бизнес никогда сразу не знает, как нужно, вы несколько раз дорабатываете, а чтобы это сделать быстро — надо заложить гибкость. Но это было отступление от темы.

** Разделение задач и оценка трудзатрат трудозатрат (включая аналитику и общение со стейкхолдерами)

** Оценка затрат на остутствие отсутствие изменений — как будет ухудшаться

Безопасный реакторингрефакторинг

* решения сегодня, которые могут быть пробемами проблемами завтра

* http-сервер. Хендлеры обрабатываются конкуретно — конкурентно — но этой конкурентностью окно внимания не перегружается, реализация скрыта

* for{select} Как в ticker — простые блоки, понятно называются и понятно что делают. Объединение в отдельный слой. простота и гибкость, доверие за счет тестирвоаниятестирования.

* pipelene — конвертер. Принимает функцию конверртации конвертации A-Б, загоняем канал Аб отдаем Б

Интенсивная процессорная нагрузка. Задача — ускорить однопоточную программу поиска простых чисел. Есть многопоточные алгоритмы. Программа фильтрует поток числе, выдавая поток простых. Делаем расщепление FanOut, потом воркеры, потмо — потом — FanIn объединяем. Как определить сколько? Ставим runtime maxproc, а потом снижаем. Чтобы не было проблем. Код бизнес-логики — не содержит никаких асинхронных паттернов. Запускаем бенчмарки, смотрим на ускорение.

Микроархитектурный кейс. Пусть в систему поступают задания, они дают процессорную нагрузку. Результат — канал Result — пишем в БД. Что сделать? Параллельную обработку заданий и писать в БД батчами. Дальше пример кода для реализации. Он не показывал реализации, только схемы, потому что реализация — под проект. Например, в одном случае мы можем через по таймауту отдавать батч, даже меньшено меньшего размера, а в другом — ждать наполнения куска.

И дальше имитационные бекчмаркибенчмарки. Отдельно на каждую оптимизацию и на обе. И, что интересно: каждая отдельно дает много, а комбинация — много не дала, и можно дальше углубляться — почему?

Фреймоврк Фреймворк для построения конкуретных конкурентных приложений.

* И покрытие блоков конкуретными конкурентными тестами — работа в асинхронной среде.