태그 보관물: design

적은 코드가 항상 더 좋지는 않다

예상했던 일이지만 소셜 미디어에서 정적 기록자(static logger) 변수를 그만 사용하자는 의견에 반발이 거세다. 모든 의견에 하나하나 대응해 줄 여유가 없음이 안타깝다. 그 중 다음 한가지 의견에 대해 답해 본다.

"우리 응용프로그램은 수백 개의 클래스로 구성된다. 정적 기록자를 사용하지 않기 위해 모든 클래스에 DI(dependency injection) 설정을 하는 것은 비현실적이다."

계속 읽기

Advertisements

정적 기록자는 이제 그만

수십년간 적응력있는 소프트웨어를 만들기 위한 노력이 지속되고 있다. 우리는 많은 원칙들과 패턴들을 도출했고 또 일부는 퇴출시켰다. 도메인은 가장 높은 적응력을 가져야 하는 소프트웨어 구성요소로 거론되고 있다. 간혹 도메인을 호스팅하는 웹 응용프로그램 코드가 도메인 코드보다 물리적으로 더 큰 비중을 차지하더라도 도메인의 중요성은 여전히 가장, 그리고 월등히, 높다.

아키텍처는 점점 다양해지고 그 수명은 점점 짧아진다. 변화하는 비즈니스 상황에 따라 동일한 도메인 논리는 다양한 호스팅 환경으로 확산되어 구동된다. 서비스 초기에는 단순한 웹 응용프로그램 호스트면 충분하다. 그러다 아마 곧 반응성에 대한 사용자들의 불만이 생겨날 것이고, 도메인 구성요소의 일부를 작업자 프로세스로 이동시켜 비동기적으로 실행해 반응성을 높여야 한다. 서비스가 성장하면 이제 도메인은 외부 서비스들과 교류하게 되고 개방형 API와 웹 훅을 통해 도메인 논리가 트리거된다. 아, 그렇지! 지금은 클라우드 시대다. FaaS(Function as a Service)를 빠뜨릴 수 없다. 다시 한 번 언급하면 도메인 논리는 동일하다. 외부 변화에 따라 다른 아키텍처로 이동되거나 확산될 뿐이다.

물론 상당수의 서비스는 성장하지 못하고 생을 다한다. 하지만 성장의 기회가 왔을 때 정적 기록자(static logger) 변수 따위가 도메인의 발목을 잡는다면 모습이 우스을 것이다. 그것도 화려하고 무거운 무언가를 도입하는 것이 아니라 고작 담백한 한 두 줄 코드 추가가 부담되어 그랬다면 말이다.

계속 읽기

싱글턴은 정적이지 않다

얼마전 페이스북에서 많은 프로그래머들이 당연시하게 기록자(logger)를 정적(static)으로 사용하는 것을 비판했는데, 비슷한 주장을 하는 다른 분의 글에서 기록자는 인스턴스 범위(scope)에 있지 않고 클래스 범위에 있다는 반론을 발견했다. 나는 반론 제기자에게 그것은 논점을 벗어나니 의존성 역전 원칙(dependency inversion principle)를 공부하라고 조언했다. 아쉽지만 반응에 의하면 아마 내 조언은 무시된 것 같았다.

계속 읽기

캡슐화와 정보 숨김

본능적으로 모호함을 피하려는 프로그래머들 사이에서도 캡슐화(encapsulation)라는 용어의 의미는 명확하지 않다. 가장 많이 사용되는 몇 가지 정의는 다음과 같다.

  • 정보 숨김(information hiding)과 동의어
  • 구현 숨김(implementation hiding)과 동의어
  • 데이터 숨김(data hiding)과 동의어
  • 응집을 통한 새로운 정체성 형성

정보 숨김의 정의는 논란의 여지가 없다. 70년대 초 David Parnas는 어려운 설계 결정과 변경될 가능성이 높은 설계 결정을 파악하는 것으로 모듈화를 시작하라 제안했고 이런 결정들이 다른 모듈로부터 숨겨지는 것을 정보 숨김이라 표현했다.

계속 읽기

좋은 디자인과 테스트하기 쉬운 디자인

TDD와 관련된 오해 중 가장 심각한 것은 단위 테스팅과 TDD를 구별하지 못하는 것입니다. 그리고 또 다른 오해가 ‘좋은 디자인’과 ‘테스트하기 쉬운 디자인’의 관계에서도 발견됩니다. ‘좋은 디자인은 테스트하기 쉽다’는 명제에 대한 반론은 찾아보기 어렵습니다. 저도 반례를 경험한 일이 없습니다. 따라서 TDD 과정에서 어떤 코드를 테스트하기 어렵다면 디자인 문제를 의심해 볼 수 있고 이것은 TDD가 주는 나쁜 디자인에 대한 피드백으로 볼 수 있습니다. 게다가 이 피드백은 세부 구현 전에 제공되기 때문에 더 유익합니다. 하지만 안타깝게도 그 역인 ‘테스트하기 쉬운 디자인은 좋다’는 명제는 성립하지 않습니다. ‘좋은 디자인’과 ‘테스트하기 쉬운 디자인’은 동치가 아닙니다. 단순한 사례는 아주 쉽게 만들 수 있습니다.

계속 읽기

매개변수 3개는 너무 많은 것일까?

저는 책을 멀리하는 사람이기 때문에 Robert Cecil Martin이 Clean Code에서 이런 말을 했다는 것을 알지 못했습니다.

The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification

전문이 아닌 짧은 구절만 읽어서는 정확한 의미를 파악할 수 없습니다. 그런데 얼마전 메서드 매개변수가 3개이면 코드를 이해하기 어렵기 때문에 나쁜 디자인이라는 주장을 직접 접하기도 했습니다. 정말 3개 이상의 매개변수를 가진 메서드는 나쁜 디자인일까요?

three

계속 읽기