코드 작성 기준

[haxr369]

코드 작성

[ooMia]

기준을 정리하기 위해 프로젝트라는 큰 관점에서부터 접근하고 있습니다.
GitHub Copilot에게 받은 질문 중 현재 관심사에만 체크를 해두고 있습니다.

프로젝트 진행 전 합의 사항

현재 코드 통합과 기능 명세서 작성이 조사의 목적이다.

• 프로젝트 목표 및 범위: 프로젝트의 최종 목표와 그를 달성하기 위한 범위
• 역할 분배: 팀원 각각의 역할과 책임
• 프로젝트 일정: 프로젝트의 주요 마일스톤과 완료 예정일
• 커뮤니케이션 방법: 팀원 간의 커뮤니케이션 채널과 방법, 회의 일정
• 개발 도구 및 환경: 사용할 개발 도구, 프로그래밍 언어, 프레임워크, 버전 관리 시스템
• #FF0000 코드 스타일 및 품질 관리: 코드 스타일 가이드, 코드 리뷰 프로세스, 테스팅 전략
• #FF7F00 문서화: 프로젝트 문서화 방법과 필요한 문서의 범위

설계 단계 합의 사항

요구사항은 기능과 에러 처리에 대해 명시적으로 서술한다.
다만, 기능의 분량이 크고 복잡하므로 상대적으로 더 중요하다.
코드 재사용 및 확장성에 대한 부분은 기준이 없어서 조사가 필요하다.

• 비기능적 요구사항: 성능, 보안, 사용성
• #FF0000 기능적 요구사항: 데이터 모델, 알고리즘, 아키텍처
• #FF0000 코드 재사용 및 확장성: 코드 재사용, 요구사항 변경에 대한 유연한 대응
• #FF7F00 에러 처리: 예상 가능한 에러 상황, 이에 대한 적절한 처리 방안

설계 문서화

프로젝트 README에는 요구사항을 적어두어야 한다.
docs/README.md에 작성할 구현 명세는 여기서 설계 문서에 가깝다.
다만, 이번 Lotto 프로젝트는 코드 통합을 위해 다음을 모두 구체화해야 한다.

• 폴더 구조
• 클래스 명
• 역할

• #FF7F00 설계 문서 작성: 아키텍처 다이어그램, 데이터 모델, API 설계
• 주석 작성: 코드 내 주석 (기능, 작동 방식, 사용 방법)
• README 파일 작성: 프로젝트 개요, 설치 및 사용 방법, 기여 가이드라인

코드 품질 개선

• 코드 리뷰: 팀원 간 코드 검토하며 피드백을 주고 받는 과정
• 테스트 자동화: 단위 테스트, 통합 테스트, 시스템 테스트
• 정적 코드 분석: Lint 도구로 코드의 스타일과 버그 검사
• 코드 메트릭: 코드 복잡성, 중복성 등의 메트릭 측정
• CI/CD: 변경 사항을 자주 통합하고 배포하여 문제 발견과 해결 사이클 간소화
• 리팩토링: 기능 변경 없이 내부 구조 개선

[ooMia]

MVC

1. Model은 Controller와 View에 의존하지 않아야 한다.
2. View는 Model에만 의존해야 하고, Controller에는 의존하면 안 된다.
3. View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
4. Controller는 Model과 View에 의존해도 된다.
5. View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.

Record 사용 기준

• (선택) record에 primitive type 또는 불변 객체를 사용하기
• enum과 구분하기
  • enum은 차후 변경 가능성이 적고, 다수의 레이어에서 공통적으로 사용하는, 일차원적으로 매핑되는 상수에 한하여 사용한다.
  • enum을 사용하더라도 결국 조건문을 사용해서 처리함 (src/main/java/lotto/util/Winnings :: valueOfWinningsAndBonus)

예외 처리

호출하는 시점에 파라미터를 결정할 권한이 있는 시점에서 예외를 catch하여 '처리'한다.

