Есть старая инженерная мудрость, которую на собеседованиях произносят с полуулыбкой, а на практике встречают с полным трепетом: продукт всегда похож на организацию, которая его сделала. Это закон Конвея, и в мире его прослеживается настолько пунктуально, что его уже перестали считать шуткой. Сформулированный в 1967 году программистом Мелвином Конвеем в статье с говорящим названием о том, как изобретают комитеты, закон гласит простую вещь: организация, проектирующая систему, вынуждена производить устройство, копирующее её собственную структуру коммуникаций. Программные системы выходят по форме коридоров, в которых ходят их создатели, и Windows, пожалуй, самый большой и самый почитаемый памятник этого закона в масштабе планеты.
Что именно говорит закон и откуда он взялся
Отточенный звук закона спокоен и строг: команды проектантов должны общаться, чтобы совместимость между частями работала, а где общение трудно, там и стык делается жёстким, формальным, полным договоров вместо живого диалога. Технические границы подсистем поэтому неизбежно совпадают с границами людских команд, и всякое большое программное сооружение выдаёт в своей анатомии структуру совещаний, иерархии и инстанций фирмы-производителя.
Сам Конвей замысливал закон шире, чем о программах, и научный мир встретил идею с интересом: на симпозиуме по модульному программированию 1968 года наблюдение звучало достаточно серьёзно, чтобы получить имя закона. Позже исследователи из влиятельных бостонских школ говорили уже о "гипотезе зеркала" и подтверждали её на опыте: продукты слабосвязанных организаций и вправду демонстрируют другую архитектуру, чем продукты монолитных структур.
Закон в строгом виде не утверждает направление причинности. Одни толкователи видят в нём силу, которая заставляет организацию перестраиваться по форме продукта, другие - прямое давление коридоров на чертёж. Третьи честно замечают: всё перемешано, и это скорее симфония взаимного притирания, чем монолог одной из сторон. Для читателя важно одно: связь никуда не девается, и любой, кто хочет понять архитектуру большой системы, обязан в некоторой мере разбираться и в архитектуре её ведомства.
Windows как дом, построенный множеством команд
Взгляните на операционную систему Windows глазами, натренированными законом Конвея, и многое мгновенно становится на место. ОС строится как слоёвка из зрелых компонентов: ядро и его ближайшее окружение, подсистемы ввода-вывода, графическая инфраструктура, оболочка, службы безопасности, настройки, магазин приложений, десятки сервисов и консолей. Каждый из этих блоков это не только конструкция в коде, а целиком исторический придел, за которым проступает силуэт конкретной команды с её начальством, привычками и сроками.
Раздвоенность старой панели управления и новых настроек, по которой путешествует пользователь, отражает не художественный каприз проектирования, а длинную институциональную автобиографию: одна эпоха интерфейсов сменялась другой, команды менялись, приоритеты переносились, сроки поджимали, и в результате два мира оказались аккуратно залиты в одном корпусе, перекинутые мостиками из пунктов меню. Кто провёл десятилетие в ведомственной жизни, тот без труда прочтёт в этом дуэте свой будничный сюжет про "старую команду и новую команду".
Ровно та же логика видна в ритме реорганизаций. Когда в компании укрупнялись или делились отделы, ответственные за систему, архитектурные линии продукта отзывались почти физически: выделялись платформы, менялись границы подсистем, перепривязывались службы к новым центрам ответственности. Знаменитая иллюстрация закономерности пришлась на времена больших корпоративных перестроек десятых годов, когда известные манёвры с крупными подразделениями ощутимо изменили и саму траекторию развития системы: границы продуктов переехали в обозримом направлении после того, как переехали границы отделов.
Примеры, где коридорное зеркало видно почти без специальных приборов
Закон Конвея редко обнаруживается прямым указанием, но он рассыпается по множеству деталей. Если в операционной системе сосуществуют два почти одинаковых механизма настройки, судьба их почти наверняка наследует разные эпохи и разные отделы ответственности. Если звуковая подсистема ощущается как отдельный континент с собственной логикой и службами, так вероятнее всего и есть. Если прилагаемая карта продуктов компании кажется вам подозрительной, достаточно взглянуть на организационную диаграмму десятилетней давности, и совпадения начнут проступать как на фотоплёнке.
Социологи и бухгалтеры крупной разработки давно пользуются этим приёмом для чтения систем: изучая структуру модулей, можно восстановить заседательную жизнь фирмы и наоборот. Для Windows, где почти полвека работы сменяли несколько поколений управленческих стилей, история читается особенно ярко: где-то находил смелость целый пласт, отполированный централизованной волей единой руки, где-то по горизонтали раскатывались параллельные ветки от разных команд, а где-то спокойная береговая линия компонента десятилетиями оставалась неизменной, потому что за него отвечала маленькая и очень стабильная группа.
Отсюда и неслучайно звучит здесь и уважительный тезис работы с наследством: части системы, принадлежащие большим переписанным командам, переписываются чаще, и вовсе не потому, что там больше ошибок, а потому, что новые отделы любят начинать с больших перемен. Организационное любопытство замешено в структуру поверх любых строгих технических резонов, и честный читатель это видит.
Обратная сторона закона и возможность его использовать
Важное следствие закона Конвея состоит в том, что он работает в обе стороны, и это даёт в руки грамотным руководителям настоящий инструмент. Хотите определённую архитектуру у продукта - постройте команду, способную её нести. Расчленённый на аккуратные микросервисы продукт потребует соответствующих автономных взводов, монолитная вещь сбережётся целой у большой сильной группы. Современные практики архитектурных преобразований в крупных компаниях откровенно рядят с изменением структуры команд по принципу обратного Конвея: сначала строим организацию под желаемую систему, потом система неумолимо начинает принимать задуманную форму.
Памятки команде разработки из этого закона просматриваются прозрачно:
- Принимая архитектурное решение, отдайте себе отчёт, какая команда будет владеть каждым блоком в долгую;
- Если границы компонентов невыяснены, сначала проясните границы ответственности людей;
- Избавляйтесь от дублирования не декретами, а объединением владения;
- Знакомясь с чужой большой системой, не стыдитесь спросить у её истории, кто и когда за что отвечал;
- Любая боль в архитектуре - это сначала боль в организации, а потом уже в коде.
Принцип выглядит философией, но на практике означает довольно приземлённые способы действовать: правильно расставить полномочия командам, договориться о точках стыков, не создавать тройного владения никаким компонентом. Крупные преобразователи индустрии говорят об этом языком отрезвляющей реальности: закон Конвея умеет наказывать тех, кто делает вид, что его нет.
Шкала явления от телефонного справочника до архитектуры ядра
У закона Конвея обнаруживается забавное свойство масштабируемости: он одинаково честно работает и на панели быстрого набора, и на структуре ядра. Маленькая команда хранит мало документов, и её система получается совсем соразмерной компактной. Десятки тысяч человек с десятилетиями переписки создают сооружение, в котором можно летать между ревизиями и барокко поздних украшений. Вид закона под этим углом предлагает комфортный совет: не обвиняйте большие системы в громоздкости, пока не узнаете, сколько людей их строит, потому что громоздкость там правило, а не сбой.
Для Windows это означает одну конкретную вещь: слоистость, иногда раздражающая пользователя, это цена непрерывной разработки при длинной памяти. Команды, живущие в ритме коротких циклов сбора, физически не могут единообразно переписывать пласт за пластом, и любые гигантские развороты на девяносто градусов превратились бы в организационные перипетии гигантской стоимости. Архитектура системы в этом смысле это не недочёт, а налог на непрерывность и совместимость с миллиардом устройств и десятилетиями кода.
Примирение с отражением
Знайте правило зеркала или не знайте, оно работает молча в одном и том же ритме. Проектировщики интерьеров офисов шутят, что планировка этажа это диаграмма процессов компании, но закон Конвея идёт дальше: он работает не со стенами, а с самыми нежными архитектурами, со структурами данных и с границами модулей. Чем раньше команда признаёт его, тем меньше слёз льётся над неудачными диаграммами. А операционная система, в которую вы загружаетесь каждое утро, остаётся самой большой из наглядных агитаций на свете: смотрите, мол, во что превращается совещание, если его проводить сорок лет кряду.
Что из закона вынести домой рядовому читателю
Совсем необязательно управлять корпорацией, чтобы применять наблюдение Конвея. Любая развесистая структура, будь то семейный бюджет в таблицах, личный проект с папками на диске или простая доска с задачами на холодильнике, рано или поздно начинает перенимать топологию своих хозяев: папки разводятся по членам семьи, задачи группируются не по смыслу, а по половинам комнаты. Понимание этого механизма освобождает от лишних претензий к себе и к другим: если система неудобна, возможно, мы её просто случайно отзеркалили к тому виду, в котором живём.
В следующий раз, когда в Windows что-то покажется вам странным отголоском старой эпохи, невольно подумайте: за этой гранью, очевидно, стоит коридор, в котором когда-то ходили люди со своими сроками, планёрками и постерами. Операционная система - летопись таких коридоров, и закон Конвея это всего лишь почти физическое следствие того, что любые сложные существа на свете, в том числе гигантские программы, строятся людьми по образу и подобию их общения.
И если маленькая формула нужна на память, пусть она будет такой: архитектура это застывшая переписка. Модули это абзацы, границы это абзацные отступы, древние компромиссы это исторические вставки, а весь документ продолжает писаться ежедневно большим коллективом авторов. Кто умеет читать эту переписку, тот не удивляется капризам большой системы, а бережёт от неё главное, способность каждое утро включаться и работать на человека.
Отдельной страницей стоит и привычный бытовой опыт администраторов. Спросите у любого ветерана больших сетей, как он понимает, почему две соседние службы ведут себя несогласованно, и он, подумав, ответит вам про разные команды сопровождения, разные регламенты и разное чувство срочности у этих служб. Его ответ окажется технически несовершенным и стопроцентно верным по сути, потому что за артефактом всегда стоит коллектив, а у коллектива всегда есть своя погода. Умение слушать эту погоду отличает зрелого инженера: он не делает вид, что продукт рождается из чистой логики, а смотрит на него как на продолжение разговора людей, иногда громкого, иногда вполголоса, но всегда человеческого до донышка.
Законченный образ этой статьи попадает в коллекцию уважительных вещей, которые можно сказать про любую большую программу вообще и про Windows в частности. Система больше не просто инструмент и не просто текст в репозитории: она архив совместной работы десятков тысяч людей на протяжении почти четырех десятилетий, со всеми следами их согласований. В следующий раз, наткнувшись на нестыковку в настройках, посмотрите на неё глазами исследователя: перед вами, вполне возможно, застывший след старого совещания, и относиться к нему стоит не с досадой, а с интересом археолога, которому повезло увидеть историю вживую у себя на рабочем столе.