원문: </> htmx ~ Locality of Behaviour (LoB)

Carson Gross

2020년 5월 29일

“쉬운 유지보수를 위한 주요 특징은 지역성(locality)입니다. 지역성이란 프로그래머가 소스 코드의 작은 부분만 보고도 해당 소스를 이해할 수 있게 하는 특성입니다.” – Richard Gabriel

LoB 원칙

행동의 지역성(Locality of Behaviour)은 다음을 의미하는 원칙입니다:

코드 단위의 행동은 해당 코드 단위만 보더라도 가능한 한 명확해야 한다.

논의

LoB 원칙은 Richard Gabriel의 인용문을 간단하고 규범적으로 공식화한 것입니다. 가능한 한, 그리고 다른 고려사항들과 균형을 이루면서, 개발자들은 “코드 요소의 행동”이 코드확인시 명확하도록 노력해야 합니다.

(원문: developers should strive to make the behaviour of a code element obvious on inspection)

HTML에서 *AJAX 요청을 구현하는 두 가지 다른 방식을 고려해 봅시다. 첫 번째는 htmx입니다:

AJAX: Asynchronous JavaScript and XML (비동기 스크립트로 페이지 일부만을 전체 페이지 새로고침없이 바꿀 수 있는 기술, AJAX -> jQuery -> React, htmx로 변화해옴)

<button hx-get="/clicked">Click Me</button>

두 번째는 jQuery입니다:

  $("#d1").on("click", function(){
    $.ajax({
         /* AJAX options... */
    });
  });

<button id="d1">Click Me</button>

전자의 경우, 버튼 요소의 행동은 검사 시 명확하여 LoB 원칙을 만족합니다.

후자의 경우, 버튼 요소의 행동이 여러 파일에 분산되어 있습니다. 코드베이스에 대한 전체적인 지식 없이는 버튼이 정확히 무엇을 하는지 알기 어렵습니다. 이러한 “원거리 유령 현상(spooky action at a distance)”은 유지보수 문제의 원인이 되며 개발자가 코드베이스를 이해하는 데 방해가 됩니다.

htmx 예시는 좋은 행동의 지역성을 보여주는 반면, jQuery 예시는 행동의 지역성이 좋지 않습니다.

행동 표면화 vs. 구현 인라인화

행동의 지역성에 대한 일반적인 반론은 코드 단위 내에 구현 세부 사항을 인라인화하여 코드 단위를 덜 추상적이고 더 취약하게 만든다는 것입니다. 그러나 어떤 행동의 구현을 인라인화하는 것과 어떤 행동의 호출(또는 선언)을 인라인화하는 것 사이의 구분을 짓는 것이 중요합니다.

대부분의 프로그래밍 언어에서 함수를 생각해 보세요. 함수의 선언과 호출 지점에서의 사용 사이에는 구분이 있습니다. 좋은 함수는 구현 세부 사항을 추상화하지만, 원거리 유령 현상 없이 명확한 방식으로 호출됩니다.

다른 조건이 동일하다면, “요소의 행동 명확성”을 높이는 것은 좋은 일입니다. 하지만 LoB를 가능한 한 쉽고 개념적으로 깔끔하게 만드는 것은 최종 개발자, 특히 프레임워크 개발자의 몫입니다.

다른 개발 원칙과의 충돌

LoB는 종종 다른 소프트웨어 개발 원칙들과 충돌할 수 있습니다. 두 가지 중요한 원칙은 다음과 같습니다:

소프트웨어 개발자들은 일반적으로 코드나 데이터의 중복을 피하려고 노력합니다. 이를 “DRY 유지하기”, 즉 “반복하지 마라”라고 부릅니다. 다른 소프트웨어 설계 원칙과 마찬가지로, 이 원칙 자체는 좋은 것입니다. 예를 들어, htmx는 DOM의 부모 요소에 많은 속성을 배치하여 자식 요소에 이러한 속성을 반복하는 것을 피할 수 있게 합니다. 이는 DRY를 위해 LoB를 위반하는 것이며, 이러한 절충은 개발자가 신중하게 이루어져야 합니다.

행동이 영향을 미치는 코드 단위에서 멀어질수록 LoB 위반의 심각성은 더 커진다는 점에 유의하십시오. 코드 단위에서 몇 줄 이내에 있다면 페이지 하나만큼 떨어져 있는 것보다 덜 심각하고, 완전히 별도의 파일에 있는 것보다 덜 심각합니다.

확고한 규칙은 없으며, 소프트웨어 개발자로서 주관적인 절충이 이루어져야 합니다.

  • SoC - 관심사 분리 (Separation Of Concerns)

관심사 분리는 컴퓨터 프로그램을 별개의 섹션으로 분리하여 각 섹션이 별개의 관심사를 다루도록 하는 설계 원칙입니다. 이에 대한 전형적인 예시는 HTML, CSS, JavaScript를 분리하는 것입니다. 다시 말하지만, 이 원칙 자체만으로는 좋은 것일 수 있습니다. 최근에는 인라인 스타일이 더 보편화되었지만, 이와 관련하여 SoC를 지지하는 강력한 주장들도 여전히 존재합니다.

그러나 SoC는 LoB와 충돌한다는 점에 유의하십시오. CSS 파일을 수정함으로써 요소의 모양과 어느 정도 행동이 극적으로 변할 수 있으며, 이러한 극적인 변화가 어디서 왔는지 명확하지 않습니다. 도구가 어느 정도 도움이 될 수 있지만, 여전히 “원거리 유령 현상”이 발생하고 있습니다.

다시 말하지만, 이것은 SoC를 전면적으로 비난하는 것이 아니라, 코드를 어떻게 구성할지 고려할 때 주관적인 절충이 이루어져야 한다는 것을 말하는 것입니다. 최근 인라인 스타일이 더 보편화된 사실은 SoC가 개발자들 사이에서 일부 지지를 잃고 있다는 징후입니다.

결론

LoB는 코드베이스를 더 인간적이고 유지보수하기 쉽게 만들 수 있는 주관적인 소프트웨어 설계 원칙입니다. 다른 설계 원칙들과 절충되어야 하며, 코드 단위가 작성되는 시스템의 한계를 고려해야 하지만, 실용적인 한 이 원칙을 준수하면 소프트웨어의 유지보수성, 품질 및 지속 가능성이 향상될 것입니다.

번역 끝.

투자 관점

코딩을 할 때 고민되는 부분입니다. SoC를 챙길지 DRY를 챙길지, LoB를 챙길지. 이 세가지 밸런스를 잘 잡고 있는 기업에 투자합시다. 아래는 기술적 내용입니다, 투자처는 이런 기술의 관계를 알고 있어야 합니다.

개발원칙들간 충돌이 있다고 하지만, 프로젝트 규모에 따라 더 가치를 둘 개발원칙이 있습니다.

예를 들면, OS 관련된 모든 코드를 하나의 파일에 넣어둘 순 없겠죠. 그러나 HTMX (리엑트와 비슷한 AJAX library)는 단 하나의 파일에 코드를 몰아넣었습니다.

Django (MVT), Spring (MVC) 같은 기능이 많은 프로젝트는 SoC이 잘되어 있습니다. 그러나 flask, FastAPI같은 micro framework는 단 하나의 파일에도 작동합니다.

DRY를 위해 함수를 나누다보면 위의 LoB가 약해집니다. 함수를 많이 나눌수록 어떻게 나눴는지, 어떤 함수들이 있는지 내부 싱크가 필요할 거 같습니다. (개발자 교육을 통하든, 개발문서를 통하든)