TIL

그냥 두서없이 메모하면서 쓴 글이라, 읽기 힘드실 겁니다... @Around("@annotation(piglin.swapswap.global.annotation.SwapLog)") public Object swapLog(ProceedingJoinPoint joinPoint) throws Throwable { HttpServletRequest req = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest(); log.info("start transaction"); log.info("\nMethod - {} | Method Argument - {}\nIP - {} | Browser - {}\n▼ ▼ ▼ ..

가장 큰 이유 레포지토리를 그냥 쓴다는 것은 JPA를 쓰는 것 JPA의 추상화 수준만 가져간다 → DB딴을 직접 연결한다는 것 개발 난이도 낮아지고 편함 → 비즈니스 룰을 가져갈 수 없음 A - B 의존을 별로 안 함 B - C 를 의존 소규모에서는 레포지토리 딴 넣는게 편할 것이다. 대규모 일때 문제가 됨 상품 → 결제 도메인이 있다면 상품이 결제 완료로 바꾸고 싶어했을 때 상품 도메인에서 바로 결제완료 시켜버린다면 결제 도메인에서 작성 한 비즈니스 코드를 활용하지 않는게 되어버림. 내가 모든 도메인의 비즈니스 로직을 파악하고 있어서 이런 고민이 생겼던 것 모든 아키텍처는 신입을 기준으로 → 신입이 처음 개발할 때 우리 회자 비즈니스 로직을 무시하고 레포지토리에 바로 접근하려고 하면? 😡 요령을 피우면..

@Around("@annotation(piglin.swapswap.global.annotation.SwapLog)") public Object swapLog(ProceedingJoinPoint joinPoint) throws Throwable { HttpServletRequest req = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest(); log.info("start transaction"); log.info("\nMethod - {} | Method Argument - {}\nIP - {} | Browser - {}\n▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ Cookie ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ..

Logback? Logback 은 Log4J(SL4FJ 의 구현체) 를 기반으로 재탄생한 SL4FJ 의 구현체로 스프링 부트 기본으로 들어있는 라이브러리이다. spring-boot-starter-web에 spring-boot-starter-logging 으로 들어있다. Spring Boot 는 기본적으로 CommonsLogging을 쓴다. Jul to SLF4J Log4J to SLF4J SLF4J -> Logback CommonsLogging을 쓰나 결국 Logback 으로 출력한다. Spring Boot에서는 우리 로깅 진~짜 잘 돼 있으니까 구현체를 바꾸거나 할 일이 없을 것이다 하고 얘기한다. Spring 프레임워크 5.0부터 Spring에는 spring-jcl 모듈에 구현된 CommonsLogg..

로깅? 프로그램 동작 시 발생하는 모든 일을 기록하는 행위다. 모든 일? 기록? 애매모호하다. 모든 일 (최소한의 목적) 서비스 동작 상태 시스템 로딩 HTTP 통신 트랜잭션 DB 요청 의도를 가진 Exception 장애(Exception, Error) I/O Exception NullPointException 의도하지 않은 Exception 로깅은 언제 할까? 나 메이플 직업 추천해줘 같은 질문 같다. 답이 없다는 뜻 프로젝트 성격에 맞게, 팀에 맞게, 로깅 시점은 때에 따라 다르다. 기록 로깅 프레임 워크를 알기전에 쓰던 방식 System.out.println("로깅") System.err.println("로깅 에러") 로깅 프레임 워크 Log4J... Log4J2도 있음 JUL 자바 정식 로깅 프레..

생각보다 많은 사용자가 우리 사이트를 이용해줘서 놀랐다. UI/UX 리뷰 말고 버그나, 성능적인 부분의 리뷰를 원했는데 설문 90%가 UI/UX이다. 근데 참여자 개발자 백엔드 비율은 전체 40% 인데... 왜.... 어쨌든, 기능 추가하면 좋을 거 같다는 의견도 조금 있었다. 버그도 조금 발견했고 요구사항을 말로만 전달했다가 기능 구현을 잊고있었던 부분도 캐치를 할 수 있었다. 생각보다 정말 많이 접속해주고 사람이 많으니까 여러가지 변수가 생겨서 이 부분에 대해 계속해서 캐치를 할 수 있었다. 내가 로컬에서 진행했을때는 사용자들이 이렇게 하겠지? 하면서 예상하며 했었는데, 블랙박스 테스트를 하면서 코드가 어떻게 동작할지 모르고 각종 만들어놓은 기능들을 테스트를 해주니, 진짜 예상하지 못한 부분을 발견해..