24.01.08 TIL

깨달은 점

나는 다른 팀원들보다 부족한 점이 많다...
많이 배워가쟈!
화이팅!

그리고 팀의 막내로서(맞나..?) 서기를 맡고 있는데 이후에 보니 너무 중구난방 정리가 되어있었다. 정리를 더 잘 하자!

01/06 자 개발 일지

안건1 : 객체지향의 5가지 원칙중 의존 역전 원칙 코드 컨벤션 추가 설정함!

User of(String email, String password…),
User of(UserCreateRequest) entity는 request에 의존하지 않고 그 자체로 존재해야 한다고 생각함
Request.toEntity(User) → User of(String email, String password…)
이 부분의 이후 문제점을 발견, Sequence 같은 경우 request가 필요하지 않는데 이것을 통일화하기 위해서는 SequenceRequest를 만들어야 하는데 불필요한 request dto인데 맞는 것 인가?
→ 하지만, 한 팀원의 의견(익명성 보장)은 굳이 entity를 생성하는 부분에서 이 request를 파라미터로 전달하는 부분이 꼭 모든 부분에서 통일화가 되어야 하는가? request를 전달하는 방식을 사용하자는 것은 개발의 편의성, 변경 가능성을 고려해서 적절한 방식을 혼용해서 사용하는 것이 어떤가입니다.
→ 이 request를 파라미터로 전달하는 방식과 필드를 파라미터로 전달하는 방식을 혼용해서 사용하는 것이 코드 내 통일성(= 컨벤션)을 위배하는 것인가? 에
대한 의견이 궁금합니다. → 저는 코딩 컨벤션이라는게 entity의 생성방식을 고정하는 것은 아니라고 생각하는데..

결론: 위의 의견에 대해서 튜터님은 정정펙토리 방식이 아닌 Request에 toEntity라는 해당하는 Request의 Entity를 생성할 수 있는 메서드를 사용해서 Entity가 Request에 의존하는 것이 아닌 Request가 Entity를 의존하게끔 하는게 좋다고 하셨다.

안건2 : Project Directory 구조에 대한 정리

goods(공연), sequence(회차), 좌석(seat), 공연장(place) 가 너무 depth 가 깊지않게 구성하고 싶은데 service나 controller가 작성되지 않더라도 패키지 분리가 좋을까요? 아니면 place → seat , goods → sequence 이런식으로 하위로 넣어주는 것이 명확할까요

결론: 프로젝트 기획상 분리하는것이 맞다고 판단됨

안건3 : Entity와 Dto의 변수 Type을 참조형으로 사용할지 아니면 원시타입으로 사용할지에 대한 의논

Long, User 참조형 타입 @ColumnDefault가 설정되어도 새로운 row insert할 때 default값이 들어가는것이아니라, null 로 들어가는데, long int 같이 primitive 타입이 아니라 기본 초기세팅 값 (0을 넣는 것이니깐, int long 같은 경우는 초기 세팅 값 0이라서 )
이유는 → 기본적으로 insert할 때, 객체의 모든 필드에 대해서 insert하기 때문에 null로 insert가 됨
@DynamicInsert, @DynamicUpdate 를 붙이면, null을 제외하고 row가 추가됨

결론: 튜터님은 Entity에서의 필드값은 유지보수 및 사용적 측면으로 봤을때 참조형이 더 좋을것 같다고 하셨다.

안건4: 경매 남은 시간 처리에 대한 아이디어

좌석 추가 시, 경매 등록(DB에)
redis 에 key(경매 id), value(해당 경매에 대한 입찰가) 남은 시간 등록(현재 ~ 경매 종료될 때까지의 시간) TTL
유저들이 좌석을 선택
웹 소켓을 여는데, STOMP 방식(채팅방 처럼), 1번 좌석을 선택한 모든 유저들을 하나의 채팅방에 초대하는 형식
여기서 redis에 저장된 남은 시간을 뿌려줌
경매 종료 == redis 에 키가 expire됨
키에 대해서 listener를 두고 계속 체크
이제 키가 없어지면, 경매 종료를 호출

결론: 아이디어 자체에서 문제점은 없음 따라서 좋은아이디어!

01/07 자 개발 일지

안건1: 예외처리진행시 Spring에 등록돼있는 메서드는 Overrided를 사용해서 Custom하는것이 좋은가?

예외 처리 핸들러 구현에서, 모든 예외에 대해 작성하는 것이 아니라 ResponseEntityExceptionHandler 추상 클래스에 정의되어 있는 예외들은 오버라이딩 하자

결론: Spring에 정리돼 있는 Exception 메서드는 @Overried 해서 사용하는것이 좋다. 즉 있는건 사용하자.

안건2: 회원가입시 휴대폰 인증에 대한 안건

휴대폰 인증 시점
:흰색_확인_표시: 선 인증(인증 번호 발송 시, 핸드폰 중복 여부 검증 → 회원 가입 버튼 누른 후, 인증 번호에 대한 검증)
가입 시, 인증 번호와 휴대폰 번호에 대해 같이 인증(후 인증)

결론: 1번 방식을 채택하여 진행 결정

안건3: 프로젝트 구조상 동시성 처리를 위해 사용할 수 있는 다양한 방식중 낙관적 락은 좋은 방법인가?

@Version(낙관적 락) → 동시에 접근하는 트랜잭션이 두 개 있다면, 먼저 접근해서 성공한 트랜잭션이 version을 올려주고, 이후에 늦은 트랜잭션은 버전을 확인하고 실패 처리됨
결론: 프로젝트를 진행하면서 동시성을 처리할 수 있는 방법들에 대해 진행해보고 추후 결정