코드 리뷰 회고 (클린 코드, DB 모델링, 공통코드 or Enum)

여태껏 동아리 프로젝트들을 하면서 클린코드에 대해 잘 모르고 막 코드를 작성했었다는 걸 깨닫게 되었습니다..

인턴 생활을 진행하면서 시니어 개발자분이 코드리뷰를 해주시면서 배운 것들을 정리해보려 합니다😂

 

1. API 문서화

• SwaggerUI 를 통해 API 규격이 잘 드러나도록 하면 좋음
  1. FE 개발자와의 커뮤니케이션 비용을 낮출 수 있음
  2. 규격이 명확하면, FE 를 위한 DTO 자동생성도 가능함
• Swagger 어노테이션을 통해 설명을 많이 달아준다.
• DTO 는 Request, Response 를 명료하게 분리하기.
  • 클래스 수가 많아지더라도 파라미터가 다름을 FE 에게 인지시키는게 나을수도 있다. 
  • 필요한 경우 액션이름 포함하여 DTO 생성하기
    • ex) 사용자 설정정보 수정요청: UserSettingInfoRequest --> UserSettingUpdateRequest

2. 컴파일후 가장 깨끗한 상태 유지

• Warning 을 모두 없애기
• 코드상 잘못된 부분을 찾을때, Error/Warning 은 혼동을 유발한다
• 또한, 잠재적인 오류를 포함할 수 있다.
• 개발프로세스가 엄격한 경우, 정적분석도구(컴파일된 코드의 문제점 분석)를 이용하여 코드개선을 해야할 수 있다.
  • sonarcube 등의 툴을 이용하여 분석
  • 테스트 단계에서 코드가 안전한지 확인하고, 개선되어야만 통과된다.

3. naming convention 은 명료한 명칭사용하기

• Info 같은 명칭은 추상적으로 모든 정보를 포함할 수 있다.
  1. 정보에도 종류가 다양함
  2. Info 에서 특정 정보를 분리하여 Entity 로 만들기 원한다면? -> 구체적인 정보의 명칭표기로 변경

4. 유효성체크 로직 추가

• 가장 앞단의 Request,Response 에 validation 로직을 추가하여 400 에러 응답
• FE 개발자가 어떤게 잘못된 요청인지 인지할수 있도록 알려야 개발단계 커뮤니케이션 비용이 줄어듦
• 또한, 잘못된 값의 유입을 막을수 있음

5. class vs record ?

  record

  장점                                                                                                      

• 필드 값 변질의 우려가 없음                     
• 대부분의 보일러 플레이트 코드가 사라짐

     

    단점

• 필드 값 수정 불가             
• 상속 불가 (final 클래스)       
• abstract 선언 불가 (final 클래스)
• static이 아닌 멤버 변수 선언 불가

 

6. DB 모델링 어떤게 나을지 

자연키 와 인조키로 DB모델링을 했을 떄 생기는 차이에 대해 알아보았습니다.

요즘은 인조키로 만드는게 추세라고 합니다. 그 이유는 자연키 값이 바뀌는 상황이 온다면 시스템 전체적으로 문제가 생기기 때문입니다. 

	자연키	인조키
의미	실세계에서 Entity 를 유일하게 식별하는 키	인위적으로 부여되는 키
실세계와의 관계	실세계의 값을 그대로 사용	무관
생성주체	사용자로부터 입력받음	어플리케이션이 생성
예제	주민번호, 차량번호판	auto-increment
전달	쉽게 이해됨 (실시계값 그대로 이용)	한번 이상 거쳐야 이해가 됨
변경 가능성	변경가능성이 있는 경우 부적절한 선택 전화번호가 대표적인 비판예시.사용자의 핸드폰번호는 바뀔수 있다. 어떻게 대처할 것인가?	실세계값과 연관이 없으므로 변경에서 안전
복합키  발생	발생가능	필요없음
보안	보안을 필요로 한다면, PK 로 부적합 여러군데 값을 저장하여 암호화변경 등에 대처가 어렵다.	의미없는 값이므로 무관
비지니스 변경대처	변경가능성을 완벽하게 예측할 수 없다. 비지니스변경으로 인해 변경가능성이 발생하고 이로인해 유일성이 훼손될 수 있다.	비지니스 즉, 실세계의 값과는 무관하게 유일성을 보장한다.
쿼리 복잡성	Join 발생빈도가 보다 낮음.	간단한 조회문에도 Join 이 발생할 수 있음

 

 

7. 공통코드 vs Enum

  옛날에는 공통코드로 관리하는 프로젝트가 많았다고 합니다. 그 이유는 외부 사용자가 관리페이지 같은 것을 이용해 관리하기 편하게 사용하기 위함입니다.

Enum은 코드를 봐야 알 수 있기 때문입니다. 

하지만 요새 개발자가 직접 운영 관리를 하고 CI/CD가 구축되어 가면서 Enum으로 코드를 관리하는 것이 추세가 되어 가고 있습니다.

	공통코드	Enum
처리방식	"코드를 관리하는 테이블을 하나"만 만들고, 어플리케이션 전반에 사용	코드를 "어플리케이션 로직"에 관리
타입 세이프	별도의 체크로직이 필요함	보장됨.
코드별 Customizing	코드 특성에 맞는 속성을 정의하거나, 메서드를 넣기 어려움 개별 특성까지 맞추려면 초기설계단계에서 많은 노력이 필요함	Enum 고유의 기능을 활용하여 개별특성을 반영할 수 있음 어플리케이션에서 서비스, 유틸 클래스의 혼용을 줄여줌
변경 가능성대처	DB 에서만 변경 데이터변경이 아닌 속성이나 기능의 변경엔 취약함	어플리케이션을 변경하고 재구동하는 절차가 필요함 속성과 기능변경엔 유연함
성능	Join 을 이용하면 성능저하 보완책으로 캐시를 이용할수는 있음	DB 로직과 무관하게 코드값을 관리하므로 성능 영향없음
어플리케이션 의존도	DB 의존	철저히 어플리케이션 의존

 

참고 링크 : https://techblog.woowahan.com/2527/

Java Enum 활용기 | 우아한형제들 기술블로그