관습에 의한 코딩과 레거시코드. 그리고 나.

왜 이렇게 코드를 작성하는지에 대한 이해가 없이 어떠한 새로운 것을 배울 때에

몸이 익숙해진 코딩을 유지하면서 하는 것. 관습에 의한 코딩.

지난 주에 스터디 그룹에 개발방법에 대한 이슈가 올라왔는데

그때에 DTO 개념이 보이질 않았던 터라 DTO의 사용여부라는 답없는 질문을 스터디 그룹에 질문했다.

글 타래들을 보면서 DTO를 보다 강력하면서도 편하게 작성할 수 있는 라이브러리도 보게 되었고

동시에 VO와 DTO의 차이점도 보게 되었다.

(사실 예전에 TDD책을 잠시 보았다가 DTO와 VO를 동일하게 보는 문구를 보았던 터라 동일하게 봤다 -_-)

그리고 구글링을 통해 아래와 같은 오래된 DTO에 대한 논의도 접했다.

http://blog.naver.com/PostView.nhn?blogId=gunlee00&logNo=10100486790&redirect=Dlog&widgetTypeCall=true

원래는 웹개발에서 service layer의 interface 작성이 반드시 필요한가에 대한 논의에서 출발한

어플리케이션 개발을 어떻게 하는게 좋을까에 대한 논의였는데,

난 습관화 되어있는 interface작성에 대해 회의가 들었고.

그 논의의 개발방법에서 DTO에 대한 얘기가 없었는데,

난 각 layer간의 통신에 대해서 DTO작성함에 있어서도 회의가 들던 참이었다.

하지만 오늘 아침에도 난 습관적으로 service layer에 interface를 추가하였고 그것을 상속받아 구현 클래스를 작성했다.

또한 Model layer에서 다룰 DB에 mapping되는 property같은 녀석들을 가지고 있는 DTO를 만들었다.

(그렇다. 단순히 get/set을 위한 property를 만들었다. C#에서의 그 property와 같은 의미다.)

왜 이렇게 작성했는지 생각해보니 분명히 목적에 맞지도 않은 코딩이지만 기존 코드와의 균형이 깨지는게 싫었다.

기존 코드의 모든 value들은 DTO에 담겨져 있다.

이러한 코딩에 만족을 느끼는 경우는 별로 흔치 않다.

만족을 느끼는 순간은 그저

DB쿼리를 기존의 쿼리로 날리는 대신에 특별히 view layer에 보여져야할 data를 가공할 수 있는 정도.

interface 작성의 만족 역시도 많지는 않지만 각 layer간의 결합도가 낮아져 조금은 유연한 코딩이 가능해지는 정도.

하지만 웹개발의 특성상 위의 문제로 시달릴 일이 얼마나 될까란 의문이 우선이다.

오히려 이러한 코딩으로 생산성에 문제가 생기지 않는가?

DTO는 변경엔 닫혀야하고 확장엔 열려야하는 OOP를 해치지 않는가?

그럼에도 레거시 코드를 핑계로 다시금 관습에 의한 코딩을 하고 있다.

정말 무서운 것은 레거시 코드에 대한 핑계이며 알면서도 행하지 않는다는 것이다.

기계랑 다를게 뭐가 있나.

그저 하나의 모터로 지금 당장에 돌아가고는 있지만

더 좋은 모터가 생기면 난 그저 폐기처분을 기다릴 구닥다리 모터일 뿐이다.

작성하다보니 나를 너무 자괴감에 젖게 했군.

이렇게 누구나 볼 수 있는 공간에다가 스스로 욕보였으니

이젠 내가 규정한 몇몇 관습적인 코드들을 리팩토링해야겠다.