• (exception이 메서드를 타고 올라온다는 것이 어떤 안티 패턴에 대한 이야기인지 모르겠음)

메서드명

• getter와 setter의 사용을 지양해야 한다.

YAGNI

• 요구사항에 존재하는 최소한의 내용만 작성하기
• 사용되지 않는 코드는 삭제 또는 작성 의도와 함께 주석 처리
• Model의 서비스에 대한 함수형 인터페이스를 작성하자 (단, 외부에서 사용하게 되는 시점에)

자료구조 선택

• 항상 정렬된 상태를 보장해야 하는 경우에만 정렬 자료 구조 사용

[haxr369]

프로젝트 개발 기준

기본 패턴 설정

앞으로 스프링 템플릿으로 발전과 난이도를 봤을 때 MVC 패턴을 익히는 것이 중요함

폴더 구조

• controller: 클라이언트의 입력을 처리하고 비즈니스 로직을 호출하는 부분입니다.
• domain: 애플리케이션의 데이터 모델을 정의하는 부분입니다.
  • service: 비즈니스 로직을 수행하는 부분으로, 데이터 모델과 컨트롤러 간의 인터페이스 역할을 합니다.
  • **ResponseStatus** : 각 도메인에 맞는 예외 메시지를 저장, 필요에 따라선 HTTP code도 포함
• view: 사용자 인터페이스를 표현하는 부분으로, 일반적으로 웹 애플리케이션에서는 사용되지 않을 수 있습니다.
• **common**: 여러 클래스에 걸쳐 공통으로 사용되는 클래스를 작성 ex) 유효성 검사

명명 규칙

접두사	설명	사용 사례
get	값을 가져오거나 조회하는 동작을 나타냅니다.	getBalance(): Retrieves the balance.
set	값을 설정하거나 업데이트하는 동작을 나타냅니다.	setQuantity(int quantity): Sets item quantity.
create	새로운 인스턴스를 생성하거나 새로운 객체를 만드는 동작을 나타냅니다.	createOrder(): Creates a new order.
generate	주로 무작위로 값을 생성하거나, 어떤 작업을 통해 자동으로 생성되는 동작을 나타냅니다.	generateToken(): Generates a random token.
process	어떤 데이터나 자원을 처리하거나 변형하는 동작을 나타냅니다.	processPayment(): Processes a payment.
validate	주어진 조건에 대해 유효성을 검사하는 동작을 나타냅니다.	validateUserCredentials(User user): Validates user credentials.
compute	계산이나 연산을 수행하는 동작을 나타냅니다.	computeTotalPrice(): Calculates total price.
handle	예외나 특정 상황을 처리하는 동작을 나타냅니다.	handleException(Exception e): Handles an exception.

handleUserInput(String input): Handles user input. |

예외처리

사용자 입력에 대한 예외는 컨트롤러에서 최대한 처리. 그럼 DB에서 발생한 예외는 Spring의 경우 @ExceptionHandler 사용으로 일괄 처리 혹은 repository에서 예외처리

enum과 record

enum : 비교적 바뀌지 않는 모델 정의. 상수

record : 런타임에서 객체 생성 시 필드 값이 정해지는 VO

[haxr369]

Spring Data JPA Transaction 모범 사례

1. Transaction scope는 최대한 작게 유지하자
2. 긴 시간 동안 Transaction 작업은 피하자
3. Propagation 인자를 신중하게 설정하자
4. Exception을 명확하게 발생시키고 해결하자
5. 하나의 EntityManager나 SessionFactory를 사용하자 - (이건 필수적인지 모르겠습니다.)
6. 낙관적 락을 사용하자
7. 읽기 작업에서는 Read-only 속성을 붙여주자

Implementing Transactions in a Spring Boot Application

[ooMia]

Transaction scope를 최대한 작게, 작업 시간 또한 최대한 짧게 유지해야 한다.

