В данной статье объясняется Закон Хайрама, о сути которого многие могли даже не догадываться.

"При достаточном количестве пользователей API становится не так важно, что вы обещаете в контракте: все наблюдаемые изменения вашей системы будут зависеть от чьих-либо действий," - Хайрам Райт, программист-инженер Google

А теперь давайте объясним о чем этот закон, а далее мы приложим полный текст оригинальный статьи в переводе на русском.

Суть закона в том, что при росте числа пользователей фичи, её реализация постепенно становится контрактом даже при наличии интерфейса. Под контрактом понимается ожидаемое и задокументированное поведение программы. В статье приводится пример с API - когда при большом числе юзеров неявный интерфейс в виде времени ответа сервера начинает сильно влиять на пользователей и автоматически становится частью контракта.

Полный текст статьи:

Разрабатывая низкоуровневые инфраструктурные миграции последние пару лет в одной из самых сложных программных систем на планете, я заметил различия между интерфейсом и имплементацией. Мы обычно думаем об интерфейсе, как об абстракции для взаимодействия с системой (например, руль или педали), и об имплементации как о непосредственной работе системы (колёса и двигатель). Это полезно по ряду причин, самое важное из них это то, что самые часто используемые системы быстро становятся слишком сложными в понимании для одного человека или группы людей, и абстракции необходимы для управления этой сложностью.

Определение правильного уровня абстракции - тема для отдельной дискуссии (Мифический человеко-месяц), но мы любим полагать, что когда абстракция объявлена, она становится конкретной. Другими словами, интерфейс теоретически должен обеспечивать четкое разделение между потребителями системы и её имплементаторами. На практике, эта теория рушится, когда использование системы возрастает, и её пользователи начинают полагаться на детали реализации, умышленно выставленные через интерфейс или которые они предугадывают в обычном использовании. Закон дырявых абстракций олицетворяет доверие потребителей к деталям внутренней реализации.

Доводя до логической крайности, это приводит к следующему наблюдению, которое простыми словами можно описать как «Закон неявных интерфейсов»: при частом использовании - системы - не существует частной реализации. То есть, если у интерфейса достаточно пользователей, намеренно или нет, они коллективно зависят от каждого аспекта реализации. Этот эффект приводит к ограничению изменения реализации, которая теперь зависит как от явно задокументированного интерефейса, так и от неявного интерфейса, выявленного в процессе использования. Мы часто называем это явление "bug-for-bug совместимостью".

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

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

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

Конец статьи

Ниже представлен комментарий Python-разработчика относительно данного закона:

"Одна из основных причин использования интерфейсов - это изоляция пользователей системы от необходимости знания её внутренней реализации. Все знания пользователя о системе должны ограничиваться API контрактом. Однако, закон Хайрама говорит нам о том, что при росте количества пользователей и/или усложнении систем - добиться этого невозможно.

Рассмотрим простой пример. У нас есть POST-запрос, который выполняется за 20 секунд, со временем появляются пользователи, пишущие свои системы с использованием нашего API и каким-либо образом полагающиеся на эту особенность (например, прописывают таймауты в своих системах) - то есть внутреннюю реализацию нашей системы. Вы скажете, что это можно описать в контракте и будете правы, в таком случае не будет "неявного знания" о внутренней реализации. Но есть одно большое но - мы можем поменять логику работы при вызове POST-запроса и контракт "сломается", самое страшное то, что у нас таких эндпоинтов может быть много, и их внутренняя логика может меняться очень часто, поддержка контрактов такой системы при её росте превратится в ад.

Второй пример - это когда пользователи начинают замечать и использовать в API вещи, неописанные в контракте (какие-либо фичи, типы ошибок и т.п.). Привязывая свои системы к этим неописанным особенностям, они неявно подписываются под то, что их система может в любой момент сломаться, и в контракте используемой системы не будет ни слова о предстоящих изменениях, потому то эти особенности были прокинуты наружу по ошибке. Часть проблем, связанных с человеческим фактором, успешно решается инструментами для автогенерации документации (например, Swagger), однако не все типы проблем удается решить таким образом.

Чем сложнее системы, чем больше пользователей, тем выше шанс того что рано или поздно начнут появляться системы, реализация которых будет знать о вещах, выходящих за рамки описанного вами контракта." - Короев Хетаг, Python-разработчик YLab

Подписывайтесь на меня в Twitter.

По материалам hyrumslaw.com