Think Like a CTO (Настоящий CTO: думай как технический директор) - Part II (Рубрика #Management)

В продолжении первого поста о книге "Think Like a CTO" здесь я расскажу про вторую часть книги.

7. Ежегодная оценка сотрудников - здесь автор рассказывает про performance review, промотирование и увольнение сотрудников. Я отдельно рассказывал про performance review, а также про наш процесс Т-Роста, который мы используем для роста сотрудников
8. Технологические решения - рассказ о том, как принимать сложные технологические решения, например, buy vs build, on-prem vs cloud, reliability vs cost или closed source vs open source, микросервисы или монолиты. Если кратко, то автор рассматривает плюсы и минусы каждого из подходов. Но вообще, общий паттерн рассмотрения вопроса долженн быть таков, что надо провести исследования, сравнить альтернативы, а потом принять решения. Я больше 5 лет назад рассказывал примерно об этом в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения"
9. Разработка - здесь автор рассказывает пару страниц о проектном управлении, потом криво рассказывает про waterfall и agile (очень криво), дальше про обеспечение качества. Честно говоря, это очень слабая глава, ооочень. По поводу проектов и продуктов рекомендую почитать мою статью, а про инженерные процессы рекомендую глянуть книгу "Grokking Continuous Delivery", про которую я рассказывал недавно
10. Работа с договорами - здесь гигиеническая база по договорной работе и важности привлечения юристов для изучения договоров:) А также важность лицензий на интеллектуальную собственность в общем, и код в частности.
11. Документация - здесь автор рассказывает базу про документацию. Правда, здесь видно, что автор привык работать в маленьких конторах и, например, предлагает документировать релизный процесс, а не нормально его автоматизировать. В общем, опять слабая глава.
12. Безопасность - очередная базовая глава про безопасность. Рекомендую вместо этого почитать книгу от Goolge "Building Secure and Reliable Systems", про которую я рассказывал. Также можно почитать старенькую книгу "Agile Application Security", про которую я рассказывал раньше
13. Поддержка и обслуживание - здесь автор рассказывает про operations часть, но делает это очень базово:) Рекомендую вместо этого почитать про это мой доклад о том, как проектировать надежные системы и поддерживать их надежность во время эксплуатации системы
14. Рост компании - глава про проведение due diligence, принятии и передаче должности технического директора. В принципе, норм, но очень базово.
15. Вы, Inc - глава о том, как идти в ногу со временем, поддеживать свой технический уровень, а также скиллы руководителя. А в конце автор дает совет, что не стоит задерживаться на работе, которая не соответствует вашим долговременным карьерным целям и не приносит удовлетворения.

P.S.
Про должности и ответственность CTO я уже как-то рассказывал в посте про инфляцию должности CTO

#Management #Leadership #Processes #Software #Architecture #Strategy #ChangeManagement

Как я начал публично выступать (Рубрика #LifeStory)

Вчера я был на ИТ-квартирнике от наших devrel, который они проводили для людей, кто много делает для технического бренда компании. Мероприятие было теплым и ламповым - я пообщался со старыми знакомыми и похлопал коллегам, что победили в разных номинациях и поехал домой. Но пока ехал, я решил свпомнить о том, как я поборол страх выступлений и впервые вышел на сцену большой конференции, которой оказалась Teamlead Conf.

К этому привели события весны 2018 года, когда я решил в марте с друзьями съездить в Сорочаны покататься на сноуборде. Вроде это должна была быть рядовая поездка, ведь катать я начал лет за девять до этого, пару раз ездил в Альпы, достаточно много катал в Подмосковье. Но тут все пошло не по плану - за мной утром, как мы и договаривались заехали друзья и мы поехали на каталку. В ту ночь я поспал пару часов, но считал, что этого достаточно. Незадолго до этого я купил жесткую и быструю доску и очень хотел ее обкатать ...

Дальше я помню, как я очнулся на пассажирском сидении автомобиля, у меня болела голова, грудь, нога ...
Я повернулся к своему другу, что вел машину и задал вопрос "А где мы и что происходит?". Он посмотрел на меня и, как бы нехотя, начал рассказывать, что мы поехали на склон, приехали и начали кататься, прошел где-то часик, а потом один из них увидел как кого-то похожего на меня увозят на снегокате в сторону медпункта. Дальше они пришли туда и увидели, как мне оказывают помощь. В какой-то момент я очнулся и дальше начал задавать вопросы в стиле "А где мы и что происходит?", мне на них отвечали, но через 30 секунд происходил reboot и дальше я задавал их по новой. Мои друзья решают отвезти меня в Москву, чтобы вызвать для меня скорую и положить в московскую больницу. Медперсонал дает совет по дороге общаться со мной и отвечать на повторяющиеся вопросы, ожидая, что через N итераций ребуты перестанут происходить и память схватится.

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

Из этого происшествия я вынес несколько важных уроков
1) Не стоит в плохой форме заниматься экстремальными видами спорта
2) Даже если ты профи в чем-то, то техника безопасности наше все (теперь шлем всегда со мной)
3) Очень тяжело чувствовать себя как главный герой из романа "Цветы для Элджернона" ("Flowers for Algernon")
4) Через месяц, когда из основных пост-эффектов остались только очки, я решил, что надо начать больше делится своим опытом с окружающими - чтобы были материальные подтверждения для потенциальных внуков, что их дедушка до того, как впал в маразм, был достаточно прошаренным :)