• 트랜잭션 범위가 넓고 시간이 길어질수록, 다른 트랜잭션들이 해당 데이터에 접근하는 것이 제한되므로 성능이 저하될 수 있습니다. 트랜잭션의 타임아웃 설정을 통해 트랜잭션이 너무 오래 걸리는 것을 방지할 수 있습니다.
• 슈퍼마켓에서 한 사람이 장바구니를 너무 오래 들고 다니면 다른 사람들이 원하는 물건을 가져가지 못하는 상황과 비슷합니다.

읽기 작업에서는 Read-only 속성을 붙이기

• 읽기 전용 트랜잭션은 데이터베이스에서 불필요한 락을 방지하고, 일부 데이터베이스에서는 읽기 전용 쿼리의 성능을 향상시킬 수 있습니다.
• 읽기 전용 트랜잭션을 사용하는 것은 마치 도서관에서 책을 읽기만 하려는 사람에게는 다른 사람이 그 책을 빌려갈 수 있도록 하는 것과 비슷합니다. 책을 읽기만 한다면, 그 책을 빌리는 것이 아니라 다른 사람이 동시에 그 책을 사용할 수 있게 하여 도서관의 자원을 효율적으로 사용할 수 있게 합니다. 이처럼, 읽기 전용 트랜잭션은 데이터를 변경하지 않고 오직 읽기만 하는 작업에서 데이터베이스의 자원을 효율적으로 사용할 수 있게 합니다.

Exception을 명확하게 발생시키고 해결하자

• 트랜잭션에서 발생하는 예외는 적절하게 처리되어야 합니다. 또한, 롤백이 필요한 경우에는 명시적으로 예외를 발생시켜야 합니다.
• 실패한 요리를 다시 시작하기 전에 무엇이 잘못되었는지 정확하게 파악하고 문제를 해결하는 것과 비슷합니다.

Propagation 인자를 신중하게 설정하자

• 트랜잭션 전파 옵션은 트랜잭션의 동작 방식을 결정합니다. 이는 비즈니스 로직에 따라 적절하게 설정해야 합니다.
• 트랜잭션 전파 옵션을 설정하는 것은 마치 여러 사람이 같은 작업을 수행할 때 각자의 역할을 어떻게 분배할지 결정하는 것과 비슷합니다. 예를 들어, 집을 청소하는 작업을 생각해보세요. 한 사람이 모든 작업을 담당할 수도 있지만, 효율적으로 작업을 수행하기 위해선 각자가 청소할 영역을 나눠서 작업하는 것이 좋습니다. 이처럼, 트랜잭션 전파 옵션은 여러 작업이 동시에 일어날 때 어떤 작업이 다른 작업에 영향을 미치는지, 또는 독립적으로 수행되어야 하는지를 결정합니다.

하나의 EntityManager나 SessionFactory를 사용하자

• EntityManager나 SessionFactory를 사용하는 목적은 데이터베이스와의 상호작용을 추상화하고, 데이터 접근 코드를 보다 간결하고 유지 관리하기 쉽게 만드는 것입니다.

  • EntityManager는 JPA(Java Persistence API)의 핵심 인터페이스로, 엔티티를 생성, 읽기, 업데이트, 삭제하는 등의 CRUD 연산을 수행합니다. 또한, 트랜잭션 관리와 쿼리 실행 등의 작업도 수행합니다. SessionFactory는 Hibernate ORM에서 사용되며, Session 인스턴스를 생성하는 역할을 합니다. Session은 데이터베이스와의 단일 유닛 작업을 나타내며, EntityManager와 유사하게 CRUD 연산과 트랜잭션 관리를 수행합니다.

  • 두 클래스 모두 데이터베이스와의 상호작용을 관리하는 역할을 합니다. 그러나 둘은 사용되는 기술과 제공하는 기능에 따라 차이점이 있습니다.

    • 기술: EntityManager는 JPA(Java Persistence API)의 일부로, JPA는 자바 플랫폼에서 제공하는 ORM(Object-Relational Mapping) 표준입니다. 반면에 SessionFactory는 Hibernate ORM 프레임워크의 일부로, Hibernate는 JPA의 구현체 중 하나입니다.

    • 세션 관리: EntityManager는 각 트랜잭션에 대해 새로운 EntityManager 인스턴스를 생성하고, 트랜잭션이 끝나면 인스턴스를 닫습니다. 반면에 SessionFactory는 Session 인스턴스를 생성하고 관리하는 역할을 합니다. Session은 데이터베이스와의 단일 유닛 작업을 나타내며, EntityManager와 유사하게 CRUD 연산과 트랜잭션 관리를 수행합니다.

    • 기능: EntityManager와 SessionFactory 모두 CRUD 연산과 트랜잭션 관리를 수행하지만, Hibernate의 SessionFactory는 Hibernate의 고급 기능(예: 쿼리 힌트, 통계 수집 등)을 사용할 수 있습니다.

