[실용주의 프로그래머] 직교성

[실용주의 프로그래머] 직교성

-

설계, 빌드, 테스트 그리고 확장하기에 쉬운 시스템을 만드는 데에 있어 직교성(Orthogonality)은 매우 중요한 개념이다.

직교성이란

-

컴퓨팅에서 이 용어는 일종의 독립성(independence)이나, 결합도 줄이기(decoupling)을 의미한다.

하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.

비직교적인 시스템

직교성의 장점

-

시스템의 컴포넌트들이 고도로 상호의존적인 경우, 특정 국지적 부분만 수정하는 방법이란 없다.

“” 관련 없는 것들 간에 서로 영향이 없도록 하라. “”

-

컴포넌트들이 각기 격리(isolate)되어 있으면 어느 하나를 바꿀 때 나머지 것들을 걱정하지 않아도 된다.

해당 컴포넌트의 외부 인터페이스를 바꾸지 않는 한, 전체 시스템으로 퍼져나가는 문제를 일으키지는 않으리라고 안심할 수 있다.

-

직교적인 시스템을 작성하면 두 가지의 큰 장점이 있다.

생산성 향상과 리스크 감소

생산성 향상

-

변화가 국소화(localize)되서 개발 시간과 테스트 시간이 줄어든다.

상대적으로 작고, 자족적인 컴포넌트를 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 더 쉽다.

간단한 컴포넌트들은 설계하고, 코딩하고, 단위 테스트하고, 그리고는 잊어버릴 수 있다.

새로운 코드를 추가할 때마다 기존의 코드를 계속 바꾸어야 할 필요가 없다.

-

직교적인 접근법은 또한 재사용을 촉진한다.

시스템이 더 느슨하게 결합(coupling) 되어 있을수록 재설정(reconfigure)하고 리엔지니어링하기 쉽다.

-

직교적인 컴포넌트들을 결합하는 경우 꽤 미묘한 생산성 향상이 있다.

리스크 감소

-

감염된 코드는 격리된다.

어떤 모듈이 병에 걸렸다 해도 시스템의 나머지 부분으로 증상이 전파될 확률이 낮다.

게다가 그 부분만 도려내고 새롭게 건강한 놈으로 이식해 넣기도 쉽다.

-

어떤 부분을 골라서 약간 바꾸고 수리해도 거기서 생기는 문제점들은 그 부분에만 한정될 것이다.

-

직교적인 시스템은 해당 컴포넌트들에 대해 테스트를 설계하고 실행하기 훨씬 쉽기 때문에, 아무래도 더 많은 테스트를 하게 된다.

-

써드파티 컴포넌트로 연결되는 인터페이스들이 전체 개발의 작은 부분에 한정되기 때문에 특정 벤더나 제품, 플랫폼에 덜 종속될 것이다.

프로젝트 팀

-

팀 내 업무가 겹치는 영역이 많다면 구성원들은 책임 영역에 대해 혼동하게 된다.

뭘 하나 바꾸려고 해도 그들 중 누구라도 영향을 받을 수 있기 때문에 전체 팀원이 모여야 한다.

-

앱에서 인프라(infrastructure)를 분리하는 방식을 선호된다.

주된 인프라 컴포넌트(DB, 커뮤니케이션 인터페이스, 미들웨어 레이어 등등)마다 서브팀을 할당한다.

앱 기능의 분할 역시 유사하게 나뉜다.

그리고 나서 현재의(혹은 계획된) 가용 인원을 확인하고 조직을 적절하게 개편(grouping) 한다.

-

프로젝트 팀 구조가 얼마나 직교성을 갖는지 간단히 측정해 볼 수 있는 방법이 있다.

요청된 개별 변화에 대한 토론에 참여할 필요가 있는 사람이 몇 명인가를 보라.

숫자가 클수록 그룹의 직교성은 낮다.

직교적인 팀이 더 효율적임이 명백하다.

설계

-

시스템은 협력하는 모듈들의 집합으로 구성되어야 하고, 각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다.

때로는 이런 컴포넌트들이 레이어로 조직되기도 하는데, 각 레이어는 하나의 추상화 층을 이루게 된다.

이 레이어식 접근은 직교적 시스템을 설계하는 강력한 방법이다.