Осенью 2018 года я уже выступил на питерском Teamlead Conf, где рассказывал про то, как мы выстраивали процессы разработки в наших фронтовых командах. Если найти запись этого выступления, то видно, что я сильно волнуюсь и мне сложно дается выступление на публике. Но с тех пор много воды утекло, поэтому сейчас публичные выступления на русском для меня это просто. В конце 2019 года я планировал в 2020 году податься на западные конференции и съездить выступить ... но не сложилось. Но из этих публичных выступлений вырос мой бложик TellMeAbout.Tech, а также этот tg канал.

P.S.
Как мне сказал однажды мой лучший друг: "В любых ситуациях надо попробовать увидеть лучшее, а не фокусироваться на проблемах". Кажется, что я внял совету и теперь вспоминаю про то падение, не как о причине серьезной травмы, а как триггер серии событий, что привели меня к знакомству с моей будущей женой. Мы с ней познакомились и начали общаться на первой конференции ArchDays, которую я открывал в главном зале, а она была ведущей второго зала:)

#Storytelling #PublicSpeaking #Leadership #SelfDevelopment

Teaching Software Architecture Design - Building Intuition - Part I (Рубрика #Architecture)

Прочитал недавно интересный whitepaper про обучение архитектуре от Gaurav Agerwala, Len Bass. Заинтересовался я этой статьей из-за ее автора - Len Bass, который является соавтором классической книги "Software Architecture in Practice" и преподает в Carnegie Mellon University. И могу отметить, что я не был разочарован - подход авторов к обучению чем-то напоминает тот процесс system design interview, что мы практикуем у себя в компании:) Кстати, описание подхода есть на Github

Ну а теперь давайте перейдем к самой статье.

Исследователи в статье рассказывают о своем методе и структуре курса, который ставит себе целью демистифицировать процесс проектирования софта и помочь студентам думать аналитически, одновременно развивая интуицию, о компромиссных решениях, принимаемых на этапе проектирования. Но начинается все с введения, где авторы вспоминают про разные процессы проектирования
- ACDM (Architecure Centric Design Method) - итеративный подход из середины двухтысячных к проектированию софта, который ставит проектирование в центр процессов разработки. Подробнее можно почитать здесь
- ADD (Attribute Driven Design) - системная методология из начала двухтысячных для проектирования софта, которая фокусируется на внедрении и приоритизации атрибутов качества (quality attributes) одновременно с функциональными требованиями. Цель в том, чтобы создать эффективную архитектуру, которая будет удовлетворять как функциональные, так и нефункциональные требования.

