독립성이나, 결합도 줄이기를 의미함.
컴포넌트들이 각기 격리 되어 있으면 어느 하나를 바꿀 떄 나머지 것들을 걱정하지 않아도 된다.
직교적인 시스템을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향상과 리스크 감소다.
- 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다.
- 재사용을 촉진한다
- 생산성 향상
- 감염된 코드가 격리되어 있다.
- 시스템이 잘 깨지지 않는다.
- 테스트를 설계하고 실행하기 쉽다.
- 업체나, 제품, 플랫폼에 덜 종속된다.
시스템은 서로 협력하는 모듈의 집합으로 구성되어야 하고, 각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다.
계층 구조는 직교적 시스템을 설계하는 강력한 방법이다. 각 계층은 자기 바로 밑에 있는 계층이 제공하는 추상화만을 사용하기 때문에, 다른 코드에 영향을 끼치지 않으면서 기반 구현들을 변경할 수 있게 되어 유연성이 높아짐
설계가 직교적인지 확인하는 손쉬운 방법은 컴포넌트들을 나누었을 때 스스로에게 물어보아라. '특정 기능에 대한 요구 사항을 대폭 변경해야 하는 경우 몇 개의 모듈이 영향을 받는가?' 정답은 하나여야 함.
외부에서 만든 툴킷이나 라이브러리를 도입할 때 시스템의 직교성을 해치지 않는지 주의 깊게 살펴보아라.
코드를 작성할 때마다 애플리케이션의 직교성을 떨어트릴 위험을 감수하는 셈이다.
직교성을 유지하기 위해 사용할 수 있는 몇 가지 기법이 있다.
- 코드의 결합도를 줄여라
- 전역 데이터를 피하라
- 유사한 함수를 피하라
자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라. 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라.
직교적으로 설계하고 구현한 시스템은 테스트하기 더 쉽다. 시스템 컴포넌트 간의 상호 작용이 형식을 잘 갖추고 있고 제한적이기 때문에 시스템 테스트 중 많은 부분을 개별 모듈 수준에서 수행할 수 있다.
단위 테스트가 나머지 시스템의 많은 부분들을 불러와야해서 힘들다면 결합도를 충분히 줄이지 못했다는 뜻이다.
버그 수정을 통해 어떤 한 부분만 수정하면 되었는가? 또 다른 버그가 생기지는 않았는가? 이 질문들에 제대로 답하려면 자동화도 적용을 해야한다.
놀랍게도 직교성은 문서에도 적용할 수 있다.
정말 직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수 있다.
직교성은 DRY 원칙과도 밀접한 관계가 있다. 당연한 말이겠지만 DRY원칙으로 무장하고 직교성 원칙을 충실히 적용한다면 개발하고 있는 시스템이 더 유연하고 이해하기 쉬워질 것이다. 디버깅, 테스트, 유지보수도 쉬워질 것이다.