인프런 워밍업 클럽 4주차 발자국

4주차 강의 정리Presentation Layer -> 사용자와 시스템 사이의 외부 값을 검증@WebMvcTestMockingMockMvc@Mock@MockBean@InjectMocks@Spy@SpyBeanLayer별 DTO -> 모듈 분리시 의존성 문제 가능성 제거, 책임 분리@Transactional@Transactional(readOnly=true)긴 작업일때는 지양 @Valid@NotNull@NotEmpty@NotBlank Test DoubleDummyFakeStubSpyMockBDDMockitoClassicist -> 실제 모듈을 사용해서 통합 테스트 지향Mockist -> 기능 보장된 것은 제외하고 빠른 테스트 지향테스트의 목적은 하나로 하는게 좋다.제어 가능한 영역으로 분리하여 테스트테스트 독립성 테스트에 영향을 주는 다른 요소 제거테스트간 공통 의존 제거Test Fixture@BeforeEach는 테스트 로직과 관련성이 적은 요소 위주테스트는 문서다 -> 정보의 파편화 발생 가능성테스트 환경 통합 -> 테스트를 위해 Spring Boot 실행 횟수를 감소시키는 방향으로 4주차 강의 회고좋았던 점실무에 적용되는 테스트 팁을 알 수 있었다.명확한 테스트 방법에 대해 생각해볼 수 있었다. 아쉬웠던 점특별 라이브에 참석하지 못한 점이 아쉽다.배운 점Spring 진영의 테스트 세부 기능명확한 테스트 문서 작성 방법 앞으로 바라는 점미션Day15https://lapis-dew-01f.notion.site/Day15-1267d24093d680bb8d2ed4c5e35a6a5b?pvs=74Day18https://lapis-dew-01f.notion.site/Day18-12a7d24093d680659325ed3c31986b56

인프런 워밍업 클럽 3주차 발자국

3주차 강의 정리테스트의 필요성 -> 커버할 수 없는 영역 발생 방지, 감보다 코드에 의존잘못 작성된 테스트 코드 -> 새로운 짐올바른 테스트 코드수동 테스트 -> 콘솔 출력 및 개발자에 의한 판단자동 테스트 -> 안정성 및 유지보수성 증가단위 테스트 -> 클래스 및 메소드 단위, JUnit5, AssertJ해피 케이스와 예외 케이스 -> 경계값 테스트테스트하기 어려운 영역을 분리하여 production code와 test code를 교체할 수 있도록 테스트 설계TDD -> 프로덕션 코드보다 테스트 코드를 먼저 작성, Red-Green-RefactorTDD로 엣지 케이스 발견 가능성을 높이고 복잡도가 낮은 코드 구현 가능테스트 코드가 기능의 보조 수단이 아닌 동등한 관점에서 협력하는 관계가 될 수 있다.기능을 설명하는 문서 -> 기능 이해 도움 & 고민의 결과물@DisplayNameBDD -> given-when-then통합 테스트Library vs Framework -> 내 코드의 관점@SpringBootTest vs @DataJpaTestassertThat().extracting().contains()Persistence Layer -> Data Access의 역할Business Layer -> 비즈니스 로직 구현 역할@Transactional vs tearDown() 3주차 강의 회고좋았던 점테스트에 대한 필요성에 대해 더 잘 알게 되었다.TDD를 실제로 적용해볼 수 있었다.Spring & JPA에 테스트를 적용할 수 있었다. 아쉬웠던 점테스트 지점을 아는 것이 어려웠다 배운 점테스트 도구 사용법단위 테스트와 통합 테스트 적용 방법앞으로 바라는 점테스트 커버리지 도구와 CI에 테스트 적용하는 법 공부미션Day12고민했던 점IO 담당하는 부분 테스트를 어떻게 해야하는지파일 입력을 테스트 상에서 구현하는 방법? @MappedSuperclassJPA에서 엔티티의 공통 속성을 정의하기위해 사용.부모 클래스에 정의된 모든 속성은 자식 클래스의 테이블에 포함@EntityListenersCollectors.groupingBy()Builder와 private 생성자

인프런 워밍업 클럽 2주차 발자국