К обоим подходам имел отношение Len Bass, но для студентов он решил сделать процесс SADM (Software Architecture Design Method), который доступен на GitHub и который фокусируется на ключевых активностях по идентификации и анализу верхнеуровнего дизайна на основе требований. В этом он похож на ADD, но он менее формален и фокусируется на том, чтобы помочь студентам наработать интуицию. Здесь фокус скорее не на отдельных шагах сложного процесса, а на практике в дизайне сложных систем, где много неизвестных. Сама суть метода SADM в том, чтобы дать дизайнером инструмент для работы с этими неизвестными. SADM - это метод для декомпозиции системы или компонета, который выглядит так
- У нас на входе есть требования
- Мы строим контекстную диаграмму
- Дальше выбираем scope для декомпозиции
- Предлагаем гипотезу того, как можно сделать декомпозицию
- Проверяем, что при этом мы удовлетворяем функциональные требования (сценарии)
- Проверяем, что при этом удовлетворяем атрибуты качества (кстати, в Github репозитории есть презентации про такие атрибуты как availability, performance, observability, security, modifiability, integrability)
- Если у нас есть неизвестные моменты, то мы заносим их в таблицу с process steps, чтобы разобраться с ними позже
Такая декомпозиция идет пока мы не декомпозировали систему на части так, чтобы закрыть все требования.

А теперь немного про process steps, куда мы переместили моменты, по которым требовалась дополнительная работа. Собственно, там могут быть 3 активности
- Отложенные решения - это решения, что мы отложили до появления новой информации. Например, использовать DBaaS решение или разворачивать самому кастомную технологию. Это решение может принимать после некоторого количества итерацаций SADM процесса
- Исследовательские активности - возможно требуется дополнительный сбор информации и поиск по внешним источникам, например, варианты подключаемых устройств к умному дому при дизайне IoT системы
- Активности по тестированию - некоторые решения стоит принимать после построения прототипа и проверки гипотез на нем.

Продолжение разбора статьи в следующем посте.

