코드 품질올리기, 코드 설계 - 1 이름의 중요성과 모델링

"내 코드가 이상한가요" 센바다이아 著 를 읽고 정리한 글입니다.

 

가. 이름의 중요성과 모델링

 

1. 기술을 중심으로 이름을 짓거나, 일련번호를 매겨 이름을 지으면 코드에서 어떠한 의도도 읽어낼수 없습니다. 읽고 이해하는데 시간이 오래 걸릴 뿐더러 기능을 일일이 매핑시킨 알람표(스프레드시트)는 바쁜업무로 인해 유지보수가 거의 이루어 지지 않습니다.

 

권장하지 않는 예 1) 기술중심 명명

class MemoryStateManager {
    void changeIntValue01 (int changeValue) {
        updateState01();
...
}

 

종류	예
컴퓨터 기술 유래	memory, cache, thread, register 등
프로그래밍 기술 유래	function, method, class, module 등
자료형 이름 유래	int, str, flag 등

[기술 중심 명명 예]

 

권장하지 않는 예 2) 일련번호 명명

class Class001 {
   void method001();
   void method002();
...
}

 

권장하지 않는 예 3) 주석, 추가 자료로 대체하는 명명

int d = 0;             // d : 대미지 크기, p1 : 플레이어의 기본 공격력, d1 : 적의 방어력....
d = p1 + p2;
d = d - ((d1 + d2) / 2);
if (d < 0) {
   d=0;
]

 

권장하는 예

int damageAmount = 0;
damageAmount = playerArmPower + playerWeaponPower;
damageAmount = damageAmount - (( enemyBodyDefence + enemyArmorDefence) / 2);
 
if ( damageAmount < 0 ) {
   damageAmount = 0;
}

 

2. 목적과 의도가 있는 명명

Class에 적합한 크기의 책무와 비 상속관계의 Class간의 강한 결합을 방지하려면, Class와 Method에 적절한 이름을 붙여야 합니다. 이름을 대충 붙이다 보면 책무가 엉켜 강한 결합이 되고 클래스가 거대해져 유지관리가 힘들수 있습니다. 이를 방지하기 위해서는 '목적 중심 이름 설계'에 충실해야 합니다.

목적 중심 이름 설계는 이름에서 목적과 의도를 읽고 이해할 수 있게 설계하는 것입니다.

 

권장하지 않는 예

온라인 쇼핑몰은 상품을 중심으로 이루어 집니다. 출고, 예약, 주문, 발송 등 상품을 다루는 유스케이스가 많습니다. 따라서 이름을 단순하게 상품 클래스라고 붙이면, 여러 유스케이스와 관계를 맺게 됩니다. 그러면 상품 클래스가 여러 클래스와 관련 있는 로직을 갖게 되고 점점 거대하고 복잡해질 것입니다. 강한 결합 구조가 되어 버리는 것입니다.

 

따라서 관심사(〓 유스케이스, 목적, 역할)에 따라서 각각 클래스로 분할해야 합니다.

 

권장하는 예

단순하게 존재를 나타내는 이름은 의미가 여러곳에서 사용되기 쉬우며, 목적이 불분명해지기 쉽습니다.

 

 

존재 기반	목적 기반
주소	발송지, 배송지, 업무지 ...
금액	청구금액, 소비세액, 연체 보증료, 캠페인 할인 금액 ...
사용자	계정, 개인프로필, 직무 ...
사용자 이름	계정이름, 닉네임(별칭), 본명, 법인명 ...
상품	입고 상품, 예약 상품, 주문 상품, 발송 상품 ...

[목적 기반으로 생각한 이름의 예]