• 각 데이터베이스에 대해 별도의 EntityManagerFactory 또는 SessionFactory를 사용하는 것이 바람직합니다. 이는 각 데이터베이스의 연결 정보와 설정이 다를 수 있기 때문입니다.
• 여러 도시를 여행하는 사람이 각 도시마다 다른 가이드를 고용하는 것과 비슷합니다.

트랜잭션 격리 수준과 동기화 정책 (락)

• 도서관에서 대학교 전공 서적을 빌릴 수 있다고 가정합시다. 단순히 내용을 읽는 건 도서관 내에서 얼마든 가능하지만, 실제 수업에 교재를 소지하기 위해서는 반드시 대여를 해야만 합니다. 다소 비현실적인 가정이지만, 교재에 필기를 하지 않는다는 가정 하에서는 1억명 이상이더라도 도서관에 함께 모여 얼마든지 책의 내용을 읽을 수 있습니다. 하지만 단 한 명이라도 교재에 필기를 하겠다고 대여한다면, 두 가지 경우로 나뉩니다.

1. 최신 변경 사항을 보기 위해 계속 기다리는 경우
2. 기다리지 않고 그냥 가장 최근에 변경된 내용을 보는 경우

이러한 내용은 트랜잭션 격리 수준과 연관되어 있습니다.

트랜잭션 격리 수준 설정

• 이는 트랜잭션에서 동시에 발생하는 여러 작업이 서로 어떻게 영향을 미치는지를 결정하는 중요한 설정입니다.
• 여러 사람이 같은 작업을 동시에 수행할 때 각자의 작업이 다른 사람의 작업에 어떻게 영향을 미치는지를 결정하는 것과 비슷합니다.

동기화 정책 (락)

• 낙관적 락은 동시성 문제를 해결하는 데 유용한 기법입니다. 그러나 모든 상황에 적합한 것은 아니며, 비즈니스 요구 사항과 동시성 수준에 따라 적절하게 사용해야 합니다.
  • 낙관적 락은 데이터 변경을 가정하지 않고 동작합니다. 도서관의 책을 인터넷으로 검색하고 대여하는 것과 비슷합니다. 책이 도서관에 있다면 대여할 수 있을 것이라고 '낙관적'으로 가정합니다. 그러나 도서관에 가서 보니 책이 이미 대여된 상태라면 대여할 수 없습니다. 이처럼, 낙관적 락은 데이터 변경 시점에만 락을 걸어 일관성을 유지합니다. 이 방식은 동시성 문제를 해결하면서 성능을 향상시킵니다.
  • 비관적 락은 데이터를 처음부터 락(잠금) 걸어 다른 트랜잭션이 변경하는 것을 막습니다. 이는 도서관의 책을 인터넷으로 예약하는 것과 비슷합니다. 책을 예약하면 다른 사람이 대여할 수 없는 상태가 됩니다. 즉, '대여 예약'을 통해 책을 선점한 것입니다. 이 방식은 동시성 문제를 효과적으로 해결하지만, 성능 이슈가 발생할 수 있습니다.