#Architecture #Software #Engineering #SelfDevelopment

Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024 (Рубрика #Architecture)

Интересное выступление Кента Бека, который когда-то не просто участвовал в подписании Agile Manifesto, а был первым подписантом среди уважаемых джентельментов ... так как шел первым по алфавиту. В этом выступлении Кент, создатель методологии XP (eXtreme Programming) рассказывает о своих экстремальных подходах к дизайну и кратко про книгу "Tidy First?", про которую я уже рассказывал раньше. Если кратко обобщить его рассказ в этом выступлении, то получится следующее

1) Начинается все с мотивации к деятельности - у нас есть порядка 3 млрд секунд (~ 95 лет). Если думать об истекающем времени, то есть мотивация не тратить его впустую
2) А в разработке софта есть много таких бесполезных вещей, например, автор так троллит тему с документацией:)
3) Когда-то давно автор участвовал в панельной дискуссии на конфе с корифеями Edward Yourdon, Larry L. Constantine, что написали книгу "Structured Design". Кент к той панельке прочел эту книгу и решил написать обновленную версию
4) Так появилась "Tidy First?", где Кент говорит про то, как наводить порядок в коде. Это позволит разработчику улучшить свое рабочее место и упростить работу.
5) Есть идея на вторую книгу "Tidy together?", в которой Кент планирует рассказать про совместную работу инженеров в командах, а в третьей книге будет рассказ про связь технологий с бизнесом
6) Основная идея автора - важность дизайна для изменения поведения системы. Софт состоит из фунукций и структуры. Про фукнции думает бизнес, а структура является backbone для этих функций
7) Если мы только клепаем фичи, то структура оказывается недоинвестированной - мы создаем технический долг, что усложняет внедрение новых фичей в дальнейшем
8 ) Цель правильного подхода в том, чтобы сбалансировать инвестиции в функции и структуру (автор приводит пример с выпиливанием дублирующего функционала)
9) Кент много говорит про социальные эффекты в разработке, про доверие и отвественность, а также разные стимулы и интересы у разных участников процесса. Обычно это называют социотехнической системой.
10) Кент много говорит про ограничения документации вида того, что она устаревает быстрее, чем ее обновляют и т.д. но не ясно какую альтернативу он предлагает
11) Кент говорит, что в разработке софта совокупная стоимость владения складывается по большей части из стоимости поддержки и модификации написанного, а не из первоначальных инвестиций в написание кода. Кстати, про этот тезис часто сейчас забывают, когда оценивают эффекты написания кода LLM ассистентами, считая только легкость начальной генерации кода:)
12) Но не все изменения стоят одинаково - обычно небольшие изменения стоят недорого, но много небольших изменений могут накапливаться и превращаться в большее, которое может стоить как значительная часть системы. В терминальном случае это большое изменение приводит к запрету версии 1.0 и создании нового пректа с нуля
13) Для снижения стоимости изменений, которые точно будут, надо понимать структуру затрат - это поможет подготовить софт к эволюции по мере изменений требований бизнеса
14) Кент говорит про coupling и про то, что изначально coupling между компонентами означал что изменения в одном элементе могут потребовать изменений в других. А потом определение Edward Yourdon, Larry L. Constantine начало мутировать и потеряло изначальный смысл
15) При разработке ПО нужно учитывать стоимость связей и стоимость их отсутствия. Важно находить компромиссы между стоимостью изменений и их последствиями. Пространство компромиссов помогает оценить целесообразность изменений.
16) Оценивать эти компромиссы лучше понимая экономические факторы вида NPV и стоимости денег во времени, оценки рисков и так далее. Например, инвестиции в структуру создают возможности для будущих изменений, что дает нам опцион на реализацию дешевых изменений в будущем
17) Отдельно автор отмечает, что наличие ограничений дает инженерам пространство и стимул для хороших решений:)

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Teaching Software Architecture Design - Building Intuition - Part II (Рубрика #Architecture)

Продолжая первый пост с разбором whtepaper про обучение архитектуре, здесь я расскажу про оставшуюся часть статьи

Анализ гипотез по отношению к требованиям в итоге должен вести к
- Развитию инженерного подхода к принятию дизайн решений
- Повышению уверенности инжнеров, что предложенный ими диазайн удовлетворяет требованиям
- Способствует дискуссии о компромиссах, которые принимаются при выборе того или иного варианта дизайна

Для этого авторы предлагают использовать подход с опровержимой аргументацией (defeasible argumentation), в которой аргументы принимаются на текущий момент, если они звучат разумно и приняты на основе доказательств, что есть на текущий момент. Но эти аргументы могут быть пересмотрены при появлении новых данных. Этот подход очень напоминает то, как работают люди, что проектируют софт
- Они опираются на текущие данные и принимают решения в этом контексте
- При появлении новой информации они могут увидеть, что это противоречит предпосылкам, на которых был основан дизайн раньше
- А это потребует принятия нового решения, что изменит старое
Обычно такой процесс реализуется с использованием подходов RFC и ADR, где
- RFC - это request for comments или подход коммитетов к принятию решения
- ADR - это architecture decision record, что добавляется в список принятых архитектурных решений.

В рамках SADM студенты учатся задавать критические вопросы по отношению к дизайн гипотезам, практикуясь в формулировании аргументации, а также в ее опровержении. Причем здесь есть 2 формата аргументов

1) Аргументы для анализа use cases
Если предложенная гипотеза о декомпозиции помогает реализовать необходимое поведение для конкретного сценария, то студенты могут попробовать задать критические вопросы вида
- Какие исключения из шагов в сценарии делают его вклад в вариант использования недействительным?
- Есть ли какие-либо побочные эффекты предлагаемой архитектуры, которые отрицательно влияют на шаги или мешают им выполняться?
- Вносит ли предлагаемая архитектура отрицательный вклад в другие требования системы (варианты использования или требования к атрибутам качества)?
- Нарушаются ли какие-либо ограничения во время выполнения сценария или его исключений?

2) Аргументы для анализа атрибутов качества
Эта часть посложнее, так как требует много лет опыта, чтобы приводить неотразимые аргументы. А у начинающих часто аргументы звучат в формате "так работает google/aws/netflix", а значит это масштабируется, что является очень слабым аргументом. Здесь авторы предлагают студентам делать отсылки к референсной архитектуре, а также общепринятым архитектурным паттернам. Например, во второй части книги "Software Architecture in Practice" есть примеры паттернов, что приведены в свзяи с теми атрибутами качества, которые они поддерживают. Для использования паттернов можно использовать следующий подход
- Показать, как предлагаемая архитектура является примером задокументированного шаблона или эталонной архитектуры.
- Показать, что шаблон или эталонная архитектура, как известно, удовлетворяют указанному атрибуту качества.
Критические вопросы, которые студенты могут задавать по этим аргументам звучат примерно так
- Включает ли предлагаемая архитектура другие паттерны, которые отрицательно влияют на атрибут качества?
- Мешает ли предлагаемый шаблон/эталонная архитектура другому требованию к системе?

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

