[개발자의 서재] "실용주의 프로그래머" 8. 직교성

1. 직교성이란

직교란 직각으로 교차한다는 뜻으로 물리학적인 관점으로 보면 두 물체의 기존 운동과 가장 영향을 적게 주는 방향으로 충돌하는 것이다.

소프트웨어에서 말하는 직교성도 유사하다. 두 모듈, 컴퍼넌트, 시스템이 직교적이라는 말은 서로의 변경이 서로에게 영향을 주지 않는다는 뜻이다. 객체 지향 설계 원칙인 단일 책임 원칙(SRP), 개방 폐쇄 원칙(OCP)의 맥락과 동일하다고 생각한다.

2. 직교성의 장점

사실 직교성의 장점은 명확하고 모두가 이해하고 있다. 소프트웨어 특정 부분의 변경이 시스템 전체로 전달되는 것을 막아주기 때문에 생산성, 안정성을 높여준다.

• 문제는 개발 중에 소프트웨어가 직교성을 잃어가는 것이라고 생각한다. 직교성을 적용할 수 있는 범위와 방법을 익히자.

3. 팀 + 직교성

팀에도 직교성을 적용할 수 있다. 기능 수정이 필요할 때마다 얼마나 많은 인원들이 모여서 변경사항을 검토해야 하는가? 필요한 인원이 많을수록 해당 팀의 직교성은 떨어지는 것이다.

그렇다고 팀을 직교적으로 구성하는 정답은 따로 없다. 프로젝트의 성격, 팀의 가용 인원,  팀의 방향성에 따라 방법이 달라질 것이다.

• 지금 팀이 얼마나 직교적인지보다는 충분한 고민을 하고 합리적인 선택을 한 것인지 생각하기

4. 설계 + 직교성

시스템을 설계할 때 직교성을 고려하는 대표적인 방법은 레이어를 나눠가면서 추상화를 적용시키는 것이다. 서버를 예시로 들면 다음 순서와 유사할 것이다.
API - 비즈니스 로직 - 모듈 및 프레임워크 - 백킹 서비스(데이터베이스, 메시지 큐 등)

직교적으로 설계되었는지 확인하는 방법은 간단하다. 모듈 하나의 변경이 얼마나 많은 모듈에 영향을 끼치는지 검토하는 것이다. 시스템이 직교적으로 설계되었다면 API의 변경이 비즈니스 로직을 변경시키지 않고 모듈 혹은 프레임워크의 변경이 비즈니스 로직을 변경시키지 않을 것이다.

• 직교성을 추구하는 이유가 생산성과 안정성이라는 것을 잊지말자
• 현실세계로부터 받아오는 값처럼 제어할 수 없는 것에 의존하지 말자

5. 코드 + 직교성

코드를 작성하는 것은 언제라도 어플리케이션의 직교성을 해칠 수 있는 폭탄을 안고 가는 것이다. 코드를 작성하면서 직교성을 지킬 수 있는 방법들을 소개한다.

• 코드의 결합도를 줄여라. shy code, 디미터 법칙
• 전역 데이터 사용을 피하자.
• 유사한 함수를 만들지 말자. 스트레터지 패턴

6. 테스트 + 직교성

직교적으로 작성된 테스트는 실행, 유지보수가 매우 쉽다. 테스트 케이스를 실행하기 위해 라이브러리, 서비스가 최소한으로 필요하기 때문에 실햄 환경 설정도 쉽고, 실행 시간도 짧다. 그리고 일부 코드의 변경으로 테스트 케이스를 변경할 필요도 없기 때문에 유지보수도 쉽다.

버그를 수정하는 과정도 시스템의 직교성을 검토할 수 있는 아주 값진 시간이다. 버그를 수정하면서 얼마나 많은 모듈을 수정했는지 추적하면 시스템의 직교성이 어떻게 관리되고 있는지 파악할 수 있다.

• 단위테스트와 통합테스트의 분리가 생산성에 엄청난 영향을 끼친다는 것을 뼈저리게 느끼고 있다.
• 시스템의 의존성 때문에 통합테스트 설계가 어려운 경우가 있는데 의존성을 어떻게 제거하는 것이 좋은지 고민해보자.
• 기록의 중요성이 여기서도 보이네요.

7. 문서 + 직교성

워드프로세서의 스타일시트와 매크로를 이용하여 내용과 표현을 구분하여 문서를 작성하자.

• 아쉽게도 이런 경험이 없다! 이렇게 문서를 관리하는 사람에게 배우거나 자료를 찾아보고 싶다.