§8.06 Интерфейс: правила взаимодействия
Время: 60 мин чтение + 40 мин = 100 мин Что узнаешь: что такое интерфейс между системами, почему хороший интерфейс скрывает внутреннее устройство, и как описывать взаимодействие так, чтобы оно не ломалось при изменениях
В одном предложении: интерфейс — это не кнопка или экран, а договор между системами о том, как они обмениваются; если этот договор не записан явно, системы перестают понимать друг друга при первом же изменении внутреннего устройства одной из них.
Сигнатура понятий:
- Интерфейс — это совокупность правил, по которым система взаимодействует с другими системами; граница, где заканчивается внутреннее устройство одной системы и начинается внутреннее устройство другой.
- Интерфейсная спецификация — это формальное описание интерфейса: форматы данных, протоколы обмена, ограничения, допустимые и недопустимые входы; контракт между системами.
- Скрытость реализации — это принцип, при котором внутреннее устройство системы скрыто за интерфейсом; позволяет менять устройство без нарушения связей с другими системами.
Мем, который снимается. «Интерфейс — это дизайн кнопок и цвета экрана». Нет. Интерфейс — это договор. Кнопки и цвета — это одна из реализаций интерфейса для человека. Но системы взаимодействуют друг с другом без кнопок. API - тоже интерфейс. Формат файла - тоже интерфейс. Протокол передачи данных - тоже интерфейс. Если вы думаете об интерфейсе только как о том, что видит пользователь, вы упускаете значительную часть взаимодействий в системе.
Определение из источника.
В Pack интерфейс определён как совокупность правил взаимодействия системы с окружением. Существенное свойство: интерфейс — это граница системы (§3.02), которая отделяет внутреннее устройство от внешнего мира. То, что происходит за границей интерфейса, внутри системы, не должно влиять на тех, кто использует интерфейс.
Хороший интерфейс имеет три свойства:
- Явность - правила записаны и доступны всем сторонам. Нет негласных договорённостей.
- Стабильность - интерфейс меняется реже, чем внутреннее устройство. Если интерфейс меняется каждую неделю — это не интерфейс, это хаос.
- Минимальность - интерфейс содержит только то, что нужно для взаимодействия. Лишние элементы — это лишние зависимости, которые будут ломаться.
Интерфейсная спецификация — это формализация договора. Она отвечает на вопросы: какой формат данных? Какие операции допустимы? Какие ограничения? Что происходит при ошибке? Без спецификации интерфейс существует только в головах участников, и эти головы расходятся.
Скрытость реализации — это следствие хорошего интерфейса. Если интерфейс стабилен и явен, система может менять внутреннее устройство: заменять технологии, оптимизировать процессы, перестраивать архитектуру, и всё это не ломает связи с другими системами. Потребители интерфейса даже не узнают о переменах. Это ключ к эволюции системы без разрушения экосистемы.
Связь с предыдущими подразделами: интерфейс — это граница черного ящика (§8.01). Снаружи видны только входы и выходы, формализованные интерфейсом. Внутри лежит прозрачный ящик (§8.02), который может меняться, пока интерфейс стабилен. §8.05 показало, как строить модели уровнями; интерфейс — это уровень 0, который остаётся стабильным, пока меняются уровни 1–3.
Развитие мысли.
Люди склонны недооценивать интерфейсы, потому что они невидимы, когда работают. Когда два человека договариваются «по-хорошему», они не записывают правила, и всё работает, пока оба помнят договорённости. Но когда один из них меняет «внутреннее устройство» (меняет процесс, переходит на новый инструмент, уходит в отпуск, забывает), интерфейс ломается, и никто не понимает почему.
Договорённость между людьми — это тоже интерфейс. «Присылай мне отчёт по пятницам в формате PDF» — это интерфейсная спецификация. Если один день вы пришлёте отчёт в Excel, а другой - в виде устного сообщения, интерфейс нарушен. Получатель тратит время на адаптацию вместо работы с содержанием.
Через IWE: MCP-протоколы — это интерфейсы между агентами и инструментами. Агент отправляет запрос в строго определённом формате. Инструмент отвечает в строго определённом формате. Если инструмент меняет внутреннюю логику, но сохраняет формат ответа - агент не замечает изменения. Если инструмент меняет формат - ломается весь pipeline. Формат — это интерфейс. Логика — это реализация.
Формат Pack-записей - интерфейс между пилотом и агентом. Пилот пишет заметку в определённой структуре. Агент читает эту структуру и понимает, что делать. Если пилот начинает писать «как получится» - агент не понимает. Если агент начинает ожидать другую структуру - Pack ломается. Стабильность формата - условие существования системы.
Скрытость реализации работает и в организациях. Отдел продаж взаимодействует с отделом производства через интерфейс: заявка на производство. Пока формат заявки стабилен, производство может менять внутренние процессы как угодно: автоматизировать, перестраивать смены, менять поставщиков. Отдел продаж об этом не узнает - и это хорошо. Проблема возникает, когда производство меняет формат заявки, не предупредив продажи. Интерфейс сломан.
Метод - минимальный шаг. Практика «Опиши договор» (40 мин):
- Выберите две системы, которые взаимодействуют в вашей работе: два отдела, два инструмента, два процесса (5 мин).
- Опишите интерфейс явно: что передаётся из системы А в систему Б? В каком формате? С какой периодичностью? (10 мин).
- Опишите обратный интерфейс: что передаётся из системы Б в систему А? В каком формате? (10 мин).
- Проверьте скрытость реализации: можете ли вы изменить внутренний процесс одной системы, не меняя описанного интерфейса? Если нет - где интерфейс «протекает» во внутреннее устройство? (10 мин).
- Запишите интерфейсную спецификацию в Pack: формат, правила, ограничения, контакт при изменениях (5 мин).
Пример из жизни. Ольга работала в издательстве. Отдел редакции передавал макеты в отдел печати через общую папку на сервере. Формат файлов - InDesign. Интерфейс был неявным: «кладём в папку, когда готово».
Редакция решила перейти на новую версию InDesign. Макеты стали сохраняться в новом формате. Печать не могла их открыть - у них была старая версия программы. Производственный цикл остановился на два дня, пока IT не установил обновления.
Проблема была не в том, что редакция обновилась. Проблема была в том, что интерфейс «протекал»: формат файла — это не просто формат, это часть интерфейса. Если бы интерфейс был явным и включал спецификацию формата, редакция бы поняла, что обновление InDesign — это изменение интерфейса, которое требует согласования с потребителем.
Ольга описала интерфейсную спецификацию: «От редакции в печать: файлы в формате PDF/X-1a (не InDesign!), в папке /Print/YYYY-MM-DD/. Срок - не позднее 18:00 за день до печати. Формат PDF/X-1a стабилен: печать может открыть его любой версией софта. Редакция может менять внутренние процессы (InDesign, Figma, ручная вёрстка) - печать об этом не узнает, пока на выходе PDF/X-1a».
Скрытость реализации заработала: редакция перешла на Figma для некоторых проектов - и печать не заметила разницы, потому что интерфейс (PDF/X-1a) остался прежним.
Типичная ошибка. «Мы работаем давно, и так всё понятно». Это самая опасная иллюзия. «Понятно» — значит «пока ничего не меняется». Но системы меняются. Человек уходит, процесс обновляется, инструмент заменяется - и «понятно» превращается в «никто не знает, почему это сломалось». Интерфейс нужен именно потому, что системы меняются. Явный интерфейс — это страховка на случай изменений.
Вторая ошибка - смешивать интерфейс и реализацию. Когда система А требует от системы Б не только определённого формата ответа, но и определённого способа его получения - интерфейс «протекает». Например, если интеграция требует прямого доступа к базе данных вместо API — это не интерфейс, это проникновение. Такая «интеграция» работает, пока структура базы не изменится. Когда изменится - сломается всё.
Третья ошибка - менять интерфейс без предупреждения. Даже если интерфейс был явным и стабильным, его изменение должно быть объявлено заранее. Системы, которые зависят от интерфейса, должны иметь время адаптироваться. Иначе изменение интерфейса — это разрушение связей, а не эволюция.
Степени мастерства:
Объясняю. Могу отличить интерфейс от реализации, назвать три свойства хорошего интерфейса и привести пример интерфейсной спецификации Критерий: один раз выполнил практику «Опиши договор"
Умею. Могу для двух систем, с которыми работаю, описать интерфейс явно и проверить, не протекает ли он Критерий: есть запись одной интерфейсной спецификации в Pack
Навык. Автоматически описываю интерфейсы при изменении процессов; ловлю моменты, когда системы взаимодействуют «по-хорошему» без явного договора Критерий: коллеги отмечают, что я «сначала описываю правила, потом меняю процесс»; или: могу привести 3 эпизода, где явное описание интерфейса предотвратило сбой при изменении
Мастерство. Проектирую системы со стабильными интерфейсами, которые позволяют эволюционировать внутреннему устройству без разрушения связей; внедряю культуру интерфейсной спецификации Критерий: есть кейс, где спроектированный мной интерфейс выдержал изменение внутреннего устройства одной из систем без доработки со стороны потребителей
Проверка себя.
- Понимание: вы можете взять любое взаимодействие в вашей работе и ответить: какой формат обмена? какие правила? что произойдёт, если одна сторона изменит внутренний процесс?
- Поведение: когда вы меняете процесс, вы сначала проверяете, не нарушает ли это интерфейс с другими системами - и если нарушает, предупреждаете заранее.
- Застревание: если вы тратите время на выяснение «почему это сломалось» после изменения в одной системе - вероятно, интерфейс был неявным или отсутствовал. Найдите взаимодействие, опишите его интерфейс, зафиксируйте в Pack.
Что дальше. Интерфейс — это граница системы. Но граница не просто разделяет «внутри» и «снаружи» - она определяет, как система существует в контексте других систем. Следующий подраздел - о том, как описывать свойства системы: характеристику, состояние и показатель, чтобы управление было основано на числах, а не на впечатлениях. См. §8.07.