Обзор книги “A Philosophy of Software Design” — Part I

Раньше я уже рассказывал здесь про John Ousterhout, создателя Raft, который на мероприятии “Talks at Google” рассказывал о философии проектирования программного обеспечения. В этом выступлении он за час рассказал краткое содержимое своей книги, которое мне очень понравилось. В итоге, я не смог удержаться и заказал бумажную версию книги, прочел ее и дальше решил написать краткий обзор. Первая часть обзора доступна на моем Medium - https://apolomodov.medium.com/review-a-philosophy-of-software-design-part-1-980697f52698

Очень рекомендую прочитать книгу в оригинале, она тонкая, но наполнена очень крутыми мыслями - по концентрации их она у меня на первом месте😁

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Philosophy #Architecture

Explainable AI Explained for Developers • Joop Snijder & Willem Meints • GOTO 2022

Я возобновил свои походы в фитнес, где я обычно занимаюсь кардио на эллиптическом тренажере.
А так как крутить педали просто так скучно, то я обычно успеваю посмотреть какое-то выступление с конференции. Именно так я вчера смог посмотреть доклад про explainable AI с последней конференции GOTO, что проходила в Нидерландах. Сам доклад мне понравился
- спикеры рассказали как ML становится вездесущим
- потом начали рассказывать про то, как ML может помочь фейвовой компании, которая продает кофе по подписке
- рассказ перешел в демо по использованию Auto ML в Azure для предсказания оттока подписчиков
- а потом авторы начали задаваться вопросами, а что делать с результатами предсказаний - так они подошли к заявленной теме, а именно, что обычно требуется умение понимать результаты

Все вопросы в выступлении рассматриваются на уровне погружения, который есть у среднего разработчика без глубоких деталей ML и вот этого всего:) А на выходе слушатели получают неплохое понимание о том, что сейчас ML тоже стремится в сторону commodity (особенно с появлением Auto ML), но вот вопрос хранения данных, их подготовки, деплоя модели и интерпретации результатов требует определенных скилов у инженеров, которые при помощи Auto ML пока не решаются:)

#ML #Conference #Software

Prioritizing Technical Debt as If Time & Money Matters • Adam Tornhill • GOTO 2022

Крутой доклад от Адама Торнхилла, который продолжает тему complexity в разработке ПО, которая была главной в книге A Philosophy of Software Design, которую я вспоминал вчера.
Сначала автор приводит Lehman's "Laws" of Software Evolution, которые показывают почему вопрос управления сложностью важен
- Continuing change - система должна постоянно адаптироваться или она будет прогрессирующе становиться менее приемлемой
- Increasing complexity - по мере эволюции системы complexity возрастает, пока не будут выполнена работа по поддержке или уменьшению complexity
Это накопление complexity приводит к появлению технического долга, который замедляет time to market, снижает предсказуемость работы над системами, приводит к организационным проблемам, а также снижает возможности к инновациям.
Дальше автор предлагает способы его померить при помощи Behavioral Code Analysis, который состоит из трех компонент: code, people, context. Все это можно подтянуть из VCS. Автор предлагает мерить 2 параметра
- Code complexity - метрика сложности кода, про нее чуть дальше отдельно
- Code change frequency - метрика частоты изменения кода (тут просто количество изменений кода за период времени)
В сумме эти два параметра позволяют понять какие части кода являются сложными и которые приходится часто править.

Code Complexity автор предлагает мерить опять не одной метрикой, а используя набор метрик для оценки здоровья кода:
- На уровне модулей - low cohesion (слишком много ответственности на классе), brain class (low cohesion, + как минимум один Brain метод, который большой, сложный и централизует поведение модуля)
- На уровне функций - brain methods, copy-pasted logic
- На уровне имплементацииl - deeply nested logic, primitive obsession

Дальше автор показывает пример анализа кодовой базы Android для того, чтобы продемонстировать свою концепцию. Распределение частотности работы с разными файлами выглядит как распределение с длинным хвостом, поэтому часто изменяющихся файлов не так много и только часть из них сложные. Собственно нам надо начинать работу с нашим техдолгом именно с этих файлов, а остальные можно игнорировать - это прагматичный, экономически-обоснованный подход. Интересно, что автор утверждает, что это стандартная картина для всех проектов, что он видел. А дальше он находит проблемный файл ActivityManagerService.java и делает drill down, чтобы показать как найти место внутри этого файла, где сконцентрированы основные проблемы - собствеенно это он и называет X-Ray.

Дальше идет рассказ про legacy code, который он определяет следующим образом:
- Lacks in quality - стандартное определение
- We didn't write ourselves - не совсем стандартная часть:) которая мешает начать рефакторить свой код вовремя
Дальше автор рассказывает забавную историю про анализ трех разных проектов, где два были свои родные, а один приемный. Они были сравнимы по качеству, но переписать хотели только чужой проект, так как на него пало подозрение в том, что он legacy:)

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

