객체지향 생활체조-규칙5

해당 글은 developerFarm 개발자 블로그의 농장객체지향 생활체조를 참고하여 정리한 글 입니다.

규칙5. 축약 금지

누구나 클래스, 메서드, 또는 변수의 이름을 줄이려는 유혹에 곧잘 빠지곤 한다. 그런 유혹을 뿌리쳐라. 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다.

왜 축약을 하고 싶은지 생각해보라. 계속 반복해서 똑같은 단어를 치기 때문이 아닐까? 만일 그 경우라면 아마도 메서드가 너무 대대적으로 사용되어 중복을 없앨 기회를 놓치고 있는 것이다. 메서드 이름이 길어지고 있기 때문일까? 이는 책임 소재의 오류나 클래스의 부재라는 신호탄일지도 모른다.

클래스와 메서드 이름을 한두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자. 클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다. 짧게 ship()이라고 하면 클라이언트에서는 order.ship()라고 호출하며, 간결한 호출의 표현이 된다.

신입시절에 다니던 회사에서는 클래스, 메서드, 변수 명을 대부분 축약하여 사용하였다. 지금 돌이켜보면 그 당시 코드들은 객체지향적이기 보다는 절차지향적으로 코드를 작성하였기 때문에 클래스, 메서드, 변수 명등이 지나치게 길어져서 축약을 한게 아닌가 싶다. 객체지향적으로 코드를 작성하다보면, 단어 자체가 길어질 경우가 흔치 않다. 또한 요즘은 IDE의 자동완성 기능이 워낙 좋기 때문에 축약을 할 필요성도 없어 보인다.

축약을 함으로서 단점이라고 하면 불필요한 주석과 해당 코드 작성자 이외의 개발자들에게 혼란과 축약된 단어의 의미를 유추하는 등의 불필요한 시간을 허비 해야 한다는 것이다. 주석이 안좋다는 의미가 아니다. 필요한 내용만을 주석으로 작성하고, 클래스, 메서드, 변수 명만으로도 역할등이 명확하게 표현하여 가독성을 높히는 것은 개발자들의 공통적인 숙제이다.