P.S.
Мне кажется, что здесь описан логичный и легкий процесс того, как можно подтянуть свои умения в дизайне сложных систем:)

#Architecture #Software #Engineering #SelfDevelopment

Недавно выступал на конфе имени Андрея Смирнова из X5, где рассказывал про soft skills и важности баланса между ними и hard skills. На записи есть проблемы с качеством звука, поэтому краткое саммари того, что я рассказывал такое
1) Эволюция разработки и роль софтов
- Разработка за последние 20 лет стала сложнее.
- В современных компаниях разработчики должны проектировать системы, писать код и тесты.
- Важность коммуникации и взаимодействия между различными ролями в разработке.
2) Pipeline Driven Organization и абстракции
- Pipeline Organization: интеграция различных ролей в начале процесса.
- Нам нужно использовать абстракции для упрощения работы, но все равно остается необходимость взаимодействия с деталями.
- Важность понимания под капотом систем и взаимодействия с разработчиками.
3) Сложность современного мира и коммуникация
- Мир меняется быстро, что требует постоянной адаптации.
- Коммуникация становится ключевым фактором в сложных и хаотичных условиях.
- Конечно можно работать на одном уровне, но часто люди хотят активного роста.
4) Рост в инженерии и лидерство
- Возможность роста в инженерии через индивидуальные проекты и менеджмент.
- Важность лидерских качеств и умения вести за собой команду.
- Инициатива о повышении исходит от самих сотрудников.
5) Личный опыт и планирование роста
- Личный опыт становления руководителем и важность планирования времени.
- Умение брать ответственность и доводить дела до конца.
- Важность коммуникационных навыков и навыков переговоров.
6) Мотивация и планирование
- Важно понимать, зачем ты делаешь то, что делаешь.
- Поддерживай мотивацию окружающих, особенно если ты лидер.
- Планирование помогает структурировать задачи и достигать целей.
7) Матрица Эйзенхауэра
- Важные и срочные задачи решаются сразу.
- Важные, но не срочные задачи откладываются на потом.
- Срочные, но не важные задачи можно делегировать.
- Цели должны быть амбициозными и достижимыми.
😍 Подход от желаемого результата (working backwards)
- Начинайте с желаемого результата, а не с текущего состояния.
- Стройте шаги от цели к текущему состоянию, а не наоборот.
• Это помогает избежать ментальных блокировок и достигать амбициозных целей.
9) Проектный менеджмент
- Проектный менеджмент полезен для больших задач с большими затратами на координацию
- Важно уметь использовать проектный менеджмент для достижения целей.
10) Принятие ответственности
- Признайте и примите ответственность за свои действия.
- Четко определите свои обязанности и цели.
- Фокусируйтесь на том, что можете контролировать
11) Решение проблем и рефлексия
- Решайте проблемы, а не откладывайте их.
- Учитесь на своих и чужих ошибках.
- Будьте устойчивы к проблемам и показывайте пример.
12) Развитие навыков коммуникации
- Активное слушание помогает лучше понимать собеседника.
- Адаптируйте стиль коммуникации под аудиторию.
- Важно понимать, что хочет услышать аудитория, и адаптировать свои выступления.
13) Проблемы с ясностью и публичными выступлениями
- Обсуждение важности ясности в речи и публичных выступлениях.
- Личный опыт выступлений на конференциях и трудности с эмоциями.
- Важность фидбека и рефлексии для развития коммуникационных навыков.
14) Планирование и чекпоинты
- Идея планирования с чекпоинтами для достижения больших целей.
- Личный опыт написания постов и создания книг.
- Важность фиксации результатов и планирования для достижения успеха.
15) Теоретический и практический подходы
- Различие между теоретическим и практическим подходом к решению проблем.
- Личный опыт работы с теоретическими и практическими методами.
- Важность фиксации и повторения результатов для роста и развития.
16) Лидерство и софт скилы
- Софт скилы важны как для инженеров, так и для лидеров.
- От высокогрейдового инженера сейчас ожидается лидерская проактивная позиция
- Для достижения амбициозных результатов необходимы лидерские качества и эффективные коммуникации.
- Без этих навыков сложно достичь масштабных результатов.