각 레이어는 자기 밑에 있는 레이어들이 제공하는 추상화만을 사용하기 때문에 코드에 영향을 끼치지 않으면서 아래에 있는 다른 구현들을 바꾸는 높은 우연성을 얻을 수 있다.

레이어를 두는 것은 또한 모듈 간에 종속성이 빨리 늘어나는 위험을 감소시킨다.

-

직교적인 설계를 테스트하는 손쉬운 방법이 있다.

컴포넌트들을 나누었을 때 다음과 같이 스스로 물어보라.

“특정 기능에 대한 요구사항을 극적으로 변경했을 경우, 몇 개의 모듈이 영향을 받는가?”

직교적인 시스템에서는 답이 “하나”여야 한다.

툴킷과 라이브러리

-

써드파티 툴킷이나 라이브러리를 도입할 때, 시스템의 직교성을 보존할 수 있는지 주의 깊게 살펴보라.

기술을 현명하게 선택하라.

코딩

-

직교성을 유지하기 위해 사용할 수 있는 몇 가지 기법이 있다.

    코드의 결합도를 줄여라

        부끄럼타는 코드(shy code)를 작성하라.

        즉 불필요한 어떤 것도 다른 모듈에 보여주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라.

        객체의 상태를 바꿀 필요가 있다면, 객체 스스로가 여러분을 위해 그러한 일을 수행하게 만들라.

        이렇게 한다면 코드는 다른 코드 구현으로부터 분리된 채로 남아있을 것이며, 계속하여 직교성을 유지할 기회가 많아진다.

    전역(global) 데이터를 피하라.

        코드가 전역 데이터를 참조할 떄마다, 코드는 해당 데이터를 공유하는 다른 컴포넌트와 묶이게 된다.

        읽기 전용 목적으로 전역 데이터를 사용한다 하더라도 문제가 발생할 수 있다.

        예를 들어 코드를 갑자기 멀티스레드로 바꿔야 하는 경우가 그것이다.

    유사한 함수를 피하라.

-

자신이 작성하는 코드를 항상 비판적으로 검토해 보는 습관을 기르기 바란다.

기회가 있을 때마다 코드의 구조와 직교성을 향상시키기 위해 노력하라.

이러한 프로세스를 리펙토링(refactoring)이라 부른다.

테스트

-

직교적으로 설계, 구현한 시스템은 테스트하기 더 쉽다.

모듈(혹은 단위, unit) 수준의 테스트가 통합 테스트보다 테스트케이스를 만들고 수행하기 훨씬 쉽다는 점에서 좋은 소식이다.

우리는 모든 모듈이 자신만의 단위 테스트를 위한 테스트케이스를 갖고, 테스트가 정규 빌드 과정의 일부로 수행되어야 한다고 생각한다.

-

버그 수정은 시스템의 직교성을 총체적으로 점검해 볼 수 있는 값진 시간이다.

문제가 발생했다면 버그 수정이 얼마나 지역화 되어 있는지 평가해 보라.

모듈 하나만 변경하면 되는가?

변화가 시스템 전반에 걸쳐 분산되어 있지는 않은가?

수정을 했다면 모든 것이 제대로 고쳐졌는가?

수정이 끝난 후 생각지도 못했던 곳에서 새로운 문제가 발생하지는 않는가?

문서화

-

직교성은 놀랍게도 문서에도 적용할 수 있다.

내용과 표현이 두 축이 된다.

정말 직교적인 문서라면 내용 변화 없이 표현을 극적으로 바꿀 수 있을 것이다.

직교적으로 살아가기.

decoupling, global data, iNdependence, infrastructure, orthogonality, reconfigure, refactoring, shy code, unit 테스트, [실용주의 프로그래머] 직교성, 개발 시간, 결합도 줄이기, 느슨한 결헙, 독립성, 디커플링, 리스크 감소, 리엔지니어링, 리펙토링, 모듈 단위 테스트, 버그 수정 직교성, 변화의 국소화, 부끄럼 타는 코드, 생산성 향상, 실용주의 프로그래머, 영향, 유사한 함수를 피하라, 인프라 분리, 재사용 촉진, 재설정, 전역 데이터를 피하라, 직교성, 직교적인 팀, 추상화 층, 컴포넌트 레이어, 코드 결합도, 테스트, 테스트 시간, 툴킷과 라이브러리, 프로젝트 팀