본문 바로가기

전체 글196

Project Section - PreProject Review Review 에서는 학습한 내용을 다시금 기록합니다. Unit Review는 학습한 내용 중 기존에 알고 있었지만 정확하게 이해하지 못하던 정보와 새롭게 알게된 정보를 기록합니다. 추가적인 설명을 요하는 부분은 댓글로 남겨주세요. Section Review는 전반적인 Section을 되돌아보고 학습했던 시간과 과정, 내용을 총괄하여 기록합니다. 프로젝트 섹션의 두 가지 큰 미션 중 하나였던 프리 프로젝트가 끝났다. 컴퓨터공학을 이중전공하긴 했지만, 할 줄 아는게 없어 '협업'의 '협'자도 몰랐던 나로써는 처음으로 프론트엔드 사이드의 분들과 협업할 수 있는 시간이 되었고, 또한 처음으로 스프링을 활용한 웹 서비스를 만들어볼 수 있어 얻어간 것이 많은 프리 프로젝트였다. 이번 회고에서는 기존의 섹션 리뷰에서.. 2023. 6. 27.
[6/22 TIS] configuration에서 발생할 수 있는 순환 참조에 주의하자. 프리 프로젝트를 진행하고 테스트를 위해 애플리케이션을 실행하는 과정에서 순환참조 문제가 발생했다. 생성자 레벨에서 순환 참조를 최대한 주의했기 때문에 어느 부분에서 순환 참조 문제가 생기는지 알 수 없었다. 순환참조가 발생한다고 알려주는 클래스 들에서는 생성자 레벨에서의 DI에 의한 순환참조는 발생하지 않았다. 문제 상황은 Configuration 클래스와 Service클래스에서 발생했다. 도저히 뭐가 문제인지 모르겠어서 구글링을 진행했고, 비슷한 사례를 겪으신 분의 글을 발견해 해결할 수 있었다. https://velog.io/@platinouss/Spring-Circular-References-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0 [Spring] 순환 참조(Circular.. 2023. 6. 22.
Section 4 - Section Review Review 에서는 학습한 내용을 다시금 기록합니다. Unit Review는 학습한 내용 중 기존에 알고 있었지만 정확하게 이해하지 못하던 정보와 새롭게 알게된 정보를 기록합니다. 추가적인 설명을 요하는 부분은 댓글로 남겨주세요. Section Review는 전반적인 Section을 되돌아보고 학습했던 시간과 과정, 내용을 총괄하여 기록합니다. 마침내 이 날이 오고야 말았다. 마지막 섹션을 마치고 이제는 프로젝트만 남겨놓은 단계다. 마지막 섹션을 끝마친만큼 이번 섹션 리뷰는 지난 한 달이 아니라, 2월부터 거쳐온 부트캠프 전체 기간을 좀 돌아보고자 한다. 4개월이라는 짧지 않은 시간 중 첫 절반은 부트캠프를 통해 생활 습관을 만들 수 있었고, 나머지 절반은 부트캠프를 통해 여러 기술들을 공부할 수 있었다.. 2023. 6. 8.
[6/7 TIS] DELETE는 Transactional하게 진행하자. 엔티티를 delete하는 로직을 만들던 중 다음과 같은 에러를 마주했다. No EntityManager with actual transaction available for current thread - cannot reliably process 'remove' call 대충 보아하니 remove를 안정적으로 할 수 없다는 말이 있었고, transaction이라는 키워드가 눈에 밟혔다. 해당 에러 메세지를 검색해보니 @Transactional 애너테이션을 통해 delete메서드를 수행하는 로직 자체를 트랜잭션 처리하면 삭제가 정상적으로 수행된다고 했다. 그대로 수행했고, 문제 자체는 쉽게 해결했다. 그런데, 왜 삭제 로직은 트랜잭션 처리를 해야하는지가 궁금했다. 삽입, 수정, 조회는 잘 되는데. 라고 생각.. 2023. 6. 7.
나는 왜 알고리즘 문제를 어려워하는가? 알고리즘 문제를 풀고 생각난 점을 적어보았습니다. 해당 문제에 대한 삽질 및 풀이의 과정은 링크에서 확인하실 수 있습니다. 먼저 해당 방법을 공유해 주신 분에게 큰 감사의 말씀을 드린다. 정말 머리를 망치로 한 대 맞은 것 같았다. 너무 쉽게 해결할 수 있는 문제였다. 다르게 생각해보면, 나는 왜 이렇게 쉬운 방법을 생각하지 못했을까? 라는 생각이 들었다. 두 개의 수를 비교할 때, 왜 여러 가지 경우의 수를 전부 처리하려고 애썼을까 했다. 결국 핵심은 두 수의 우선순위 비교였는데, 그 부분을 계속 놓치고 있었다. 보통 내가 알고리즘 문제 풀이에 실패할 때는 위와 같은 경우다. 문제의 본질을 파악하지 못하고 너무 저차원적으로 문제에 접근한다. 이런 문제는 차후에 어플리케이션을 설계하고 프로그래밍을 진행하.. 2023. 5. 31.
나는 왜 Mapper를 사용하지 않는가? 부트캠프 내에서 Dto를 엔티티 객체로 전환하는 방법 중 하나로 mapper를 사용하는 방식을 배웠다. Dto를 객체로 '변환'하는 역할은 어떤 객체가 해내야만 하는 일이었고, 부트캠프에서는 이 방법 중 하나인 mapper를 가르쳐주며, 상당히 간편하게 사용할 수 있음을 말해주었다. 실제로 그랬다. 애너테이션을 붙이고 JPA를 사용하듯이 메서드 이름만 작성해주는 인터페이스를 사용하면 간단하게 매핑이 가능했다. 문제는 복잡한 매핑에서 일어났다. JPA에서도 복잡한 쿼리는 쿼리 애너테이션을 붙이고 직접 작성하듯이, mapper 에서도 복잡한 매핑은 defualt 메서드를 만들고 내부적으로 매핑의 과정을 거쳐야 했다. 그런데 생각해보니 이게 정말 '매핑'이 맞나? 하는 생각이 들었다. mapping이란 무엇인.. 2023. 5. 31.
반응형

티스토리툴바