#Management #Leadership #Software #Processes #SelfDevelopment

Книга-квест "Ам Ням. Жми" (Рубрика #ForKids)

Вчера прочитал перед сном сыну эту книгу, в которой 20 небольших глав, а сегодня мы прошли все мини игры в дополненной реальности. Если кратко, то описание книги обещает раскрыть истинную историю появления Ам Няма, а потом Ам Ням спасет мир от супер-злодея из комптьютерной игры. Мне показалось, что это неплохая книга для дошкольников - весело и интересно, а родителям забавно читать про взаимоотношение Ам Няма и его "дамочки" сердца, Ам Няши, которую он спасает на протяжении всей книге.

P.S.
Книги от DEVAR нравятся нашим детям и у нас дома собрался из них полный комплект, а о некоторых я уже рассказывал: например, о "Живой раскраске Смешарики".

#ForKids #ForParents #Tales

The Golden Passport: Global Mobility for Millionaires (Золотой паспорт: Глобальная мобильность для миллионеров) (Рубрика #Economics)

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

Основные моменты книги включают:
- Исследование трансформации продажи паспортов от сомнительной практики до процветающей индустрии, в которую вовлечено более десятка стран. Интересно, что формально и в России есть программа гражданства через инвестиции, а глобальным лидером сейчас является Турция, которая перехватила лидерство у Кипра. В Карибском бассейне еще есть старожилы рынка инвестиционных паспортов в виде Сент-Китса, Гренады, Доминики, Сент-Люсии, Антигуа и так далее
- Анализ сложных причин этого явления, включая желание повысить глобальную мобильность, получить налоговые льготы и обеспечить страховку от политической нестабильности.
- Масштаб рынка - порядка 50к человек, что ежегодно приобретают гражданство через эти программы, стоимость зависит от программы, но начинается все с нескольких сотен тысяч долларов и может доходить до миллионов
- Исследование последствий этой практики для концепций гражданства, глобального неравенства и взаимосвязи между богатством и национальной принадлежностью.

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

P.S.
Это книга издательства Fortis Press, которая публикует переводы недавних интересных книг на актуальные темы. О парочке книг этого издательства я уже рассказывал раньше
- Woke, Inc. За фасадом корпоративной риторики о социальной справедливости (Woke, Inc.: Inside Corporate America's Social Justice Scam)
- Taming Silicon Valley: How We Can Ensure That AI Works for Us

#Economics #History

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part I (Рубрика #Architecture)

Вчера перед сном прочитал интересный whitepaper про процесс SAR (Software Architecture Recovery) при помощи LLMs. Мне идея показалась интересной, чтобы кратко рассказать про нее.

1) Стандартный подход к Software Architecture Recovery обычно работал снизу-вверх (bottom-up). Условно, некоторый анализатор кода запускался строил архитектурные метрики, которые как-то характеризовали архитектуру проекта (что-то в духе кейсов из книги "Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture", про которую я уже рассказывал)
2) В этом paper исследователи решили пойти сверху-вниз (top-down) и начать с задания референсной архитектуры, а дальше уже классифицировать части кода как относящиеся к той или иной части этой референсной архитектуры. Это позволяет не просто собрать текущее состояние архитектуры как было в стандартном подходе, а оценить расхождение между референсной архитектурой проекта и тем, что у нас есть на самом деле:)
3) Авторы говорят о том, что этот подход больше похож на то, как работают software engineers, так как обычно инженеры знают какая базовая архитектура в проекте, поэтому могут использовать эти знания при изучении кода

Дальнейшее описание процесса в следующем посте, а в приложении к этому основные иллюстрации с описанием процесса, описанием индикаторов компонентов архитектуры, а также промптом для LLM, который используется в классификации.

