Tudor Girba: от чего зависит объясняемость системы (ПО)
—
08 октября 2024 (обновлено 27.10.2024)
CEO feenk, разработчик приложения Glamorous Toolkit. Один из авторов и идеолог подхода Moldable Development в разработке ПО.
За автором и его приложением наблюдаю уже несколько лет, оно включено сразу в два моих списка (аутлайнеры и malleable software), поэтому отслеживается в рамках направления «Outline-mode».
Собрал несколько своих постов по данной теме в виде единого материала и расширил их свежей информацией.
Tudor Girba в начале октября выступал с докладом на конференции GOTO Copenhagen 2024, после чего по его мотивам опубликовал серию твитов (с 6 по 16 октября, затравочный пост) 🔻
Tudor Girba в своих постах часто использует чуть-чуть другой вариант этой же схемы.
—
Объясняемость системы (systems explainability) зависит от:
- самой системы,
- того, как вы извлекаете из нее информацию, и
- того, как вы используете информацию.
Если вы пытаетесь сделать системы объяснимыми только путем изменения самой системы, вы упускаете возможности, предоставляемые двумя другими рычагами.
—
При этом:
Объяснимость системы в большей степени зависит от того, как вы ищете объяснение, чем от того, что вы пытаетесь объяснить.
—
На «GOTO Copenhagen» я попросил аудиторию из нескольких сотен разработчиков поднять руки, если они тратят более 50% своего времени на чтение кода. Почти все подняли руки. Затем я сказал им, что это самая большая проблема, которую нужно решить в программной инженерии на сегодняшний день.
Разработчики читают код, потому что они хотят понять достаточно, чтобы принять решение о том, как изменить систему. Деятельность — это принятие решений. Чтение — это всего лишь средство извлечения информации из системы. Достаточно интересно, что не только разработчики полагаются на эту информацию: она нужна и пользователям домена, и бизнесу для принятия решений.
Плохая новость в том, что чтение — это самый ручной способ извлечения информации из систем. Проблема только усугубляется, когда информация вручную собирается в представления, которые документируют убеждения авторов о системе, а не саму систему.
Почему?
Потому что системы меняются. И потому что люди могут прочитать только часть всей системы. На основе этого они делают выводы об остальном, и это приводит к решениям, которые не соответствуют действительности.
Хорошо, это плохие новости. Но я также спросил аудиторию, рассказывают ли они о том, как они читают код. Оказалось, что они этого не делают. Если мы не говорим об этом, это не является явным. Если это не является явным, это также не оптимизировано. Это отличная новость, потому что это означает, что у нас есть возможность для большого улучшения.
Мы можем оптимизировать его с помощью инструментов. Но поскольку программное обеспечение сильно зависит от контекста, нам нужны специальные инструменты, созданные в процессе разработки. Конечно, эти инструменты должны быть запрограммированы, но приятно то, что разработчики уже знают, как программировать. Да, нам действительно нужен особый способ программирования, но это всего лишь еще один технический навык, который не так уж сильно отличается от тех навыков, которые уже существуют.
Как только у нас появляется инструмент, который обобщает систему с нашей точки зрения, мы можем генерировать представления в любое время и в актуальном состоянии. Представления становятся товаром (commodity), и это трансформационно (преобразует нас), потому что мы тратим большую часть энергии не на то, как мы извлекаем информацию, а на то, что мы делаем с информацией.
Хорошо, как это может быть практичным — создавать так много инструментов, учитывая, что инструменты дороги в создании и обслуживании?
Что ж, создание инструментов не обязательно должно быть дорогостоящим. Существует системный подход к ним. Вам действительно нужны специальные навыки и технологии, но это возможно.
Мы создали Glamorous Toolkit как бесплатный и с открытым исходным кодом, чтобы показать, что практично создавать тысячи инструментов для каждой системы. Инструмент для каждой отдельной проблемы разработки. Вы можете попробовать его самостоятельно.
Но на самом деле технология второстепенна. Самая важная часть — это то, как сгенерированные представления позволяют создавать новый набор появляющихся практик. Разговоры сосредотачиваются вокруг системы как основного источника истины, а оценки становятся основанными на гипотезах. И это основано на новом наборе практик, известных как Moldable Development, с помощью которых мы проводим исследование.
—
Вот 👇 как мы, feenk, справляемся с каждой системной проблемой, с которой сталкиваемся. От мельчайшей ошибки до масштабной миграции.
Наш достаточно хороший путь к принятию разумных решений:
- Мы начинаем с вопроса о системе.
- Мы отвечаем на вопрос, создавая инструмент.
- Каждый инструмент создается за минуты, часы или дни.
- Каждый инструмент, который мы создаем, помогает нам понять, как все сочетается в модели системы, как будто мы собираем пазл из кусочков.
- По мере расширения модели системы мы можем задавать больше вопросов.
- Конечная цель — создать достаточно хорошую модель, которая позволит нам принимать разумные решения о системе.
Небольшой вояж в историю
В течение целого десятилетия автор с коллегами занимались исследованиями того, как разработчики работают с IT-системами, в результате пришли к тому, что назвали moldable development.
В 2021 году была опубликована статья Developers spend most of their time figuring the system out, которую можно назвать прологом к той серии постов, что размещена выше.
В статье дают два примера сторонних исследований, на что уходит время разработчиков. Оказывается, что две трети времени программиста уходит на поддержку проектов. Из которых львиную долю отнимает погружение в проблему / систему. Спустя четверть века, прошедших между разными исследованиями, можно констатировать: время на понимание программ практически не изменилось.
Центральная схема и мысль из статьи (непосредственно в материале есть подробные пояснения к данной схеме):
Инструменты должны соответствовать контексту.
Так как в программном обеспечении многое зависит от контекста, мы не можем предсказать конкретные проблемы. Только классы проблем. Ключевая идея moldable development — после определения проблемы изготовить инструмент для её изучения. Таким образом, инструмент будет работать с учётом контекста, а для его применения не нужно будет тратить время на чтение кода. Конечно, чтобы это было практично, стоимость создания специальных инструментов должна быть небольшой.
Дополнительные референсы
➊ На book.gtoolkit.com в виде статичного сайта опубликована книга по приложению Glamorous Toolkit.
Большая часть справочных материалов были и ранее доступны внутри самого приложения, ещё и в интерактивном формате. Но для этого надо было его устанавливать, потом разбираться «как оно вообще работает» :0)
Теперь можно и так статьи почитать. В них также есть ссылки на видеообзоры.
—
➋ В справке Glamorous Toolkit есть выделенный раздел с примерами применения Pattern Language для Moldable Development. Здесь он применяется в его оригинальном значении:
Pattern Language — это организованный и последовательный набор паттернов, каждый из которых описывает проблему и суть решения, которое можно использовать разными способами в конкретной области знаний. Этот термин был придуман архитектором Кристофером Александром и популяризирован его книгой 1977 года «A Pattern Language».
Полезная вещь для ознакомления и расширения кругозора.
—
➌ Интересный пример совместного использования Glamorous Toolkit и TiddlyWiki с пошаговым описанием.
Для их интеграции оказывается есть готовая утилита TiddlyWikiPharo:
Utilities for working with TiddlyWiki non-linear web notebook inside the Pharo/GToolkit computing environment. This allows import/export, visualize and manipulate Tiddlers inside Pharo/GToolkit, and to build data narratives involving TiddlyWiki.