P.S.
У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран.

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management

Плакат от МИФа «Креативные техники»

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

#Creativity

Distributed Systems, 4th Edition (Рубрика #Architecture)

Полгода назад я рассказывал как дочитал книгу ван Стина и Таненбаума по распределенным системам. Она настолько мне понравилась, что я написал краткое саммари первой главы, в которой авторы делали краткий обзор всех тем книги. Дальше эту книгу выбрали слушатели клуба Code of Architecture, чтобы мы начали читать и обсуждать ее ... А дальше авторы выпускают в январе 2023 года новое издание книги, доступное бесплатно на сайте авторов.
В общем, эта книга - отличный подарок к началу нового года:)

#Architecture #SoftwareArchitecture #DistributedSystems #Software #SystemDesign

NASA Systems Engineering Handbook

Кто в детстве не мечтал стать космонавтом? И несмотря на то, что мечты не сбылись, но вот книжку про то, как космонавты проектируют свои системы я себе заполучил, причем заполучил в бумаге.
Для тех, кому бумага не принципиальна, pdf доступен на сайте nasa.

Отдельно отмечу, что сегодня при обсуждении Distributed Systems мы упоминали проектирование для mission critical доменов, навроде медицинских устройств или космических аппаратов для космонавтов.

#SystemEngineering #Processes #Management

Team Topologies, Software Architecture & Complexity • James Lewis • GOTO 2022

Еще одно интересное выступление с амстердамской конференции GOTO, в заглавии которого вынесены термины, которые я сам часто использую: топологии команд, архитектура, сложность.
Автор начинает рассказ с вступления, в котором он говорит про популярность микросервисной архитектуры и почему она стала такой популярной и что лежит за этим.
Автор концентрируется в своем выступлении на 4 аспектах:
- componentization via services
- organized around business capabilities
- products not project
- decentralized governance

Дальше автор вспоминает про сложности организационного дизайна и так приходит к книге "Team Topologies", про которую у меня есть серия статей с ее обзором:
- Teams as means of Delivery
- Team Topologies that work for flow
- Evolving team interactions for innovation and rapid delivery
И вспоминает он про нее в контексте фразы кого-то из Amazon "The bigger we get, the easier it becomes to get bigger" и смысл тут в том, что цель успешного орг дизайна в том, чтобы оптимизировать структуру под поток ценности, а именно это и помогает сделать подходы из team topologies. Забавно, что автор показывает как выглядит процесс создания value (на диаграммах, которые похожи на те, что остаются после Event Storming) и насколько там мало самого программирования:)

Дальше автор переходит к архитектуре программного обеспечения и как она помогает бороться со сложностью окружающего мира и наших решений, которые моделируют его. Рекомендую на эту тему почитать книгу "A Philosophy of Software Design" (у меня есть краткое саммари: 1, 2). В этой книге очень классно разбирается вопрос сложности и борьбы с ней при создании программного обеспечения. Потом автор приходит к понятию complex adaptive system (млекопитающие, города, создание софта?) и показывает какие у них бывают свойства (self-similarity, self-organization, complexity, emergence) и как там работают степенные законы для экономии на масштабе и убывающей полезности по мере масштабирования (кроме Amazon, у которой полезность не убывает - правда, это может быть связано с сетевыми эффектами многосторонних платформ, подробнее в книге "Machine, Platform, Crowd"). В итоге комплексные адаптивные системы оказываются везде вокруг нас и иерархии в них приводят к фрактальным эффектам с эффектом от масштабирования с экспонентой и числом меньше единицы в знаменателе.

После этого автор описывает корпоративный метаболизм - так как организации это тоже complex adaptive system, то по мере масштабирования у них растет количество уровней иерархии и revenue масштабируется сублинейно и метаболизм замедляется. Автор приводит прикольный пример с метаболизмом слона и мыши. Слону надо есть гораздо меньше еды в процентном соотношении от своей массы, чем мыши. Но, одновременно, у слона метаболизм настолько медленный, что он не более раком - клетки просто не успевают состариться. Похожее происходит и в крупных компаниях. Дальше автор рекомендует книгу "Accelerate", которая позволяет мониторить здоровье организации через метрики: MTTR, cycle time, change failure rate, number of deploys.
В крупных организациях меньше идет бюджета на R&D, больше процессов и бюрократии, а также иерархий.

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

#TeamTopologies #Software #Architecture #SoftwareArchitecture #Management #Processes #SystemDesign

В этот понедельник, 15 января, мы провели первый стрим по книге “Distributed Systems”, в котором мы начали обсуждать новое издание этой книги, которая вышла в начале января. В этом эпизоде мы обсудили первую главу "Introduction".
Гостями стрима были
- Александр Краснов, CTO Тинькофф Страхования
- Антон Костерин, который вместе с с моей командой разрабатывает сервисы по управлению сайтом Тинькофф и мобильным банком

Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software