인프런 워밍업 클럽 3기 후기 - code

code 부분의 워밍업 클럽에 참여했었는데 약 1달동안 어떻게 시간이 가는지 모를정도로 시간이 빠르게 갔다. 생각보다 많은 강의와 이해하는데 걸리는 시간이 좀 오래걸렸었다. 예전에 강의는 사놨었는데 언제 볼까. 하면서 시간만 흘렀었는데. 이번기회에 강의를 완강할 수 있었어서 좋았다. 박우빈 님의 클린코드와 테스트코드 강의를 들었었는데 하도 강의를 돌려보고 다시보고 멈추고 코드치고 하느라 내면의 친밀감이 많이 들었다(길가다 마주치면 하이파이브라도 칠것 같은 친밀감?) 강의 자체는 무언가 코드를 짜는데 있어서 두려움과 테스트 코드, 테스트 코드를 노래는 불렀고 들었는데 어떻게 해야할지 막막하다면 들어보는 것을 추천한다.

인프런 워밍업 스터디 클럽 3기 4주 차 발자국

섹션 7: Mockito로 Stubbing하기Test Double 종류Dummy: 아무 기능도 없는 객체.Fake: 간단한 형태로 실제 기능 수행 가능하지만, 프로덕션에 적합하지 않은 객체.Stub: 미리 준비된 결과를 반환하는 객체로, 상태 검증에 사용.Spy: Stub이면서 호출 기록을 제공하며 일부는 실제 객체처럼 동작 가능.Mock: 특정 행위를 명세하고 동작하도록 설계된 객체로, 행위 검증에 사용.Mockito 주요 어노테이션@Mock: Mock 객체 생성.@Spy: 실제 객체의 메서드를 수행하되 특정 메서드만 Mocking.@InjectMocks: Mock과 Spy 객체를 자동 주입.BDDMockito행동 주도 개발 방식으로 given().willReturn()을 사용하여 테스트 작성.Classicist vs MockistClassicist: 실제 객체를 사용해 자연스럽고 직관적인 테스트. 리팩토링에 유리하지만 상태 검증만으로는 동작 오류를 놓칠 수 있음.Mockist: 모든 협력자를 Mock으로 대체하여 동작을 명확히 검증. 세부 구현에 의존적이라 리팩토링 시 테스트가 깨질 가능성이 있음.섹션 8: 더 나은 테스트 작성법테스트 작성 원칙한 테스트는 한 목적만 가져야 하며, if와 for 사용을 지양.LocalDateTime.now() 같은 제어 불가능한 값은 파라미터로 넘겨 제어.테스트 환경 독립성공유 자원을 사용하지 말고, 테스트 간 독립성을 보장.픽스처(Test Fixture)는 각 테스트가 내부 구현을 몰라도 이해 가능해야 함.Test Fixture 클렌징deleteAll(): 순차적으로 삭제, 성능 저하 우려.deleteAllInBatch(): 단일 SQL DELETE 쿼리로 대량 데이터 삭제 가능.반복 및 동적 테스트@ParameterizedTest: 여러 파라미터 값으로 반복 테스트.예: CsvSource, MethodSource 활용.@DynamicTest: 런타임에 동적으로 테스트 케이스 생성 및 실행.통합 환경 최적화서버 부팅 횟수를 줄이기 위해 통합 테스트 클래스를 상속 구조로 설계.예: @SpringBootTest, @ActiveProfiles("test").Private 메서드와 테스트 전용 코드Private 메서드는 직접 테스트하지 말고, 객체 분리를 통해 public 메서드로 검증.테스트 전용 메서드는 필요하면 작성 가능하나 신중히 접근.추가 내용Spring REST Docs vs SwaggerREST Docs: 신뢰도 높고 프로덕션 비침투적이지만 설정이 복잡함.Swagger: 적용이 쉽고 API 호출 가능하지만 프로덕션 코드에 침투적이고 신뢰도가 낮음. 후기 생각보다 봐야할 강의 양도 많고 이해하기가 어려워서 한 강의당 3번씩 돌려본것 같다. 특히나 하다가 테스트를 시도했는데. 아니 강의에서는 통과하는데 나는 실패했을때 실패지점 찾는데 진짜 애먹었다. 정신나갈뻔한 상황도 많았지만 많이 배울 수 있었다. 그럼에도 아직 어려운 부분이 많았다. 강의 : https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95/dashboard

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이 @Mock@Mock은 Mockito에서 제공하는 애노테이션으로, 특정 클래스나 인터페이스의 가짜 객체(Mock)를 생성한다.Spring 컨텍스트와는 무관하며, 순수하게 단위 테스트를 위해 사용된다.테스트 대상 객체가 의존하는 객체를 가짜로 만들어 테스트를 고립시키고자 할 때 활용된다.@MockBean@MockBean은 Spring Boot에서 제공하는 애노테이션으로, Spring 컨텍스트에 등록된 Bean을 Mock 객체로 교체한다.통합 테스트에서 특정 Bean의 실제 동작을 대체해야 할 때 사용된다.주로 서비스 계층의 일부 Bean을 Mock으로 교체해 컨트롤러 테스트를 진행하는 경우에 적합하다.@Spy@Spy는 실제 객체를 기반으로 부분적으로 Mocking을 할 수 있게 해주는 Mockito 애노테이션이다.객체 전체를 Mock으로 만드는 것이 아니라, 특정 메서드만 가짜 동작을 설정할 수 있다. 나머지 메서드는 원래 동작을 그대로 유지한다.실제 객체의 일부 동작만 변경하거나 추적하려는 경우에 적합하다.@SpyBean@SpyBean은 Spring Boot에서 제공하는 애노테이션으로, Spring 컨텍스트에서 관리되는 Bean을 Spy로 교체한다.@Spy와 비슷하지만, Spring 컨텍스트 내에서 관리되는 Bean에 대해 부분적인 Mocking이 가능하다는 점에서 차이가 있다.Spring 환경에서 특정 Bean의 일부 메서드만 가짜로 설정하고 나머지는 원래 동작을 유지하고자 할 때 사용된다.@InjectMocks@InjectMocks는 테스트 대상 클래스에 필요한 의존성을 자동으로 주입해주는 Mockito 애노테이션이다.생성자, 필드, 또는 setter를 통해 Mock이나 Spy 객체를 자동으로 주입한다.테스트 대상 클래스가 여러 의존성을 가지고 있을 때 이를 효율적으로 설정할 수 있다.Mock이나 Spy 객체를 단순히 생성하는 것을 넘어, 이들을 테스트 대상 클래스와 연결해주는 역할을 한다.이 애노테이션들은 각각의 목적과 상황에 맞게 사용되며, 단위 테스트에서는 주로 @Mock과 @InjectMocks가 사용되고, 통합 테스트에서는 @MockBean과 @SpyBean이 적합한 경우가 많다. @Spy는 실제 객체의 일부만 Mocking해야 하는 상황에서 유용하다. 2. 테스트 코드 리팩토링공통 항목(@BeforeEach)테스트 코드에서 중복되는 사용자 및 게시물 생성 로직을 @BeforeEach로 이동하여 공통화할 수 있다. class CommentServiceTest { private User user; private Post post; @BeforeEach void setUp() { // 사용자 생성에 필요한 내용 준비 및 사용자 생성 user = createUser(); // 게시물 생성에 필요한 내용 준비 및 게시물 생성 post = createPost(user); } @DisplayName("사용자가 댓글을 작성할 수 있다.") @Test void writeComment() { // given Comment comment = prepareComment(post, user); // when commentService.writeComment(comment); // then assertThat(commentRepository.findById(comment.getId())).isPresent(); } @DisplayName("사용자가 댓글을 수정할 수 있다.") @Test void updateComment() { // given Comment comment = prepareComment(post, user); commentService.writeComment(comment); String updatedContent = "Updated content"; // when commentService.updateComment(comment.getId(), updatedContent); // then assertThat(commentRepository.findById(comment.getId()).get().getContent()).isEqualTo(updatedContent); } @DisplayName("자신이 작성한 댓글이 아니면 수정할 수 없다.") @Test void cannotUpdateCommentWhenUserIsNotWriter() { // given User anotherUser = createAnotherUser(); Comment comment = prepareComment(post, user); commentService.writeComment(comment); String updatedContent = "Updated content"; // when & then assertThrows(UnauthorizedException.class, () -> commentService.updateCommentAsUser(anotherUser, comment.getId(), updatedContent) ); } private User createUser() { // 사용자 생성 로직 구현 return new User("user1", "password"); } private User createAnotherUser() { // 다른 사용자 생성 로직 구현 return new User("user2", "password"); } private Post createPost(User user) { // 게시물 생성 로직 구현 return new Post("게시물 제목", "게시물 내용", user); } private Comment prepareComment(Post post, User user) { // 댓글 생성 로직 구현 return new Comment("댓글 내용", post, user); } }

Layered Architecture 구조의 레이어별 특징과 테스트 작성법

1. 레이어별 특징Presentation Layer외부 세계의 요청을 가장 먼저 받는 레이어로, 사용자나 외부 시스템과의 인터페이스 역할을 한다.클라이언트로부터 전달받은 데이터를 검증하고, 비즈니스 로직을 수행할 수 있도록 Business Layer로 전달한다.주로 요청 파라미터에 대한 최소한의 검증과 API 응답 형식을 처리한다.Business Layer애플리케이션의 핵심 비즈니스 로직이 구현되는 레이어이다.Persistence Layer와 상호작용하며 데이터 처리 및 트랜잭션을 보장한다.비즈니스 규칙에 따라 데이터를 가공하거나 처리하는 역할을 담당한다.Persistence Layer데이터베이스와 직접적으로 상호작용하는 레이어로, 데이터 CRUD(Create, Read, Update, Delete) 작업에만 집중한다.비즈니스 로직이 포함되지 않으며, 순수하게 데이터 접근 및 저장소 관련 작업만 수행한다.2. 테스트 작성법Presentation Layer 테스트목적: 외부 요청에 대한 파라미터 검증과 컨트롤러 동작을 독립적으로 테스트한다.방법:하위 계층(Business Layer, Persistence Layer)은 @MockBean으로 모킹(mocking) 처리하여 독립적인 단위 테스트를 진행한다.Spring MVC 테스트를 활용해 HTTP 요청 및 응답 흐름을 검증한다.예를 들어, 잘못된 파라미터가 전달되었을 때 적절한 에러 메시지가 반환되는지 확인한다.Business Layer 테스트목적: 비즈니스 로직이 의도한 대로 동작하는지 검증하고, Persistence Layer와의 상호작용을 확인한다.방법:단위 테스트를 작성하여 특정 메서드의 동작을 검증한다.Persistence Layer를 실제로 호출하지 않고, Mock 객체를 사용해 독립적으로 테스트할 수도 있다.통합 테스트 시에는 @SpringBootTest와 실제 DB를 활용하여 트랜잭션 롤백 기능으로 데이터를 정리하며 테스트를 진행한다.Persistence Layer 테스트목적: SQL 쿼리가 제대로 동작하는지 검증하고, 데이터베이스와의 CRUD 작업이 정상적으로 수행되는지 확인한다.방법:@DataJpaTest를 활용하여 인메모리 DB(H2 등)를 사용해 빠르게 검증한다.단위 테스트 성격을 가지며, Repository 계층에서 작성한 쿼리 메서드가 의도한 대로 동작하는지 확인한다.테스트용 프로필 설정과 초기 데이터 주입 설정을 활용하면 편리하다.3. 테스트 방법 요약레이어주요 특징테스트 방법Presentation외부 요청 처리 및 파라미터 검증MockBean으로 하위 계층 모킹 처리 후 단위 테스트 진행 (Spring MVC Test 활용)Business비즈니스 로직 구현 및 트랜잭션 보장단위 테스트 또는 통합 테스트 (@SpringBootTest)Persistence데이터 CRUD 작업@DataJpaTest와 인메모리 DB로 SQL 쿼리 및 CRUD 동작 검증이처럼 각 레이어는 역할과 책임이 명확히 분리되어 있으며, 각 레이어에 맞는 적절한 테스트 전략을 적용함으로써 코드 품질과 유지보수성을 높일 수 있습니다. 출처 : https://inf.run/pZXb7

인프런 워밍업 스터디 클럽 3기 3주 차 발자국

Layered Architecture 테스트하기 어려운 부분 분리,테스트 하고자 하는 영역에 집중,명시적이고 이해할 수 있는 형태의 문서 작성 가능여러 가지 모듈이 합쳐진 결과를 우리는 예상 할 수 있는가?이를 위한 통.합.테.스.트통합 테스트🔸 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트🔸 일반적으로 작은 범위의 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없다.🔸 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트Library vs. Framework내 코드가 주체가 되어서 필요한 기능은 외부에서 끌어다 옴 vs. 이미 갖춰진 동작 환경에서 내 코드가 수동적으로 역할을 하게 됨Spring🔸 Ioc (Inversion of Control)객체의 생명주기를 주관해서. 필요한 객체가 있을때 필요한 객체를 제3자가 만들어서 주입해줌🔸 DI (Dependency Injection)생성자를 주입해서 사용함. 어디서 온 것인지는 알 수 없음(주는 것만 사용)🔸 AOP (Aspect Oriented Programming)비즈니스 흐름과 관계없는 부분을 하나로 모아서 다른 모듈로 분리해서 사용(스프링에서는 프록시 사용해서 구현 함)ORM (Object-Relational Mapping)객체지향에 대한 개념과 관계형 DB 간의 패러다임이 달라서 DB에 넣기에 어려움🔸 객체 지향 패러다임과 관계형 DB 패러다임의 불일치🔸 이전에는 개발자가 객체의 데이터를 한땀한땀 매피하여 DB에 저장 및 조회(CRUD)🔸 ORM 을 사용함으로써 개발자는 단순 작업을 줄이고, 비즈니스 로직에 집중할 수 있다.JPA. (Java Persistence API)🔸 Java 진영의 ORM 기술 표준🔸인터페이스이고, 여러 구현체가 있지만 보통 Hibernate를 많이 사용한다.🔸 반복적인 CRUD SQL 을 생성 및 실행해주고, 여러 부가 기능들을 제공한다.🔸 편리하지만 쿼리를 직접 작성하지 않기 때문에, 어떤 식으로 쿼리가 만들어지고 실행되는지 명확하게 이해하고 있어야 한다.🔸 Spring 진영에서는 JPA를 한번 더 추상화한 Spring Data JPA 제공🔸 QueryDSL 과 조합하여 많이 사용한다. (타입체크, 동적쿼리에 대한 장점. 실무에서는 필수로 사용하지만 강의의 범위를 넘어섬)🔸@Entity 테이블 과 객체를 매핑, @Id , @Column Entity 정의🔸@ManyToOne 두 객체간의 연관관계, @OneToMany, @OneToOne, @ManyToMany(일대다 - 다대일 관계로 풀어서 사용)엔티티 설계Order 와 Product 는 다대다 관계로서. 주문 입장에서 여러 음료수, 음료수 입장에서 여러 주문들이 된다.다대다 관계는. 일대다, 다대일 관계로 풀어서 접근할 것Order — OrderProduct — Product요구사항🔸 키오스크 주문을 위한 상품 후보 리스트 조회하기🔸 상품의 판매 상태 : 판매중, 판매보류, 판매중지→ 판매중, 판매보류인 상태의 상품을 화면에 보여준다🔸 id, 상품 번호, 상품 타입, 판매 상태, 상품 이름, 가격Persistence Layer🔸 Data Access 의 역할(여기에 집중한 레이어)🔸 비즈니스 가공 로직이 포함되어서는 안 된다. Data에 대한 CRUD에만 집중한 레이어Business Layer🔸 비즈니스 로직을 구현하는 역할🔸 Persistence Layer 와의 상호작용(Data를 읽고 쓰는 행위) 을 통해 비즈니스 로직을 전개시킨다.🔸 트랜잭션을 보장해야 한다.(로직을 전개하다 문제가 생기면 롤백해야 하기에, 롤백에 대한 트랜잭션을 보장해 줘야 한다). 작업 단위에 대한 원자성

인프런 워밍업 스터디 클럽 3기 2주 차 발자국

코드 다듬기와 리팩토링에 대한 요약1. 코드 다듬기주석의 양면성:주석은 코드로 설명할 수 없는 의사결정 히스토리를 기록하는 데 사용하되, 자주 변하는 정보는 주석으로 작성하지 않는 것이 좋다. 주석이 많다는 것은 비즈니스 로직이 코드에 잘 녹아들지 못했음을 의미할 수 있다.가독성을 위한 메서드와 변수 정렬:메서드는 상태 변경 > 판별 > 조회 순으로 나열하고, 접근 제한자는 public → private 순서를 유지하면 가독성이 향상된다.패키지 구조 설계:패키지는 문맥 정보를 제공해야 하며, 너무 세밀하거나 큰 단위로 나누면 유지보수가 어려워진다. 대규모 변경 시 팀원들과 반드시 협의해야 한다.클린 코드의 현실적 접근:클린 코드는 은탄환이 아니다. 요구사항이 변하지 않는 경우 절차지향적인 코드가 더 적합할 수도 있다. 실무에서는 품질과 빠른 결과물 사이에서 균형을 잡는 것이 중요하다.2. 리팩토링리팩토링의 본질:리팩토링은 단순히 코드를 변경하는 것이 아니라, 응집도를 높이고 결합도를 낮추는 과정이다. 객체 간의 관계와 책임을 점검하며 진행해야 한다.예외 처리와 boolean 반환:기존의 boolean 반환 방식을 예외 처리로 변경하는 것은 상황에 따라 좋을 수도, 오버엔지니어링이 될 수도 있다. 예외 처리는 비용이 크므로 신중히 사용해야 한다.일급 컬렉션 활용:컬렉션을 직접 노출하지 않고 이를 감싸는 클래스를 사용하면 유지보수가 쉬워지고 테스트 가능성이 높아진다.객체에 메시지를 보내라:무분별한 getter 사용 대신 객체에 메시지를 보내는 방식으로 설계하자. 예를 들어, isSamePassTypeWith 메서드를 통해 객체 내부에서 비교하도록 하면 캡슐화가 강화된다.인터페이스 활용:조건별로 다른 동작을 수행해야 할 때 인터페이스를 도입해 if문 사용을 줄이고 유연성을 높일 수 있다.3. 리팩토링 사례✅ 리팩토링 성공 사례중복 제거 및 메서드 추출:중복된 로직을 제거하고 메서드로 분리해 가독성과 재사용성을 높였다.StudyCafePassMachine 의존성 주입:필요한 의존성을 외부에서 주입받도록 하여 내부 구현을 외부에 노출하지 않도록 개선했다.도메인 모델 개선:StudyCafePassType 내 LOCKER_TYPES 상수를 선언해 사물함 관련 로직을 간단하게 처리했다.특정 타입만 처리하는 로직을 enum 내부에서 해결하도록 하여 책임 분리를 명확히 했다.Order 도메인 추출:스터디 카페 좌석 이용권과 사물함 이용권을 합친 Order 도메인을 새로 만들어 FixedPassType 관련 분기문을 간소화했다.❌ 놓친 부분과 개선 방향FileHandler 개선 필요:데이터를 가져오는 로직만 포함되어 있으나, File 관련 로직이 추가되면 클래스가 방대해질 우려가 있다. Provider를 통해 데이터 요구사항 중심으로 설계하는 것이 바람직하다.도메인과 View 로직 분리 부족:StudyCafePassType enum에 입력 관련 필드(command)가 포함되어 있어 도메인 모델과 View 로직이 섞였다. 이는 입력 방식 변경 시 도메인 모델까지 수정해야 하는 문제를 초래한다.4. 최종 결론좋은 코드는 단순히 동작하는 코드가 아니라, 이해하기 쉽고 유지보수 가능한 코드다.완벽한 설계는 없으며, 지속적으로 개선하며 유연한 구조를 만들어가는 것이 중요하다.객체 지향 설계의 핵심은 변경에 유연한 구조를 만드는 것이다.

워밍업 클럽 3기 1주차

강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법섹션 2. 추상섹션 3. 논리, 사고의 흐름섹션 4. 객체 지향 패러다임 (SOLID)에 대해서 강의를 들고 학습할 수 있었으며 내용이 그리 많지 않고생각보다 강의가 어렵지 않았으며 미션도 간단해서 한번더 생각해 볼 시간이 될 수 있었습니다 한주를 돌아봤을때 아쉬운 점이 있다면, 꾸준하게 하지 못하고 시간에 쫓기면서 급하게 강의를 듣고 미션한 감이 많아서 '내가 제대로 학습하고 내 것으로 만들었나?' 하는 의문에 시원스레 yes 라 답을 할 수 없었던것이 스스로를 돌아볼때 좀 부끄러웠습니다 다름 한주는 좀더 규칙적으로 꾸준하게 학습하고 배우고자 하며, 더 발전하는 제 스스로가 되었으면 합니다.

[인프런 워밍업 클럽 0기 BE] 3주차 발자국

[3주차 학습내용]미니프로젝트 '출퇴근 사내 관리 시스템' 만들기후기결과를 먼저 말하자면 프로젝트 다 못끝냈다. 만약 이 블로깅 하는게 미션이 아니었다면 절대 쓰지 않고 잠적했을 것 같다. 못 다한 짧은 프로젝트 과정을 설명하자면.... 생각보다 하나 하나가 좀 많이 어려웠다. 강의로 따라 칠때는 막히더라도 코드의 정답이 있다 싶이 하니. 해결이 되었지만, 간단한 역할 분리 service, repostiory, entity, controller 이렇게 라도 할려하니 서로의 역할이 헷갈리고 난해했다. 어찌 저찌 시작해서 진도를 나갔지만 어거지로 나갔다. 다른 사람의 코드를 매우 많이 참고하면서 진행을 하였는데. 진도쳐내기 바빳다 라는 말이 딱 어울릴 정도로 학습할 수 있었다. 처음 보는 JPA는 새로운 언어같고 전혀 적응이 되지 않는 상황속에서 배포를 위해 git을 사용하고 리눅스 명령어를 처음 접하는 입장에서 프로젝트를 처내는것이 너무 힘들었다. 특히나 디스코드에서 다른사람의 진행과정과 결과물을 볼 수 있었는데. 좀 너무 차이가 나니까 비교하면서 많은 시간 좌절에 빠져있었다. 솔직히 아직 좌절에 빠져서 프로젝트에 손을 못대고 다른 사람 코드와 결과물 구경에 많은 시간을 쏟았다. 잠시 프로젝트는 멈추고 다시 강의를 수강하면서 진행해 볼 생각이다. 약간 벽을 느꼈는데. 좀 돌아갈 생각이다. 좀 스스로에게 많이 아쉽고.............아쉬웠다..

[인프런 워밍업 스터디 클럽 0기_BE] 2주차 회고록 정리

짧은 다리의 두 번째 발걸음 6일차 역할의 분리와 스프링 컨테이너 Spring Bean: 스프링 컨테이너 안으로 들어간 클래스를 스프링 빈이라 함@Service와 @Repository를 통해서 Service와 Repository도 스프링 빈으로 등록가능함 @Primary: 어노테이션의 일좀으로 우선권을 정해줄 수 있다 @Configuration: @Bean과 함께 사용 @Bean: 메소드 객체를 스프링에 등록할 때 사용 @Component: @Controller, @Service, @Repository 모두 아니면서, 직접 작성한 클래스를 스프링 빈으로 등록한다 7일차 Spring Data JPA를 사용한 DB 조작 SQL 문 직접 작성의 문제-> 문자열 작성이어서 오타 발생시 알아채기 어려움, 컴파일 시점에 발견안되고 런타임 시에 발견된다-> 특정한 DB에 종속된다-> 테이블 마다 CRUD반복 작업이 필요하다-> 객체와 달리, 양방향이 아닌 단방향이다 JPA 를 통해 문제해결: 객체와 관계형 DB 테이블을 짝지어 데이터를 영구적 저장하도록 해주는 JAVA 진영 규칙 spring: datasource: url: "jdbc:mysql://localhost/library" username: root password: driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: none properties: hibernate: show_sql: true format_sql: true dialect: org.hibernate.dialect.MySQL8Dialect 8일차 트랜잭션과 영속성 컨텍스트를 이용한 요구사항 구현 트랜잭션: DB의 논리적 연산 단위. 1개의 트랜잭션에는 N개(≥1)의 SQL문 포함 @Transcational붙어있는 메서드가 시작할 때 트랜잭션을 시작예외 없이 잘 끝났다면 commit오류라면 rollback 영속성 컨텍스트: 테이블과 매핑된 Entity 객체를 관리/보관하는 역할, 스프링에서는 트랜잭션 사용 시 영속성 컨텍스트가 생성, 트랜잭션 종료 시 영속성 컨텍스트가 종료 특징변경감지쓰기 지연1차 캐싱회고: 과제가 끝나면서 조금 마음이 가벼워진 느낌이 있었다. 실제 프로젝트를 하려하니 생각이 많아지고 어떻게 하면 좋을지 고민하는 시간이 많았다. 코치님의 각 주차에 따라 내용을 따라는 가는것 같은데 막상 내것이 되었나 생각하며 코드를 치려고 하니 시간이 배로 걸리고 오류가 자주났다. 진짜 하,,,,,,,, 라고 한숨만 하루에 100번도 넘게 쉰적이 많았다. 특히나 db연결하는데 있어서 인텔리제이랑 mysql연동해놓고 하다가 컴퓨터 껐다가 켜서 시작 프로그램이 좀 지저분해 몇개 지우니 db연결이 끊기고 다시 연결안되는 문제로 한나절 고생한것을 생각하니 진짜 암담했다. jpa에 대해서 말만 듣고 실제 해보니 마법과도 같은 편리함과 놀라움이어서 재밌었다. 문법을 좀 알고 공부해야 할것 같은데. 이렇게 나마 써보고 배울수 있어서 유익한 시간이었다. 각 주차에 따라, 따라가는 것이 좀 버겁지만 걸어가든 기어가든 완주를 하면서 얻는것이 많다고 생각하기에 끝날때까지 복습하면서 완주해낼 생각이다. 남은 시간도 스스로에게 부끄럽지 않게 공부할수 있길 바란다.

인프런 워밍업 스터디 클럽 0기 BE - 1주차 발자국

1주차 회고 인프런에서 처음으로 시작하는 스터디 클럽에 들어간지 1주일이 되었습니다. 강의는 최태현님의 https://www.inflearn.com/course/lecture?courseSlug=%EC%9E%90%EB%B0%94-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EC%84%9C%EB%B2%84%EA%B0%9C%EB%B0%9C-%EC%98%AC%EC%9D%B8%EC%9B%90를 강사님께서 하루마다의 과제분을 주시고 공부한것을 블로깅 하는 방식이었습니다. 처음 과제의 양을 봤을때는 "할만한대?" 라는 생각으로 강의를 듣고 블로깅을 하였지만, 처음의 호기로운 생각은 어디가고 이것을 어떻게 글로써 풀어서 쓸지, 강의의 내용을 제대로 이해한 것은 맞는지 엄청나게 해매는 시간을 맛볼수 있었습니다. 강사님께서 훅훅 넘어가시고 중요한 개념을 짚어 주시고 진도를 나가시는데, 이것을 블로깅으로 조금 궁금한 점들을 계속해서 검색해보니, 아 spring이란것이 강사님께서 처음 접하는 사람들을 위해 최소한의 설명으로 이해하고 따라올 수 있도록 설명해주신 거구나, spring의 양은 방대하다는 것과 알아야 할 개념들이 많음을 피부로 느낄수 있었습니다. 또한 저의 부족함과 해야할 공부량에 압도 당하는 시간도 많았습니다. 스터디를 진행하면서 디스코드에 오늘의 과제분과 블로깅을 올려주시는 분들을 보면서 저와 비교되는 퀄리티와 이렇게 같은 강의를 듣고도 이렇게나 수준 차이가 난다고? 라는 생각을 떨쳐 버릴수 없었습니다. 그 와중에 강사님께서 해주신 말씀중 기억나는 것이 있었는데 한 수강생의 질문이 "백엔드 개발자로 취업하기 위해서 얼만큼 깊게 공부해야 하나요?" 라는 어조의 질문이었는데 "정해진 것은 없다 하지만 보통 아는것과 실력이 연봉과 비례한다" 라고 말씀해 주셨었습니다(잘 기억안남ㅎㅎ). 강사님의 말씀을 들으며 한가지 다짐을 했는데 '지금이 어떻든 나아지기 위해 지금의 스터디에 참가하고 좀더 잘하는 사람들의 결과물을 보며 내것으로 만들고 더 배우면 될것 아닌가?' 라는 다짐을 하게 되었으며 부족한 만큼 이 스터디 끝까지 완주해서 많은 것을 남겨 가야겠다 마음 먹었습니다. 이러한 스터디를 만들어 주신 인프런 분들께 감사드리고 열과 정성을 다해 가르쳐 주시는 강사님과, 함께 스터디를 참가하고 있으신 동료분들깨 감사드립니다. 이만 공부하러 가보겠습니다.