하이럼의 법칙

  구글 엔지니어 하이럼이 이야기 하는 법칙

https://www.hyrumslaw.com/

Hyrum's Law

소프트웨어 엔지니어링의 관찰

API 사용자가 충분 하면 명세서에 약속된 내용이 중요하지 않습니다.
시스템에서 관찰할 수 있는 모든 동작은 누군가에 의해 좌우됩니다.

지난 몇 년 동안 지구상에서 가장 복잡한 소프트웨어 시스템 중 하나에서 저수준 인프라 마이그레이션을 수행하면서 인터페이스와 구현 간의 차이점에 대해 몇 가지 관찰했습니다. 우리는 일반적으로 인터페이스를 시스템과 상호 작용하기 위한 추상화(예: 자동차의 스티어링 휠 및 페달)로 생각하고 구현은 시스템이 작동하는 방식(바퀴 및 엔진)으로 생각합니다. 이것은 여러 가지 이유로 유용합니다. 그 중 가장 중요한 이유는 가장 유용한 시스템이 한 개인이나 그룹이 완전히 이해하기에는 너무 복잡해지며 추상화는 그 복잡성을 관리하는 데 필수적입니다.

정확한 추상화 수준을 정의하는 것은 완전히 별개의 논의이지만(Mythical Man-Month 참조), 우리는 추상화가 정의되면 구체적이라고 생각하는 것을 좋아합니다. 다시 말해, 인터페이스는 이론적으로 시스템 소비자와 구현자를 명확하게 구분해야 합니다. 실제로, 이 이론은 시스템의 사용이 증가하고 사용자가 인터페이스를 통해 의도적으로 노출되거나 정기적인 사용을 통해 확인하는 구현 세부 사항에 의존하기 시작하면서 무너집니다. Spolsky의 "Leaky Abstractions의 법칙"은 내부 구현 세부 사항에 대한 소비자의 의존성을 구현합니다.

논리적으로 극단으로 치면 구어체로 "암시적 인터페이스의 법칙"이라고 하는 다음과 같은 관찰 결과가 나타납니다. 충분히 사용하면 비공개 구현과 같은 것은 없습니다. 즉, 인터페이스에 충분한 소비자가 있으면 의도적이든 아니든 구현의 모든 측면에 집합적으로 의존하게 됩니다. 이 효과는 구현에 대한 변경을 제한하는 역할을 합니다. 이제 명시적으로 문서화된 인터페이스와 사용에 의해 캡처된 암시적 인터페이스를 모두 준수해야 합니다. 우리는 종종 이 현상을 "버그 대 버그 호환성"이라고 합니다.

암시적 인터페이스의 생성은 일반적으로 점진적으로 이루어지며 인터페이스 소비자는 일반적으로 이러한 일이 진행되는 동안 인식하지 못합니다. 예를 들어, 인터페이스는 성능에 대해 보장하지 않을 수 있지만 소비자는 종종 구현에서 특정 수준의 성능을 기대하게 됩니다. 이러한 기대는 시스템에 대한 암시적 인터페이스의 일부가 되며 시스템의 변경 사항은 소비자를 위해 계속 기능하기 위해 이러한 성능 특성을 유지해야 합니다.

모든 소비자가 동일한 암시적 인터페이스에 의존하는 것은 아니지만 충분한 소비자가 주어지면 암시적 인터페이스는 결국 구현과 정확히 일치합니다. 이 시점에서 인터페이스는 증발했습니다. 구현이 인터페이스가 되었으며, 인터페이스에 대한 변경 사항은 소비자의 기대를 위반하게 됩니다. 운이 좋으면 광범위하고 포괄적이며 자동화된 테스트를 통해 이러한 새로운 기대치를 감지할 수 있지만 개선할 수는 없습니다.

암시적 인터페이스는 대규모 시스템의 유기적 성장으로 인해 발생하며 문제가 존재하지 않기를 바랄 수도 있지만 설계자와 엔지니어는 복잡한 시스템을 구축 및 유지 관리할 때 이를 고려하는 것이 현명합니다. 따라서 암시적 인터페이스가 시스템 설계와 발전을 어떻게 제한하는지 알고, 합리적으로 널리 사용되는 시스템의 경우 인터페이스가 생각보다 훨씬 더 깊숙이 도달한다는 것을 알고 있습니다.