#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part II (Рубрика #Architecture)

Продолжая рассказ про дедуктивный процесс SAR (Software Architecture Recovery) при помощи LLMs, я расскажу своими словами про шаги этого процесса

Phase 1. Reference architecture definition - собственно, именно эта фаза добавляется авторами и позволяет потом добавить использование LLMs
1) Select reference architecture - здесь авторы предлагают выбрать референсную архитектуру, упоминаются стандартные layered architectuure, MVC, но сходу можно припомнить и другие подходы вида MVVM, Onion Architecture, ...
2) Define architectural components - здесь авторы определяют компоненты архитектуры, именно они будут использоваться LLMs для дальнейшей классификации кода. Например, для типовой layered architecture выделяются следующие уровни: presentation, application service layer и так далее
3)Define component & interaction indicators - здесь авторы в текстовом виде описывают правила взаимодействия компонентов, что дальше используется для классификации. Например, в случае с layered architecture авторы описывают свойства presentation layer

Pr1 . . sets the attributes of UI components, e.g., sets the text of a TextView.
Pr2 . . . notifies listeners about user events, such as button clicks or list item selections.
Pr3 . . . transforms domain objects into visual representations

Phase 2. Code unit classification - эта фаза рекурсивная и направлена снизу-вверх. Авторы предлагают выбрать гранулярность, а потом запустить классификацию. Например, начать с методов классов, дальше аггрегировать это в классы, потом в неймспейсы и так далее
4) Evaluate code units against indicators - собственно, здесь немного prompt engineering + код с описаниями методов попадает в LLM (GPT-4) на оценку для классификации по компонентам из референсной архитектуры

In a layered software architecture, one of the layers is the (layer_name) layer, which (layer_responsibility).
Consider the context of an Android Java project “(project_name)”:
(project_domain_description)
Here are some indicators that a Java method in the project may belong to a class in the (layer_name) layer:
(layer_indicators)
The class ‘(class_name)’ contains the method ‘(method_name)’:
(method_source_code)
Check whether this method satisfies each indicator above. Mention the specific line of code that supports your reason. At the very last
line, write the boolean verdicts separated by a comma, e.g., ‘true, true, false, true’. If indeterminate, say ‘false’.

5) Aggregate classified code units - здесь мы агрегируем ответы с прошлого этапа и получаем классы, в которых были методы, а дальше запускаем их на предыдущий шаг для повторной классификации и так пока не доберемся до нужного нам уровня абстракции

На выходе такого процесса у нас получается некоторая классификация программных компонент с учетом референсной архтитектуры нашего проекта. Авторы сделали PoC для Android приложения K9 Mail и сравнили ручную разметку экспертами с тем, что насчитала модель - precision и recall для классификации оказались 72% и 71% соответственно. В итоге, авторы отметили, что есть еще пространство для улучшений и сформулировали свой план дальнейших исследований, включающих в себя работу над референсными архитектурами, а также полевое исследование в компаниях с применением этого метода.

#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

The issue of monorepo and polyrepo in large enterprises (Рубрика #Architecture)

Недавно прочитал старенький whitepaper 2019 года от Nicolas Brousse из Adobe с анализом подходов к управлению репозиториями исходного кода в крупных компаниях. Собственно сравниваются подходы монорепозитория и полирепозитория (множества отдельных репозиториев). Монорепы используют такие компании как Google, Meta, Microsoft, а полирепозитории были в Amazon, Netflix, Lyft и так далее. Автор ссылается на исследование "Advantages and disadvantages of a monolithic repository: a case study at Google", в котором есть хорошее сравнение компромиссов монореп и полиреп и подсвечиватся плюс монорепы вида, что монорепы

Encourages consistent and high-quality code, and empowers engineers to study and learn from the institutional knowledge of their company, crystallized in the form of source code

Дальше автор рассматривает разницу через три призмы

1) Cultural Alignment (культурное соостветствие)
Структура репозиториев отражает корпоративную культуру. Монорепы подходят для коллаборативных сред (например, Google с философией «открытого сотрудничества»), а полирепозитории — для культур, ориентированных на автономию (например, Netflix с принципом «свободы и ответственности»). Интересно, что у нас полирепозиторий в Т-Банке
2) Team Cognition (командное познание)
Монорепозитории разрушают функциональные силосы, способствуя целостному пониманию задач за счёт видимости общего кода и снижения коммуникационных барьеров, что коррелирует с повышением качества софта.
3) Tradeoffs (компромиссы)
Обе модели имеют технические сложности (например, масштабируемость монорепозиториев), но монорепы стимулируют культурные изменения, улучшающие конкурентоспособность через DevOps-практики и инновации без ограничений.

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