2주차 강의 정리너무 상세한 주석은 오히려 도움이 안될 수 있다의사결정 히스토리를 기록하는 주석을 작성변수와 메소드의 나열 순서패키지 변경은 팀원과 커뮤니케이션 필요Linting - Sonarlint(Spring), cmd + option + Lgit reset --hard를 적극 사용하자 -> 코드를 수동적으로 보기만 하는 것에서 벗어나야함오버 엔지니어링 -> 리팩토링은 기능은 그대로, 구조 변경을 고려은탄환은 없다 -> 적정 기술2주차 강의 회고좋았던 점IDE 사용을 더 잘 알게 되었다.새로운 과제 프로젝트에 리팩토링을 실제로 해볼 수 있었다.아쉬웠던 점생각을 코드로 옮기는 부분이 부족했다.과제 제출을 못했다.배운 점헷갈렸던 git 커밋 단위를 알게 되었다.패키지 단위와 메소드의 나열 순서에 대해 알게 되었다.앞으로 바라는 점헥사고날 아키텍처에 대해 공부해보는 것.미션 Day7고민했던 점{ HOURLY, WEEKLY, FIXED } Enum을 인터페이스 하위에 구현체로 변경해야한다고 생각하였다.고정석만 Locker를 사용할 수 있다는 개념을 어떻게 도메인 개념으로 표현할 것인지 쉽지않았다.사물함을 사용할 수 있는 PassType인지를 확인하도록 표현하는 것이 좋았다.이때 확인 로직은 PassType Enum 안에서 수행좌석과 사물함의 관계를 어떻게 볼 것인가?좌석도 상품, 사물함도 상품이므로 분리되는 도메인으로 생각하였다. -> 중복되는 부분이 많아서 하나의 인터페이스로 추상화하는 것이 좋았다.InputHandler에서 CafePass를 생성하는 것이 맞는 것인지 고민되었다.DTO를 써서 Service에서 initialize를 해야할까 고민하였다.File에서 불러오는 데이터를 처음 실행 시에 메모리에 적재를 하고 비즈니스 로직을 실행해야할까 고민하였다.비즈니스 로직에서 while문을 통해 반복하는 것이 아닌 일회성 로직이라 변경하는 것이 아닌 것 같아보였다.

인프런 워밍업 클럽 1주차 발자국

1주차 강의 정리추상과 구체이름 짓기에서 중요한점메소드의 추상화메소드 시그니처에 의미를 담는 것동일한 추상화 레벨매직 넘버 & 매직 스트링"정리 시스템에서 중요한 과제는 최소의 인지적 노력으로 최대의 정보를 제공하는 것이다." early return -> if else의미있는 단위로 depth 줄이기의미있는 공백 라인부정어 사용 지양예외 처리 & 예상 가능한 예외 및 예상 불가능한 예외객체의 설계SOLID 1주차 강의 회고좋았던 점강의 내용이 매우 유익했다.이전 프로젝트에서 놓치고 있었던 점을 다시 되돌아 볼 수 있는 기회가 되었다.코드 작성시 사고의 관점을 어떻게 해야하는가를 생각해볼 수 있었다.아쉬웠던 점스스로 계획한 일정을 지키지 못했다.배운 점설계 관점에서 필요한 부분과 코드 작성시 유의할 점 등을 새롭게 알게 되었다.프로젝트에 객체지향 설계를 적용해보면서 SOLID의 개념을 알 수 있었다.앞으로 바라는 점계획한 일정을 지키는 것.기록을 꼼꼼하게 하는 것. 미션Day 2-> 추상과 구체의 예시를 잘 설명할 수 있는 소재에 대한 고민을 했다.-> '우린다'라는 추상 안에 일어나는 자세한 과정을 구체로 표현할 수 있다고 생각. 추상: 차를 우린다.구체티백이 담긴 컵에 적절한 온도의 물을 붓는다.티백 표면으로 물이 들어가 찻잎과 접촉한다.찻잎의 성분이 물에 용해된다.용해된 찻물은 농도가 높은 티백쪽에서 농도가 낮은 물쪽으로 확산된다. Day4-> SOLID의 개념을 내가 이해한 문장들로 표현하고자 했다.-> 리팩토링 과제는 다음을 중점점으로 생각하였다.1. Early return 활용2. 부정어 사용 지양3. 의미있는 메소드 이름 짓기4. 사고의 depth를 줄이기5. 예외 처리https://lapis-dew-01f.notion.site/Day4-1147d24093d6807a86bed3f901a3322a?pvs=4 orElse() vs orElseGet() orElse()과 orElseGet()의 인자로 들어가는 값이 부하가 크다면 orElse()는 성능 문제를 일으킬 가능성이 있다.orElse()의 내부 구현은 다음과 같다.public T orElse(T other) { return value != null ? value : other; }other 값을 반환하기 위해 other 값을 항상 평가하게 된다. 내부에서 다루는 값이 평가된 값이라는 것. 예외처리 시 항상 throws를 사용해야하는가?