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

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

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

우선 수백 개의 클래스가 이미 정적 기록자 변수를 사용하고 있다면, 설령 내 의견에 동의하더라도, 문제가 발생하기 전까지는 그냥 두자. 필요가 발생하지 않은 곳에 비싼 프로그래머의 자원을 소비하는 것은 합리적이지 않다. 과거의 코드는 나름의 역사와 이유가 있다. 존중하고 이해하자.

어떤 기법에 대해 비현실적이라 말하는 것은 정말 비현실적이거나 충분히 현실적이지만 특정 개인이나 조직이 비현실적으로 느끼는 경우일 수 있다. 후자의 예로 나는 TDD(test-driven development)가 비현실적이라는 주장을 많이 접했는데 사실은 시도해 보지도 않고 지레 겁먹었거나 TDD를 충분히 이해하지 못한 것이었다.

백 개의 클래스가 있고 모두 기록자를 직접 사용한다는 가장 끔찍한 악몽같은 경우를 가정하자. 기록자 DI 설정을 위해 클래스당 두 줄의 코드가 필요하다면 200줄이 추가된다. 비현실적으로 많은가? 그럼 이건 어떤가? 백 개의 클래스가 모두 SRP(single responsibility principle)를 충실히 따랐다고 하더라도 테스트 케이스가 천 개 정도는 될 것이다. 그러면 테스트 코드는 모두 몇 줄일까? 백 개의 클래스를 위한 천 개의 테스트 케이스를 작성하는 것도 비현실적인가? 누군가에게는 일상적이고 또 다른 이에게는 비현실적이다.

정말 문제는 백 개의 클래스 모두가 기록자를 직접 사용하는 설계다.

동일한 기능(feature)을 전제로 코드가 없는 것은 그 어떤 코드보다 더 좋다. 하지만 적은 코드가 더 많은 코드보다 항상 더 좋은 것은 아니다. 게다가 사용성(usability)과 적응성(adaptability), 테스트 용이성(testability)은 기능이다. 코드 몇 줄로 유용한 기능을 확보할 수 있다면 결코 비현실적이지 않다. 긴 코드보다 나쁜 설계를 두려워하라.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중