P.S.
На тему различий рекомендую почитать сравнение от Carlos Arguelles, инженера, что долго проработал в Amazon на CI/CD инфрой, потом ушел в Google на несколько лет, а потом вернулся в Amazon. Я раньше уже разбирал его статью "How Amazon and Google view CI/CD in an entirely different way".

#CI #SRE #Architecture #Software #Infra #QA

Hooked: How to Build Habit-Forming Products (На крючке) (Рубрика #Management)

Эта уже классическая книга Нира Эяля рассказывает о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. В книге представлена модель крючка в виде процесса из четырех зацикленных шагов, что позволяют формировать привычки пользователей. В самой модели следующие четыре части
1) Trigger (триггер): запускает поведение пользователя через внешние сигналы (например, уведомления) или внутренние мотивации (эмоции или мысли).
2) Action (действие): поведение, выполняемое в ожидании вознаграждения, которое должно быть максимально простым для пользователя.
3) Variable reward (переменное вознаграждение): результат действия, который удерживает пользователей благодаря своей непредсказуемой природе.
4) Investment (инвестиция): вклад пользователя в виде времени, данных, усилий или денег, что повышает вероятность возвращения к продукту.

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

Используя эту модель, можно разобрать подходы известных продуктов

1) Duolingo создал формирующий привычку опыт изучения языков:
- Триггер: отправляет ежедневные уведомления о целях изучения языка.
- Действие: предлагает геймифицированные, легко выполнимые уроки.
- Переменное вознаграждение: предоставляет очки опыта и достижения за серии успехов.
- Инвестиция: отслеживает прогресс и адаптирует пути обучения на основе результатов пользователя.
Я сам пользуюсь duolingo и у меня нерпрерывный streak сейчас в 2 года

2) TikTok стал крайне привлекательным, используя модель hooked:
- Триггер: внешние триггеры включают видео, которыми делятся друзья, в то время как внутренние триггеры обращаются к желанию развлечься.
- Действие: предлагает простой процесс создания аккаунта и легкий просмотр видео.
- Переменное вознаграждение: представляет постоянный поток разнообразных, персонализированных коротких видео.
- Инвестиция: позволяет пользователям создавать и делиться своими собственными видео, увеличивая привязанность к платформе.

3) Slack стал популярной платформой для коммуникации на рабочем месте и она тоже применяет модель hooked:
- Триггер: использует как внешние, так и внутренние триггеры для привлечения внимания пользователей.
- Действие: предлагает удобный интерфейс для легкого обмена сообщениями и участия в каналах.
- Переменное вознаграждение: доставляет вознаграждения в виде положительной обратной связи и уведомлений о выполнении задач.
- Инвестиция: поощряет вклад пользователей через обсуждения и участие в проектах.
Мы использовали Slack до того, как перешли на наш мессенджер Time.

Но есть у модели и стандартные проблемы, которые могут уменьшать ее эффективность
1) Несоответствие потребностям пользователей - неспособность понять реальные проблемы пользователей или создание решений для несуществующих проблем.
2) Чрезмерное усложнение модели - слишком сложный UX или слишком много фичей могут оттолкнуть пользователей
3) Неэффективные системы вознаграждений - если вознаграждения слишком предсказуемы, то это плохо. Одновременно плохо, если они неконсистентны между собой и не поддерживают интерес и мотивацию пользователей.
4) Пренебрежение фазой инвестиций - слишком слабое или слишком сильное поощрение вклада пользователей в приложение приведет к тому, что они сорвутся с крючка
5) Этические проблемы - привычки должны приносить пользу клиентам иначе легко провалиться на темную сторону силы

#Management #ProductManagement #Econimics #PopularScience