프로젝트 회고 - (with 코드리뷰)

 

 

1, 2차 프로젝트를 바쁘게 달리고 2차 프로젝트에 있었던 오류도 잡고, 3차 프로젝트를 준비하면서 재정비할 수 있는 텀이 짧게 생겼다.

 

이 기간을 어떻게 하면 잘 사용할 수 있을까 생각을 하다 우선 사수님께서 프로젝트 했던 것들을 잊기 전에 모두 정리해두라고 하셔서 정리를 하고, 그래도 남는 시간에 사수님과 짧은 코드리뷰를 진행했다. 시간이 많지 않아 구조를 뜯어고치거나 많은 것을 변경할 수는 없었기에 클린코드 책을 참고하며 우리의 코드의 부족한 점을 돌아보고 좋은 코드를 짜기 위해서는 어떠한 요소를 고려해야 하는지 정리해보는 시간을 가졌다.

반영이 모두 끝나서 코드리뷰를 하고 리팩토링한 코드를 최종 프로젝트에 반영하진 못하겠지만, 내 결과물들을 다시 돌아보고 앞으로의 프로젝트에서 더 나은 코드를 짤 수 있도록 점검해보았다.

 

 

 

 

코드리뷰

1. 기능별 모듈화

 프로젝트를 하다보니 기획이 변경되는 등의 이유로 기능이 덧붙여지는 경우가 종종 있었다. 처음 함수를 A라는 기능으로 정의하고, B, C와 같이 기능이 추가될 때 모듈화를 하지 않고 같은 함수에 덧붙여져 있었다. 

 예를 들어 목록화면에서 수정이 이루어지는 경우 데이터 변경, 데이터 삭제, 리스트 순서 변경 등 기능이 하나씩 추가되었는데 이를 따로 모듈화하지 않고 update라는 함수 안에 추가해서 점점 길어졌다. 이 와중에 또 아래처럼 주석으로 이쁘게 남겼다..

public void updateList(List<Object> list) {
    // 1. Validation Check
    validationCheck();
    
    // 2. update
    update 사전처리
    ...
    updateList();
    
    // 3. delete
    delete 사전 처리
    ...
    deleteList();
    
    // 4. change order
    update 사전 처리
    ...
    updateSeq();
    
}

 

 

업데이트를 하는 기능은 함수로 뺐지만, 사전처리는 그대로 updateList 안에 있는.. 이건 뭐 모듈화를 한 것도 안한 것도 아닌 코드였다. 결국 사전처리부분을 전부 각 함수로 넘기고 updateList 안에는 거의 함수를 호출하는 역할만 하도록 수정하였다.

public void updateList(List<Object> list) {
    // 1. Validation Check
    validationCheck();
    
    // 2. update
    updateList();
    
    // 3. delete
    deleteList();
    
    // 4. change order
    updateSeq();
    
}

 

 

2. 상수화

숫자는 상수화가 필요하다. 숫자 뿐만이 아니라 여러 곳에서 공통으로 사용되는 단어들은 상수화를 해두어야 오류를 방지할 수 있다.

예를 들어 고객 코드가 관리자(01), 일반 고객(02), 매니저(03)로 나뉠 때 'ADMIN', 'CUSTOMER', 'MANAGER' 등으로 고정시키는 것이다.

이렇게 해두고 사용할 때 직접 비교하지 않고 선언된 상수를 가져와서 비교해야 혹시나 데이터가 변경되었을 때 오류가 나지 않고, 유지보수에도 용이하다.

public class CustCode {
	
    public static final String CUSTOMER = "01";
    public static final String ADMIN = "02";
    public static final String MANAGER = "03";  
    
}

// 사용 예시
if(고객코드.equals(CustCode.CUSTOMER)) {

} else if(고객코드.equals(CustCode.ADMIN)) {
	
} else {

}

 

 

3. 변수명과 함수명은 의도가 명확하게, 함수명이 길어지는 것을 두려워하지 말기

 사실 좋은 코드를 위해 실천할 수 있는 가장 간단한 단계인 것 같다. 하지만 실제로 코드를 짜고 점점 길어지다보면 기존의 변수명이나 함수와 의미가 겹치게 되는 일이 꽤 빈번하다. 이것도 결국은 핑계지만 의미가 계속 겹치다보니 변수명을 만들고 만들다 파라미터로 넘기는 변수를 param이나 temp로 네이밍 한 것이 몇 개 있었다. 

 함수명도 마찬가지다. 나의 예제는 아니지만 실제와 비슷한 예를 들어보면 누군가 파일명을 이용하여 사진을 가져오는 함수인 getImage(String)를 기존에 만들어두었는데 URL을 이용하여 가져오는 함수가 새로 필요했다. 고민을 하던 그는 함수명을 getImageFile(String)이라고 지었다. 이렇게 되면 두 함수는 파라미터의 타입도 동일하기 때문에 추후에 사진을 가져오고 싶은 다른 개발자는 getImage와 getImageFile의 차이가 뭔지 알 수 없고, 차이를 알기 위해 함수를 직접 들여봐야 한다. 아래와 같이 네이밍을 지으면 함수를 직접 들여다보지 않아도 함수명만으로 쉽게 의도를 파악할 수 있다.

 

 나도 개발을 할 때 함수명이 길어지면 이렇게 해도 되나..? 싶어서 자꾸 축약을 하곤 했는데 함수명이 길어지는 것보다 이름의 의도가 명확하지 않는 것을 두려워 해야 할 것 같다.

getImageByFileName(String fileName)
getImageByFileUrl(String fileUrl)