Книжный куб

Как и зачем измерять инженерную продуктивность в крупной компании (Рубрика #Management) Появилась запись моего выступления на MTS True Tech Day, где я рассказывал про инженерную продуктивность. Эта тема является важно для больших компаний, так как достаточно сложно понять насколько эффективно работает организация. Есть общие показатели на всю компанию, но они — Показывают общую ситуацию в компании и сложно понять вклад отдельных частей организации — Отображают уже достигнутые результаты причем с сильным лагом — это примерно соответствует тому, чтобы при управлении машиной смотреть не в лобовое стекло, а в зеркало заднего вида В крупной технологической компании (а в Тинькофф порядка 10к инженеров) большой вклад в эффективность компании вносит эффективность работы инженеров, поэтому мы уделяем этому большое внимание. Само выступление имело следующий план - Затравка про важность этого вопроса (я ее уже тут рассказал ввыше) - Как я предлагаю сузить границы рассмотрения только продуктовыми компаниями и частью delivery без discovery - Какие подходы были в академической среде: DORA и Accelerate, SPACE, DevEx - тезисы со ссылками на материалы доступны здесь - Как это делают в Bigtech, например, в Google используют подход QUANTS - тезисы доступны здесь - Что есть на рынке в виде коммерческих платформ - тезисы и ссылки здесь - Как это делаем мы в Тинькофф - тут я расскажу про наш инструмент T-Meter - Ну и какие выводы из этого всего следуют Расшифровка есть в статье в моем блоге, а также в виде pdf в этом канале. P.S. Так как мой доклад - это не питчинг раунда финансирования для стартапа, то я решил исключить часть про влияние AI на developer productivity, что тянет на отдельный доклад (который недавно как раз рассказывал VP of Product из GitHub) #Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Вот так whitepaper про лосося и МРТ видится искусственному интеллекту:)

Neural correlates of interspecies perspective taking in the post-mortem Atlantic Salmon: an argument for multiple comparisons correction (Рубрика #Humor) При изучении книги Дэвида Хэнда "Темные данные" ("Dark data. Why what you don't know matters") наткнулся на разбор этого whitepaper про проведение экспериментов над мозгом мертвого лосося. Этот эксперимент получил Шнобелевскую премию по нейробиологии и он был поставлен следующим образом: - Метвому лососю проводили МРТ-сканирование головного мозга - Одновременно с этим показывали серию фотографий, изображающие людей в различных ситуациях - А также просили испытуемого определить какие эмоции используют изображенные люди - Фиксировали определение эмоций при помощи реакции, которая определялась как активность клеток мозга, видимая на вокселях (пикселях МРТ-изображения) Оказалось, что несколько вокселей оказались активны. Авторы сделали открытие, что

Либо мы наткнулись на поразительное открытие на стыке ихтиологии и посмертных когнитивных функций, либо что-то не так с нашим статистическим подходом. Можем ли мы заключить из этих данных, что лосось выразил свое мнение, отвечая на поставленный вопрос? Конечно, нет. Контролируя когнитивные способности субъекта, в данном случае мы полностью исключили эту возможность

Дэвид Хэнд, автор книги про темные данные, а также президент статистического общества и член Британской академии, вспоминает анекдот на эту тему

Экспериментатор А говорит экспериментатору Б, что у него большие проблемы с воспроизведением результатов, полученных Б. "Неудивительно, - отвечает тот, - ведь я тоже не смог получить их первые 100 раз, когда проводил эксперимент".

А для того, что эксперименты у нас в Тинькофф были защищены от такого мы и делаем внутри компании a/b платформу, про которую я уже рассказывал при публикации вакансии staff инженера в эту платформу. Также есть ряд книг, что полезны тем, кому нравится статистика и эксперименты и про которые я уже рассказывал раньше. - Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов - Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними - Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании #Math #PopularScience #SelfDevelopment #Humor #Statistics

Live-трансляция про слайдоцентричное мышление от Кирилла Анастасина и Вани Лукьянова (Рубрика #Speaking) Сегодня автор комикаки (@komikaki), Кирилл Анастасин, обсудит с Ваней Лукьяновым тему про презентации, в которой поднимет вопросы — Как мешают слайды готовить доклад? — Роль слайдов в презентации? — Как портит жизнь слайдоцентричное мышление в коллективе? — Что главное в выступлении? P.S. Лет 5 назад я проходил обучение у Кирилла и оно помогло мне тогда улучшить публичные выступления. Обкатывал я подходы, готовясь к выступлению на ArchDays 2019, про что я рассказывал 5 лет назад. #PublicSpeaking #SelfDevelopment

ChatGPT from Scratch: How to Train an Enterprise AI Assistant • Phil Winder • GOTO 2023 (Рубрика #AI) Интересное выступление от Phil Winder, CEO компании Winder.AI и автора книги "Reinforcement Learning". В этом видео автор рассказывает базово про chatGPT и показывает забавную демку с файнтюнингом модели для написания лирики, а дальше эту созданную лирику зачитывает на фоне музыки, сгенерированной Stable Audio. Если же переходить к основному контенту, то - Автор начинает с краткой истории LLM, где автор прослеживает эволюционный путь LLM от их рудиментарных форм до передовых архитектур, таких как GPT-4, и как это влияет на область обработки естественного языка (NLP). - Дальше он рассказывает про базовую архитектуру и компоненты больших языковых моделей (encoder-decoder в трансформерах и дальше только декодер как в GPT) - Потом речь идет про методы предварительной обработки наборов данных, специфичных для предметной области, которые приводят к созданию узкоспециализированного и эффективного LLM - После этого доходит очередь до стратегий эффективного и экономичного обучения моделей: от тонкой настройки предварительно обученных моделей до обучения с нуля. - Напоследок автор дает рекомендации по развертыванию для LLM, включая использование облачных сервисов, таких как AWS и Azure (и тут он показывает заодно демку) - Ну и в финале приводятся соображения безопасности и этики при развертывании LLM в бизнес-среде, включая конфиденциальность данных и интерпретируемость модели. #AI #ML #DataScience

Fingerpool и Чапаев (Рубрика #Kids) Кто в детстве не играл в Чапаева? Я вот играл и решил продолжить традицию со своими детьми, но быстро устал доставать шашки из под всех диванов и кроватей. Дальше я решил поискать игру в этом стиле, но так, чтобы у доски были края. Я быстро нашел игру Карром, но мне показалось, что 15+ тысяч рублей за эту игру дороговато. Потом я нашел игру под названием finger pool, которая представляет собой версию чапаева на маленьком поле для бильярда, где мы играем по правилам пула:) Эта игрушка зашла моим сыновьям и теперь мы играем в нее вместо Чапаева, а мне не приходится искать улетевшие шашки:) #ForParents #ForKids #BoardGame

Примеры иллюстраций из книги Введение в RUP (The Rational Unified Process. An Introduction)

Введение в RUP (The Rational Unified Process. An Introduction) (Рубрика #Management) Эта книга Филиппа Крачтена (Philippe Kruchten) посвящена процессу разработки, который в конце девяностых и начале двухтысячных претендовал на то, чтобы стать стандартом де-факто в разработке софта. Это был уже не waterfall, который все трактуют упрощенно и предпочитают блеймить рассказывая про отсутствие итераций и обратной связи (что в общем виде неверно). В этой книге 2001 года выпуска автор дает следующие советы по организации производственных процессов (которые актуальны и сейчас) 1. Разрабатывайте итеративно - автор пинает waterfall, дальше вспоминает про спиральную модель Барри Боема, а потом предлагает итеративный процесс, в результате каждой итерации которого создается релизная версия. Внутри итерации по стандарту есть планирование, управление требованиями, анализ и проектирование, реализация, распространение, тестирование и оценка. 2. Управляйте требованиями - под требованием тут понимается условие или характеристика, которой должна соответствовать система. И автор предлагает активно работать с функциональными и нефункциональными требованиями, а также ограничениями системы. Нам надо уметь документировать требования и отслеживать их влияние на систему и принимаемые решения и компромиссы. 3. Пользуйтесь модульными архитектурами - автор рекомендует использовать модульную архитектуру, которая способствует эластичности, распределению ответственности, использованию стандартизированных компонентов и визуальному моделированию. 4. Используйте визуальное моделирование - здесь автор говорит про важность моделирования и вспоминает UML (unified model language) - унифицированный язык моделирования, на который было много надежд в те времена. Сейчас многие тоже хотят визуально моделировать, но уже используют для этого другие нотации и подходы (C4 Model, ArchiMate, SysML, 4+1, ...). Кстати, именно модель "4+1" и рекомендовалась внутри RUP как процесс, основанный на архитектуре. Суть в том, что у нас были 5 представлений: logical, process, development, physical, scenarios. Причем сценарное представление основанно на сценариях пользователей и объединяет остальные представления. 5. Не забывайте о проверке качества - про важность автоматизированного тестирования и поиск багов на ранних стадиях разработки софта. Сейчас это называется shift-left testing:) 6. Следите за изменениями - здесь автор говорит про повторяемость процесса изменений софта. Сейчас мы добиваемся этого при помощи выстроенного процесса CI/CD (continuous integration / continuous delivery). Интересно, что рекомендации не устарели за прошедшее время и даже стали гораздо четче + появилась крутая инструментализация:) Дальше автор рассказывает про четыре функции разработки софта и показывает, что все эти функции реализуются внутри RUP и основаны на 6 советах, приведенных выше 1. Обеспечивать руководство последовательностью действий команды 2. Определять, какие артефакты должны создаваться и когда 3. Указывать, чем должны заниматься отдельные разработчики и целые команды 4. Предлагать критерии наблюдения и измерения продуктов и видов деятельности. А дальше в книге автор подробно разбирает как устроен RUP и как его использовать для того, чтобы выстроить процесс разработки. P.S. Филипп Крачтен, автор книги, - очень крутой специалист как по процессам, так и по software architecture. Он был директором по разработке процесса RUP внутри Rational до 2003 года, когда Rational был куплен IBM. В 2020 году получил Software Architecture Award от Carnegie Mellon University | Software Engineering Institute (вот его выступление про состояние software architecture, которое было приурочено к награждению) P.P.S. Помню как лет 17 назад я знакомился с этим процессом поближе, проходя тренинги и обучения в Luxoft. Меня впечатлил подход, когда ты мог собрать себе кастомный процесс из кубиков, что предоставлял RUP. Правда, уже тогда мне казалось это довольно сложной конструкцией:) #SoftwareArchitecture #Architecture #Software #Management #Leadership

ArchDays 2024 - CFP (Рубрика #Architecture) Этой осенью пройдет уже 6 ежегодная конференция ArchDays по software architecture. Я в программном комитете этой конференции с момента ее появления, поэтому не могу не поделиться стартом CFP (call for paper). Если вы хотите выступить на конференции и рассказать доклад об одной из тем: процессы проектирования, практики, инструменты, обучение архитектуре или про собственную разработку, то you are welcome. В этом году, как и в прошлом у нас упор на практику - можно подать заявку на проведение арх каты, порешать арх кейсы или подискутировать насчет разных концепций архитектуры. В общем, если планируете стать спикером, то вам сюда https://archdays.ru/speakers/ А если вы планируете прийти послушать, то уже можно покупать билеты:) #SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

Картинка от нейросети на тему цифровой экономики и цифровизации всего и вся:)

WTF "Цифровая экономика и цифровизация" (Рубрика #Economics) В комментариях к посту о книге "Цифровая трансформация Китая" ("The Digital Economy") мне намекнули, что тема цифровой экономики не раскрыта. Я подумал над комментарием и решил написать то, что я думаю про цифровизацию и цифровую экономику в виде отдельного поста. Мне кажется, что тема цифровой экономики и цифровизации всего и вся в последние годы стали уже почти шумом. Например, есть такая автономная некомерческая организация "Цифровая экономика" с описанием деятельности в виде

Деятельность АНО «Цифровая экономика» сфокусирована на направлениях, отвечающих текущим задачам развития высокотехнологичных секторов экономики РФ. Мы — это национальная экосистема поддержки цифровой трансформации и развития бизнеса, аналитика и исследования, регуляторный хаб, кадровое обеспечение, продвижение технологий и решений, устранение проблем применимости цифровых технологий.

Есть популярный канал про цифровую экономику "Нецифровая экономика" (@antidigital), в котором про цифровую экономику рассказывается без пафоса:) Есть еще куча источников, но можно почитать про цифровую экономику и на википедии и вдохновиться определением

Цифровая экономика (веб-, интернет-эконо́мика, электро́нная эконо́мика) — экономическая деятельность, осуществляемая с помощью электронных сетей (цифровых телекоммуникаций)[1], связанная с электронным бизнесом и электронной коммерцией, и производимых и сбываемых ими цифровыми товарами и услугами. Расчёты за услуги и товары цифровой экономики производятся зачастую цифровой валютой (электронными деньгами).

Если же говорить про настоящее время, то мы стремительно движемся к состоянию, что слово "цифровая" перед словом экономика можно будет просто опускать, так как цифра добралась везде. Это примерно также как мы не говорим "электрическая" экономика, подразумевая, что оно вездесуще:)) Если хочется познакомитсья с темой глубже, то рекомендую почитать книги: - "Машина, платформа, толпа" (“Machine, Platform, Crowd”) - я уже писал в канале про эту книгу и у меня есть обзор - "Цифровизация" ("How to go digital") - компиляция статей от MIT Sloan Management Review на тему цифровизации, есть обзор в 2х частях: 1 и 2 - "Цифровая трансформация" ("Digital Transformation") - книга от Томаса Сибеля, что создал знаменитый Siebel. Вот мой обзор книги - “Digital Transformation Game Plan” - книга от ребят из ThoightWorks (знаменитых IT консультантов) и мой обзор книги - "Digital @ Scale" - книга от консультантов из McKinsey и мой обзор книги #Management #Digitalization #Leadership #Strategy #Economics

Обложки книги Цифровая трансформация Китая (The Digital Economy)

Цифровая трансформация Китая (The Digital Economy) (Рубрика #Economics) Достаточно древняя книга от Ма Хуатэна, основателя компании Tencent, которую он издал изначально в 2017, а в 2019 году она была переведена на русский язык. Интересно, что Tencent - это одна из bigtech компаний Китая, которая создала страныWeChat - топ-соцсеть этой. В год издания эта книга могла бы считаться визионерской, но в 2024 году мы можем посмотреть насколько хорошим пророком оказался Ма Хуатэн (а он оказался хорош). Если говорить про содержание, то книга состоит из следующих частей

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

В общем и целом, в первой части автор показывает основные факторы цифровой экономики: данные как производственный фактор, ит-инфраструктура как необходимый фундамент для цифры, цифровая грамотность как предусловие для эффективности работников, стирание границ между спросом и предложением и слияние виртуального и реального мира. Во второй части автор говорит про инфраструктуру, грамотность, облачные технологии и искусственный интеллект. Третья часть посвящена тому, как внедрить информационные технологии в промышленность: добывающую, сельское хозяйство, торговлю, образование, медицину, транспорт и финансы. Глава про финансы посвящена разбору того, как топовые страны двигают цифровую экономику и регулируют ее: США, Евросоюз, Великобритания. Вообще, автор выделяет три модели: - Ограничительное регулирование как в США, где используется функциональное регулирование - например, это значит, что в какой бы форме не были финансы, они включаются в существующую систему финансового регулирования с учетом того, каких операций они касаются и какие функции имеют. Это видно на примере различных цифровых активов - Инициативное регулирование как в Великобритании и Сингапуре. Здесь финансовая система зрелая и выверено законодательство. В этих странах основным двигателем прогресса цифровых финансов является политика государства, а не рынок или технологии. - Пассивное регулирование - оно применяется в развивающих странах. Здесь финансовый сектор развивается под влиянием капилата и рынка и в основном опирается на бизнес-модели, представленные на рынке. Четвертая часть книги посвящена тому, как США, Евросоюз и Великобритания строят свои карты развития цифровой экономики, а также формируют инициативы. Интересно, что большая часть перечисленных инициатив уже в прошлом, а значит можно оценить их эффект:) Ну и последняя, пятая часть книги посвящена тому, как цифровизация развивается в Китае. Ну и в текущих условиях мы можем видеть насколько у них успешно прошли 7 лет с 2017 по 2024. #Economics #Management #Leadership #History

T-Start Наша мобильная команда опубликовала новую версию мобильног iOS Тинькофф Банка в AppStore под названием "T-Start". Если у вас iOS, то рекомендую оперативно скачать эту версию и получить доступ к новым фичам, которые наши ребята разрабатывали последнее время.

Немного иллюстраций к "Морфологии волшебной сказки" Владимира Проппа

Морфология Волшебной Сказки (Рубрика #Writing) Недавно я прочитал эту книгу Владимира Проппа, которая вышла почти 100 лет назад. В этой работе Владимир предпринял попытку проанализировать то, как устроены волшебные сказки и как их можно сравнивать между собой. Изначально в книге он приводит примеры классификаций волшебных сказок по сюжетам или мотивам, но быстро показывает насколько это неконсистентно. В этой связи уместно вспомнить Борхеса и его вымышленную классификацию животных, согласно которому животные делятся на

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

Дальше автор предлагает пойти не от сюжетов и мотивов, а от их строения и составляющих. Такой подход оказывается чудо как хорош и дальше его продолжают применять в других работах, навроде, "Тысячеликого героя" Джозефа Кэпмбелла (у меня уже был пост про эту книгу). Сама книга достаточно лаконичная, так как автор уносит в приложения и отдельные работы большую часть проведенного анализа сказок, а в книге делится только основами своей теории и выводами. В итоге, книга состоит из 9 частей 1. К истории вопроса - глава, где автор рассматривает предыдущие подходы к снаряду 2. Метод и материал - здесь автор очерчивает то, что он называет волшебными сказками, которые он и анализирует в своем труде. Дальше показывает, что не важно какие именно персонажи есть в сказке - важно, что они делают и какие функции выполняют. Причем функция - это та поступки персонажа, которые значимы с точки зрения сюжета. А потом следует основные выводы: число функций в известных волшебных сказках ограничено, а мало того они еще и всегда идут в одинаковой последовательности. Поэтому мы получаем неожиданный результат: все волшебные сказки однотипны по своему строению. Интересно, что дальше в книге автор связывает волшебные сказки с мифами и религией. 3. Функции действущих лиц - основная часть работы, которая описывает 31 функцию, в которой у нас участвует герой, жертва, антагонист, даритель, помощники, ложный герой, ... В общем, эту часть интересно читать и видеть как разное поведение можно свести к общим функциям 4. Ассимиляции. Случаи двойного морфологического значения одной функции - здесь автор показывает как некоторые функции в процессе эволюции сказки сливаются воедино, например, есть отдельные функции в виде задачи и боя. Условно бой с драконом или решение сложного квеста царевны, но если царевна задаст задачку сразить дракона, то у нас тут налицо объединение функций:) 5. Некоторые другие элементы сказки - здесь разбираются связки разных функций, утроения (часто встречающиеся в сказках) и мотивироки поступков персонажей 6. Распределение функциий по действующим лицам - здесь автор показывает какие действия могут совершать разные типы персонажей 7. Способы включения в ход действия новых лиц - тут рассматриваются как эти типы персонажей подключаются к сюжету 8. Об аттрибутах действующих лиц и их значении - здесь автор рассказывает про совокупность внешних качеств персонажей и как они придают сказкам красоту и обаяние. Разбирается пример с Бабой-Ягой и ее избушкой, Иван-царевич, волшебные кони, прекрасные царевны. 9. Сказка как целое - а здесь автор берет свой инструментарий и разбирает несколько сказок, показывая как они раскладываются на функции и у нас получаются аля предложения, которые описывают сказку структурно, а дальше эту структуру сказок можно использовать для их классификации. Итого, это очень крутая работа для тех, кто интересуется написанием книг, сказками или просто любит искать паттерны в разных местах. Рекомендую покупать книгу в цветном издании с картинками, тогда ее гораздо приятнее изучать и погружаться в мир сказок:) #Writing #Patterns #History

An Introduction to Residuality Theory - Barry O'Reilly - NDC Oslo 2023 (Рубрика #Architecture) Интересное выступление про residuality theory от Barry O'Reilly, автора теории. Автор делает подход к созданию теории, что поможет инженерам прокачиваться в архитектуру не просто набивая опыт, а используя достижения complexity theory, но без погружения во всю ее сложность. Для этого автор начинает с определения упорядоченных и неупорядоченных систем, а дальше он показывает как стрессоры (неизвестные факторы) могут негативно влиять на архитектуру. С учетом вариативности окружающего мира проанализировать все состояния системы и влияние стрессоров на систему в этом состоянии не представляется возможным. Поэтому автор предлагает рассматривать систему не целиком, а изучать то, что остается от системы, если случается пи... (стрессор X). Эти остатки определяют будущее системы и могут быть использованы для управления архитектурой программного обеспечения. Для моделирования стрессоров нам поможет метод Монте-Карло с его рандомизацией, которую мы можем применить к возможным стрессорам. Дальше автор вводит рассказывает про аттракторы как устойчивые состояния, в которые скатывается система. Он приходит к ним через NK модель Кауффмана. У нас есть система с N элементами, принимающими значение 0 или 1, параметром K характеризующим связность (например, максимум связей одного элемента). Суть в том, чтобы показать, что при росте N и K у нас в системе увеличивается количество аттракторов. Заодно там появляется вероятностная характеристика P, которая характеризует bias связей между элементами. Финалом размышлений становится вывод некоторой выпуклой кривой критичности, которая вырисовывается в пространстве N и K, где мы играем с количеством элементов и связей между ними (еще один способ определить количество сервисов и связей между ними). В общем, для каждого стрессора, который ломает нашу начальную наивную архитектуру, мы придумывает доработку, которая позволяет архитектуре системы пережить наступление этого стрессора. Пробежавшись по всем стрессорам, мы получаем крутую residual architecture для нашей системы. Дальше автор приводит крутые примеры из дизайна системы для управления зарядными станциями для электромобилей. Ребята учли corner cases, которые бывают с зарядкой электромобилей и это помогло потом упростить решение проблем с людьми, что оставляют заряжать машины на целый день, а также с ребятами, что занимались саботажем. А вообще история прикольная и рекомендую посмотреть ее в оригинале. Ну и в финале автор рассказывает про составление матриц для описания связей между компонентами системы и факторами стресса. Эти матрицы помогают выявить нефункциональные требования и уязвимости в системе. В этой матрице у нас в строках приведены стрессоры, а в колонках - компоненты системы. В итоге, мы анализируем для каждого стрессора влияет ли он на компонент. Если несколько компонентов подвержены одному стрессору, то вероятно у них есть неявная связь (implicit coupling), с которой хорошо бы разобраться. В конце автор приводит способ померить крутость нашей residual architecture по сравнению с ее наивной версией. Схема выглядит так, что нам надо подсчитать для каждого стрессора - Переживает ли наша наивная архитектура его наступление - Переживает ли его наступление residual architecture - Из значения успехов для residual architecture вычесть количество успехов для наивной архитектуры, а потом отнормировать на общее количество стрессоров - Полученное число показывает насколько мы хорошо как архитекторы прокачали нашу начальную архитектуру:) В общем, все звучит достаточно логично и напоминает мне подход генеративно-состязательных сетей, но только к архитектуре. Дальше я планирую прочитать whitepaper "Residuality Theory, random simulation, and attractor networks" от автора доклада и рассказать про него:) #DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes

100 Things To Know About Oceans (Рубрика #Kids) Наш млалший сын очень любит книги про океаны и морских тварей, а также он ходит в английских детский сад. По этим причинам я решил прикупить для него эту красочную книгу с отличными картинками и очень интересными фактами про подводный мир. Читаем книгу мы примерно так: я читаю сначала интересный факт на английском, потом перевожу на русский, а потом мы обсуждаем сами истории: про огромные стаи рыб, горы под водой, пиратов, китов, жителей дна океана и так далее. В общем, книга очень нам нравится - многие факты внове и для меня, а детям нравится рассматривать иллюстрации и задавать уточняющие вопросы, а еще можно подкачать английский язык себе и детям:) #ForParents #ForKids

Designing for change with Vertical Slice Architecture - Chris Sainty - NDC London 2024 (Рубрика #Architecture) Интересный, но странный доклад про вертикальные слайсы как архитектурный концепт. Основная мысль в том, что нам стоит проектировать приложения с учетом изменений, так как изменения являются единственной постоянной в нашей отрасли. Дальше автор вспоминает предыдущие виды архитектур - Трехзвенная архитектура (n-tier), что была популярна во времена динозавров. В этой архитектуре у нас есть data access layer, business logic layer, user interface layer - Луковая архитектура, хорошо, что не липовая (onion) - в этой архитектуре центральным элементом являются бизнес-правила предметной области - Чистая архитектура от дяди Боба (что любит все чистое: код, архитектуру, agile) - микс лучших практик из других архитектур возведенный на уровень догм Дальше автор вспоминает что мы делаем код не ради красивой архитектуры (звучит лучше, чем чистая), а ради создания фичей внутри продукта и зарабатывания денег. Поэтому у нас есть ограничения и иногда нам фичи сделать важнее, чем сделать все по красоте. Так появляется техдолг и потребность в рефакторинге. Сейчас стандартным подходом является создание отдельных сервисов, но у нас появляются проблемы - High coupling и low cohesion (а нужно конечно наоборот) - Это приводит к сложности в изменении и обслуживании этих систем - У нас часто появляются проблемы с методами сервисов, которые имеют больше одной причины для изменений (продолжение single responsibility principle и separation of concern) - Само свойство систем приводит к большому количеству связей и повышению сложности, если мы не боремся с этим - Стандартная многозвенная архитектура нам не помогает - у нас есть проблемы с пониманием и изменением кода, так как надо держать все части приложения в голове. Также появляются проблемы со сложностью кода, производительностью и масштабируемостью систем. И автор предлагает серебрянную пулю в виде vertical slice architecture, где у нас - Организация кода предполагается по сценариям использования, а не по технической ответственности - Мы пишем отдельный код для слайсов, а не переиспользуем существующий - В слайсах мы пишем только тот код, что нужен сейчас. Если в будущем появится новые потребности, то мы добавим их в слайсы (все 100500, которые сделаем в рамках своей архитектуры) Дальше идут плюсы архитектуры, которые влияют на производительность разработчиков, так как она - Позволяет быстро создавать и тестировать функции, что облегчает обучение и понимание системы. - Упрощает разделение функций и масштабирование отдельных частей приложения Здесь мы легко обрабатываем срочность выпуска фич - Срочные функции могут быть созданы и протестированы быстрее, без компромиссов в коде (просто добавь воды сделай еще один слайс ) - Код под кастомного пользователя может быть написан в отдельной вертикали, что позволяет избежать загрязнения существующего кода - Технический долг и рефакторинг также могут быть выполнены более эффективно, так как мы можем его отдавать по слайсам Эта архитектура помогает также с огромными сервисами, которые появляются в чистой архитектуре. Вместо этого можно использовать MediatR, который реализует паттерн посредник, обеспечивающий взаимодействие множества объектов, формируя при этом слабое зацепление и избавляя объекты от необходимости явно ссылаться друг на друга. Ну и напоследок автор говорит, что некоторый код все-таки надо шарить (сюрприз) и автор предлагает правило трех (как правило трех конвертов), которое гласит, что если код повторяется три раза, его следует извлечь в новую процедуру. Но самое важное, что автор оставил напоследок это то, что модели предметной области хорошо подходят для совместного использования кода, так как они моделируют бизнес-правила и изменения в бизнесе. #Architecture #Software #SystemDesign #SoftwareArchitecture