티스토리

임지혁의 코딩일기

검색하기

블로그 홈

임지혁의 코딩일기

jihyukcoding.tistory.com/m

임지혁코딩 님의 블로그입니다.

구독자: 6

방명록 방문하기

주요 글 목록

테스팅 1. 멀티 쓰레드 환경 멀티 쓰레드란? 멀티 쓰레드란 무엇인지, 먼저 간단하게 정리하고 넘어가자. 실행 중인 프로그램의 단위를 프로세스, 프로세스의 작업 단위를 쓰레드라 함을 모두가 알고 있을 것이다.멀티 쓰레드 라는 것은, 하나의 프로세스 단위에서 여러가지의 쓰레드를 사용하는 것을 의미한다. 이와 같은 방식으로, 이미 메모리 공간을 할당받아 동작중인 프로그램에서 여러 작업을 처리하는 것을 의미한다. JAVA와 SPRING의 경우에서 JAVA에서는 기본적으로 , main이라는 한개의 쓰레드가 동작한다.데몬 쓰레드라는 것도 존재하는데, 이는 간단하게 '주 스레드의 작업을 돕는 보조적인 스레드' 를 의미한다.메인 쓰레드가 종료되면 같이 종료되는데, 이로 인해서 가비지 컬렉션 등 생명주기와 관련있는 작업을 하기 유리하다.메인보다.. 공감수 0 댓글수 0 2024. 5. 3.
리팩토링 5. 속도 향상 목표 + 예외처리 현재 결제 로직은 다음과 같다. 어떤 서비스가 가장 오래 걸리는가 즉, 현재 결제 이후 결제 문제가 생겨 이를 취소하는 과정이 가장 큰 시간을,혹은 결제와 구매정보 변동까지 되어 이를 저장하는 과정이 두번째로 큰 시간을 사용함을 알 수 있었다. *의외로, MSA구조에 따른 MINISERVICE간의 통신엔 큰 시간이 소요되지 않았다. 로직의 속도 증가가 더 큰 로직을 더 좋게 만들어보자 1. 결제가 잘못되어 취소를 보내야 할때public Mono validateandSave ( PortOnePaymentRecords portOnePaymentRecords, String paymentId, int frontPaymentClaim, String usere.. 공감수 0 댓글수 0 2024. 5. 2.
리팩토링 4 - WEBFLUX 이번 프로젝트에 참여하기 전에, 개인적으로 결제 시스템의 핵심은 비동기라고 판단했다. 하여 결제에 대한 부분을 비동기적인 형태로 완성했다. 하지만 리팩토링을 하면서 보니, 비동기적인 통신 형태에 대해 조금 더 명확하게정리하고 이를 비동기적으로 설계하면 어땠을까 라는 아쉬움이 있었다. WEB FLUX VS MVC? 먼저, WEBFLUX와 MVC 패턴에 대한 예시를 보아야 한다. 이와 같이, WEB FLUX와 MVC는 아키택처부터 다르다. MVC는 MODEL -VIEW- CONTROLLER 아키택처를 따른다.이는 현재 가장 많이 상용화된 아키택처로써, 서브 시스템을 호출하고 해당 시스템에MODEL이라는 정보를 전달, VIEW는 그것을 표현하는 시스템이다. 하지만 WEBFLUX는, 아키택처부터 다른.. 공감수 0 댓글수 0 2024. 4. 28.
리팩토링 3 - JPA 추상층 변경 JPA 현재 문제 이와 같이 , 기본적인 기능만 (따로 선언하지 않아도 되는) 사용하는 JPAREPOSITORY에 대한 리뷰를 받았다. 왜 이런 형태는 단점이 있을까? JPA의 구조: JPAREPOSITORY를 사용한다는 건, 영속성 컨텍스트를 이해 해야 한다. 영속성 컨텍스트 (PERSISTENCE CONTEXT): ENTITY를 영구 저장하는 환경 APPLICATION과 , DATABASE 사이에서 객체를 저장하는 가상의 DB가된다. (키:밸류 형태의 해시를 활용해, 조금 더 빠르게 사용하게 돕는다) FLUSH를 통해 실제 DB에 저장한다. ENTITY MANAGER: 이 영속성 컨텍스트를 관리한다. 엔티티를 저장하고 관리한다. 고민 JPAREPOSITORY를 활용한다는 건, 수많은 기능과 영속성 컨.. 공감수 0 댓글수 0 2024. 4. 19.
리팩토링 2 - 결제 검증과, XSS 등에 대한 방어 테스트 개인적으로 생각했던, 결제의 핵심은 검증과 검사였다. 여러가지 경우에 대해 방어 테스트를 진행했었지만, 리팩토링 과정에서 추가하고자 했던 검증 과정등을 정리하여보겠다. 현재 결제 과정은 1. member에 결제 요청 -> 2. 사용자 포인트가 결제 금액보다 작은지 검증 -> 3. 작다면, 그만큼 다시 front end로 전달-> 4. front end에선, 그 부족한 금액만큼 결제 진행 -> 5. 그 결제 금액을 검증받고, 저장, 승인 -> 6. purchase 부에서 다시 member 부로 전달(product의 상태 변경, 사용자 포인트 변경 등 수행) 1. 1000원을 결제하고, 100000포인트를 넣어달라는 악의적인 요청 이러한 경우는 JSON BODY로 악의적인 DATA를 전송하였거나,혹은 코드.. 공감수 0 댓글수 1 2024. 4. 19.
코드 리팩토링 1 - 코드 정리, 가독성 증가 구조 정리 1. 수 많은 dto들의 위치를 정리하였다. 현재 우리의 프로젝트는 MSA 구조이기 때문에, 서로의 동작을 약속하고 개발 과정은 완전히 독립적이다. 남이 보기에도 명확하게, 한눈에 보기 쉽게 DTO를 정리하였다. 2. SERVICE가 아닌 METHOD 단위의 분할을 진행하였다. 설계 과정에서 SERVICE의 범위를 최대한 세밀하게 분리하자는 생각에 따라 각 SERVICㄷ들이 1개의 메소드를 지니게 아주 잘게 서비스를 분할하였는데, 리팩토링 과정에서 해당 과정에 따른 높은 결합도의 문제에 대한 의견을 들었다. 전체적인 결제의 검증과 저장을 한 SERVICE로 묶었다. 해당 SERVICE들은 사실 메소드의 개수가 많지 않기 때문에 분할하여도 되었지만, 서비스의 범위 자체가 요청을 보내는 부 , 요.. 공감수 0 댓글수 0 2024. 4. 18.
testing의 전략을 수립하자. JUNIT 5는 무엇일까? 일단 특징이 있다. 전역변수로 COUNT를 선언하고, TEST1 ,TEST2에서 COUNT를 키워도값의 증가도 이루어지지않고, 주소 또한 다르게 나온다. STATIC 변수로 COUNT를 선언하면, 값의 증가가 이루어지지만 주소는 다르게 나온다. *허나, 주의해서 사용하자. 이 의미는 곧, 테스트코드의 실행시마다 인스턴스가 만들어진다는 뜻이다. @BERFORE ALL -> 테스트 실행전 한번 실행 @BERFOREEACH -> 모든 테스트의 실행 전 마다 실행된다 @AFTEREACH-> 모든 테스트마다 실행된 후 실행된다 @AFTERALL -> 테스트 실행 후 한번 실행된다. --다양한 파라미터를 편리하게 test할 수 있다. @ParameterizedTest @ValueSourc.. 공감수 1 댓글수 0 2024. 1. 21.
결합도를 낮추는 방법 결합도의 종류 : 자료 결합도 : 인터페이스가 자료요소로만 결합 스탬프 : 인터페이스로 배열 자료구조 형태 전달 제어 결합도 : 논리적인 흐름을 제외 외부 결합도 :외부 모델에서 참조한다 공유 결합도 : 공유되는 공유 데이터 영역이 있음 내용 결합도: 내용이나 내부 자료와 기능등을 참조 (정보처리기사 참조) 모듈간의 결합도는 낮고, 응집도는 높아야한다. *예시 MemberSignupSevice에서 , memberrepository,couponservice,emailservice등을 모두 주입받으면 어떡할까? + 트랜잭션으로 signup이라는 method에서 -> 1.entity 생성, 2. 회원가입 3. coupon 발급을 모두 진행하면, 트랜잭션상 문제가 발생할 수 있다. 또한, 트랜잭션으로 묶여 회원.. 공감수 0 댓글수 0 2024. 1. 21.
객체 구조를 어떻게 설정할까? 일단 인터페이스의 존재 이유를 깨닫자. 정보처리기사 출처 - 인터페이스란, 두 어플리케이션 간의 상호작용을 위한 중간다리 역할. 그렇다면 우리는 이 interface를 활용해서, 각 객체간의 의존성 관계를 줄여야 한다. ex) 카드사의 결제 구조를 생각한다면, service에 각 카드별 find 등을 구현한다면 최종 paycontroller에서는 수많은 객체들(삼성,bc카드)등과 다 의존되어야 한다. 그렇다면, 신한카드, 우리카드 등에 따라 다른 service를 구현해야할때, 이 모든 것을 interface로 묶어, 이 interface를 controller에서 의존받아서 사용하는 방식이 내부 정보를 가리고, 의존성을 감소시키는 데에 큰 도움이 된다. 1. 객체의 크기 findby id, findbyem.. 공감수 0 댓글수 0 2024. 1. 20.
ERROR /예외 처리 NULL요건을 지키지 않았거나, 문제가 발생했을때는 어떡할까? HTTP MESSAGE 중 배열이 비어있을경우 NULL이 아닌 빈 배열을 응답하게 된다. 404,403등의 수많은 ERROR MESSAGE를 보았다. 그 중에 4XX,5XX과 같은 경우에는 항상 동일한 포멧을 RETURN하는 형태로 ERROR처리가 이루어져야 한다. ERROR에 대한 처리를 MAP 객체를 통하는 방식은, 지양하자. ERRORRESPONSE를, 별도의 CLASS로 선언하여 객체 형태로 RETURN 하는 것이 좋다. 1. ERROR RESPONSE -> 안에 내부 FIELD로 ERRORCODE를 사용한다 . 2. 그 후의 ERRORCODE는 주로 ENUM 형태로, MESSAGE를 전송한다. CONTROLLER ERROR 처리 . .. 공감수 1 댓글수 1 2024. 1. 20.
Exception의 종류들 Exception을 control하는게 리팩토링에서 굉장히 중요하기 때문에, Exception의 종류들과 특징을 정리하고자 한다. Exception은 CHECKED, RUNTIME->UNCHECKED이렇게 2가지 종류가 크게 있다고 할 수 있다. ERROR는, OUTOFMEMEORY,SLIDEDEATH 등등 처리하기가 굉장히 힘들다 . 우리는 주로 EXCEPTION에 집중한다. CHECKED EXCEPTION과 UNCHECKED의 차이는, UNCHECKED는 RUNTIMEEXCEPTION을 상속 받는 다는 것이다! CHECKED EXCEPTION의 경우에는 반드시 예외를 처리해야한다. 1. METHOD에 THROWS EXCEPTION 추가 2. TRY -> CATCH방식으로 예외를 처리해야한다 . ROL.. 공감수 0 댓글수 0 2024. 1. 16.
오류보단, 예외로 처리하자 주로 Controller에서 발생한다. -> shutdown이라는 method가 있을때, 그 내부에서 exception까지를 모두 control하기 때문. 주로 try,catch에 따라서 처리를 하게되고 . 해당 exception을 control하는 역할을 분리한다. 1. 예외가 발생했는데 catch에서 하는일이 없다? : 이는 반드시 지양하며, 최소한 log라도 발생시켜주는 것이 좋다. 2. try catch를 사용하지 않는 것이 좋기는 좋다 ex) 환율이나 경제 api를 가져올때 -> 신한에서 없으면 하나은행으로 3. 만약에 필요하다면.. 예외를 받아서 더 구체적인 예외를 발생시키자. 이 느낌이다. 만약에 service에서 무슨 일을 한다고 하면. 그때 exception이 발생할 것이다. 이때 발생하.. 공감수 0 댓글수 0 2024. 1. 16.
객체를 망치지 않는, Lombok의 사용 여태까지는 모든 공부 과정에서 Lombok을 사용해왔다. 이러한 Lombok은 생성자의 형성 등 간단하고 명료하게 객체의 생성을 지원한다. 허나 Lombok의 오사용은, 객체를 망가뜨릴수 있다. 1. @DATA를 지양해야 할 수 있다. ID,EMAIL,NAME이 있는 TABLE이 있다고 생각해보자 . 무분별하게 모든 FIELD에 대해 생성자를 형성했다고도 가정해보자 . 그렇다면 , 생성자로 들어올 수 있는 EMAIL은 EMAIL의 변경이 가능함을 의미하는 것이 아닌가? 혹은, EMAIL과 NAME이 동시에 바뀌어야 한다면 (즉, 데이터의 쌍이 있다면) SETTER가 이러한 쌍의 변경이 아닌 한 데이터만의 변환을 유발할 수도 있다. @EQUALSANDHASHCODE는 두 객체의 값과 동일성을 비교해준다. .. 공감수 0 댓글수 0 2024. 1. 16.
패키지 구조 Layer과, Domain 형 계층이 있다 . Layer는 controller끼리, config끼리 묶이고 domian 같은 경우는 coupon -> controller,domain등으로 묶는 구조이다. Layer구조시는, 전체적인 구조를 쉽게 파악 할 수 있다. -> controller면 거기서 하면 된다. 하지만, 코드의 응집력 (코드끼리 분리되어 있는 것)이 떨어질 수 밖에 없다. Domain : 코드들이 응집되어있어, 상세적인 이해가 가능하다. 하지만 도메인 구조 없이는 이해가 굉장히 힘들다. Domain 구조가 최근에는 가장 권장하는 구조이다. 주로 config,error(exception),service,dto,table,repository등을 포함한 구졸 설계한다. 전체 범위에 적용되는 것도.. 공감수 0 댓글수 0 2024. 1. 16.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.