[워밍업 클럽 BE 2기 - 클린코드, 테스트코드] 4주차 발자국

4주차 발자국 드디어 이번 워밍업 클럽의 마지막 날입니다. 0기와 2기에 참여했었고 서로 다른 주제였는데 다음 워밍업 클럽 주제가 또 기다려지네요. 개인적으로는 코틀린을 기다리고 있습니다. 이번 주차에 포함된 진도는 아래와 같습니다.Presentation LayerMock을 마주하는 자세더 나은 테스트를 작성하기 위한 구체적 조언학습 테스트 | RestDocs가장 의미있다고 여겨졌고 개인적으로 많이 배운 주제는 Day 17의 더 나은 테스트를 작성하기 위한 구체적 조언 파트였는데요. 제가 개인적으로 실수가 많은 부분이 테스트 환경의 독립성을 보장하는 것과 테스트 간의 독립성을 보장하는 것을 놓쳤었는데요. 우빈님의 조언을 얻고 이 부분을 더 신경써서 테스트 코드를 작성할 수 있겠다는 자신감을 얻었습니다. 또 몰랐던 꿀팁을 하나 얻었었는데요! 저는 테스트 픽스처 클린징을 할 때 그냥 deleteAll을 사용했는데 deleteAllInBatch를 사용해야 하는 이유에 대해서 알 수 있어서 좋았습니다. 평소 놓쳤던 부분이었는데 좀 더 시간 효율적인 테스트를 작성할 수 있게 되었고 앞으로 사내에서 JPA 프로젝트에서 운영 소스를 작성할 때도 조금 더 신경을 쓸 수 있을 것 같습니다. 이외에도 테스트를 좀 더 효율적으로 수행할 수 있는 여러 꿀팁들을 얻을 수 있어서 좋았고요. 테스트 코드가 아직까지는 누군가에겐 귀찮은 문제, 누군가에겐 팀원들을 설득해야하는 문제로서 남아있는데 더 많은 사람들이 우빈님의 강의를 듣고 테스트 코드 작성의 필요성을 느끼고 공감했으면 좋겠습니다.

[인프런-워밍업클럽 BE 2기] Day18 과제

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다. 모두 JUnit, Spring 테스트 환경에서 사용된다. 각각의 어노테이션들은 그 목적과 사용 방식이 조금은 다르다. @Mock가짜 클래스 객체를 생성한다. 이 어노테이션에 의해 모킹된 객체는 실제 객체의 메소드 호출에 대해 빈 응답을 준다.외부 의존성을 최소화 해줄 수 있어서 단위 테스트를 작성할 때 유용하다. 실제 객체의 메소드를 호출하지 않으니당연히 실체 객체를 생성하는 것도 아니다. @MockBeanSpringBoot에서 제공하는 어노테이션이고 Spring 애플리케이션의 컨텍스트에서 관리하는 빈을 모킹한다.@Mock은 스프링 컨텍스트와 관련이 없지만 @MockBean은 스프링 컨텍스트와 관련이 있다. 특정 빈을 모킹된 객체로대체할 때 사용된다. 주로 통합 테스트에서 다른 빈과의 의존성을 모킹할 때 유용하다. @Spy스파이 객체는 실제 객체의 메소드 호출을 그대로 유지한다. 특정 메소드를 모킹할 수 있는데 일부 메소드는 실제로 호출되게하고일부 메소드는 모킹할 수 있다. @SpyBean@MockBean과 마찬가지로 스프링 애플리케이션 컨텍스트에서 관리하는 빈을 스파이한다. @InjectMocksInject라는 말에서 알 수 있듯이 의존성 주입을 도와주는 어노테이션이다. @Mock이나 @Spy를 명시한 클래스들을@InjectMocks라는 어노테이션이 달린 대상 클래스에 의존성을 주입해준다. 주로 단위테스트에서 사용된다. "@BeforeEach void setUp() { 1-1. 사용자1 생성에 필요한 내용 준비 1-2. 사용자1 생성 3-5. 사용자1의 게시물 생성에 필요한 내용 준비 3-6. 사용자1의 게시물 생성 } @DisplayName(""사용자가 댓글을 작성할 수 있다."") @Test void writeComment() { // given 1-5. 댓글 생성에 필요한 내용 준비 // when 1-6. 댓글 생성 // then 검증 } @DisplayName(""사용자가 댓글을 수정할 수 있다."") @Test void updateComment() { // given 2-5. 댓글 생성에 필요한 내용 준비 2-6. 댓글 생성 // when 2-7. 댓글 수정 // then 검증 } @DisplayName(""자신이 작성한 댓글이 아니면 수정할 수 없다."") @Test void cannotUpdateCommentWhenUserIsNotWriter() { // given 3-3. 사용자2 생성에 필요한 내용 준비 3-4. 사용자2 생성 3-7. 사용자1의 댓글 생성에 필요한 내용 준비 3-8. 사용자1의 댓글 생성 // when 3-9. 사용자2가 사용자1의 댓글 수정 시도 // then 검증 }"

[인프런 워밍업 스터디 클럽 2기] 클린코드, 테스트코드 백엔드 3주차 발자국

토요일에 백엔드 3주차 진도를 모두 진행했습니다.클린코드에 이어 테스트 코드 역시 애플리케이션 개발 과정에서 매우 중요한 과정 중 하나로 저도 생각하고 있습니다.사실 이미 이전에 전부 수강을 다 했던 강의라서 다시 이 강의에서 배운 것들 중에 적용하지 못한 것은 없는지를 중점적으로보았습니다. 이번 주차에는 레이어드 아키텍처의 큰 축인 Presentation, Service, Repository 계층 테스트 코드를 작성했습니다.강의를 다시 보면서 우빈님께서 테스트 코드의 @DisplayName을 짓는 법이나 BDD에 기반해서 테스트 과정을 잘 나누고 구분하시는 것 같다는 느낌을 다시 받았습니다. 회사에 다시 돌아갔을 때 다시 한번 고칠 부분을 찾아볼 수 있는 계기가 될 것 같습니다. 강의를 수강하면서 저를 고민에 빠지게한 것은 우빈님께서는 중간에 비즈니스 로직과 테스트 코드간에 계속해서 스위칭을 하시면서 레드-그린-리팩토링 과정을 잘 거치고 계신데, 제가 아직 TDD에 익숙하지 못한 것이 이러한 전환을 하면서 생기는 복잡함을 이겨내지 못하고 있는 것 같은데 연습이 조금 더 필요한 것 같습니다.

[워밍업 클럽 2기 BE - 클린코드&테스트] 2주차 발자국

이번 주차에는 다음과 같은 내용을 수강했습니다. 코드 다듬기클린코드 리팩토링 실습 기억하기 좋은 조언들 1주차와는 달리 스터디카페 이용권을 예시로 진행을 했는데요. 코드 다듬기코드 다듬기에서는 주석의 양면성이 가장 인상 깊었습니다. 주석은 클린 코드에서 가장 많은 논란이 있는 주제인데요. 최근에 개인적으로 느끼기에는 주석을 사용하는 걸 무조건적으로 죄악시하는 풍조가 있다고 느꼈고, 오히려 주석을 달지 않아서 문제가 생기는 경우가 많았습니다. 개인적으로 주석을 무조건적으로 지양하기보다는 과연 내가 주석이 필요 없을 정도로 남이 보기에 쉽게 이해할 수 있는 코드를 작성했는지를 먼저 스스로에게 되묻는 자세가 필요하다고 생각합니다. 결국 내가 짠 코드도 누군가가 보기에는 어려울 수도 있고 꽤나 코드의 클린함이라는게 자의적인 판단이 많이 들어갈 수 있는 영역이라고 생각하기 때문입니다. 변수나 메서드의 나열 순서 파트에서도 좋은 팁을 얻었습니다. 늘 private 메서드를 따로 빼고나서 걱정이었는데 우빈님께서 사용하시는 상태의 변경 / 판별 / 값 조회 순서를 따르면 좋을 것 같다는 생각을 했습니다. 리팩토링 연습리팩토링 실습 편에서는 지뢰찾기에서 배웠던 것들을 스터디카페 이용권을 발급하는 프로그램을 리팩토링했는데요. 우빈님께서 접근하는 방식 자체가 굉장히 좋았습니다. 처음엔 중복을 제거하는 관점에서 리팩토링을 수행하고, 일급 컬렉션을 적용할 수 있는 부분을 찾고, 객체의 책임을 분리하고, 새로운 도메인 개념을 도출해내는 단계적인 절차를 밟아가면서 리팩토링을 하는 법을 배울 수 있었습니다. 저는 이전에 이러한 명확한 관점 없이 리팩토링을 수행했던 경험이 있던지라 하나의 커밋에 너무 여러 수정과정이 섞여서 정확히 무얼 했는지 스스로도 알아보기 힘들었는데, 새로운 접근법을 얻어간다는 느낌을 받아 좋았습니다. 기억하면 좋은 조언들기억하면 좋은 조언들에서는 오버 엔지니어링을 경계하자는 챕터가 가장 인상 깊었습니다. 사실 얼마전 만든 백오피스 프로그램에서 너무 이르게 추상화한 것 때문에 오히려 새로운 기능을 구현하는 것보다 기존 코드를 고치는데 시간이 너무 많이 들었던 경험이 있습니다. 단순한 문제를 괜히 복잡하게 풀어보려는 욕심이 앞섰기 때문에 발생한 문제였는데, 구체적인 구현체들을 미리 만든다음에 그 구체들로부터 추상화할 수 있는 부분을 뽑아내어 추상화를 하는 것이 더 낫다는 것을 다시 한번 깨달았습니다. 금주에는 과제도 있었고 지뢰찾기에서 배운 것을 적용도 해보는 시간이었는데 개인적으로 코드를 작성하는 시간에 건강 이슈로 인해서 스스로 고민하고 코드를 작성하는 과정이 빈약했습니다. 그래서 과제도 사실 거의 제 생각은 없은 채로 제출했는데 좀 부끄러웠습니다. 최근에는 많이 좋아져서 다시 심신을 가다듬고 테스트 코드 주차에는 이를 만회해보도록 노력해야겠다는 생각을 했습니다.

[워밍업 클럽 2기 BE - 클린코드&테스트] 1주차 발자국

이번 주는 클린한 코드를 작성하는 방법에 대해서 쭉 배웠습니다.수강하면서 가장 느꼈던 것은 클린 코드는 단순히 '나 이렇게 코드 깔끔하게 짠다'라는 것을 자랑하기 위함이 아닌내가 아닌 함께 일하는 동료를 위한, 이타적인 행위임을 느꼈습니다. 학습 내용 요약 Day 2 - 추상과 구체추상과 구체 시간에는 다시 한번 추상화를 잘하는 것이 클린한 코드의 시작점임을 깨달았습니다.강사님께서 파블로 피카소가 한 말을 말씀하신 것이 인상 깊었는데요. 추상은 항상 구체적인 실재에서 시작해야 한다.사실 얼마전에 팀에서 개발하던 프로젝트가 지나치게 '이른' 추상화 때문에 모든 팀원이 고생한 적이 있습니다.외부 서버와 통신하는 클라이언트를 공통화 했는데, 너무 섣부른 나머지 추가적인 요구사항에 전혀 대응을 할 수없었습니다. 앞으로 나올 구체적인 실재들을 간과한 추상화가 문제였기 때문입니다. 최근의 경험과 더불어서저 문장을 보고 구체와 추상간의 Context Switching을 잘 해야겠다고 생각이 들었습니다. Day 3 - 논리, 사고의 흐름 | 객체 지향 패러다임Day 3의 주제들은 사실 미리 알고 있었던 내용입니다. 저도 입사하고나서 다른 팀원들에게 적극적으로권유하고 있는 방법입니다. 논리, 사고의 흐름이라는 섹션은 딱 하나의 주제를 관통합니다."읽는 사람으로 하여금 덜 고생하게 하자"우리의 뇌를 메모리에 비유하여 읽는 사람으로 하여금 이 자원을 덜 쓰도록 하는 것이 좋은 코드라는 가르침을얻었고 Early Return이나 Depth 줄이기(else 지양), 공백에 의미 부여하기, 부정어를 가급적이면 사용하지 않기처럼 실제로 글쓰기나 말하기에서도 중요한 것들을 코드에 녹이는 방법을 배웠습니다. Day 4 - SOLIDDay 4는 객체 지향의 Core라고 할 수 있는 SOLID입니다. 지뢰찾기 게임을 이 원칙에 맞춰서 리팩토링 해나아갔는데요. 제가 이해한 SOLID는 서로 많이 연관되어 있습니다. 하나의 톱니바퀴 여러개를 맞물려야하는 느낌이었는데요. 이 원칙을 지키는데에 있어서 가장 중요한 것은 도메인 지식을 잘 이해하고 있는 것이 중요하다고 생각합니다. 그래야 필요한 인터페이스는 뭐가 있고 그 인터페이스의 명세는 어떻게 되어야 하며, 객체 간 책임분리를 통한 올바른 설계를 완성할 수 있는 것 같습니다. 개인적으로 단순히 기획서의 디스크립션만 보고 급급하게기능을 개발했던 지난 날을 반성하게 되었습니다. Day 5 - 객체 지향 적용하기Day 5에서 배운 것들 중에서는 상속과 조합, 일급 컬렉션이 가장 기억에 남았습니다. 사실 상속보다는 조합을지향하라는 문구를 본 적은 있는데 실제로 적용을 해본 적은 없었거든요. 이번에 좋은 레퍼런스를 얻었고단순한 상속보다는 약간은 더 복잡하고 코드 양이 늘어나지만 변경에 유연한 조합을 추후에 사내 프로젝트에서적용해보고 싶다는 생각이 들었습니다. 또한 일급 컬렉션의 효용성과 불변성에 대해서 다시 중요성을 깨달았습니다. 개인적으로 칭찬하는 점은 강의를 들으면서 알고 있는 내용도 있었고 몰랐던 내용도 있었는데요.알고 있는 내용에 대해서 강의를 들을 땐 '이렇게 소스 코드를 정리하실 거 같은데?' 라는 생각이 들때쯤제 예상이 맞았던 적이 많았습니다. 이전에 배웠던 것들을 그래도 잘 머릿속에 담아두고 있구나 라는 생각이들었구요. 아쉬웠던 점은 강의에서 배웠던 점들을 적용시키는데 있어서 그 적용 범위를 확장하지 못하고 있는 것 같습니다. 아무래도 경험 부족이 원인인 것 같은데 이 부분은 시간이 해결해주리라 믿고 있겠습니다 ㅠㅠ 발자국 끝!

[워밍업 클럽 2기 BE 클린코드 & 테스트코드] BE 2기

첫 번째 미션 : 아래 코드를 읽기 좋은 코드로 변경하기아래의 코드는 물론 기능 구현상에서 오작동을 일으키는 코드는 아니겠지만 이번 섹션에서 배운 내용을 토대로 읽는 사람으로하여금 과부하까진 아니더라도 부하를 겪을 수 있습니다. 아래의 코드는 그럼 어떤 문제를 가지고 있을까요?public boolean validateOrder(Order order) { if (order.getItems().size() == 0) { log.info("주문 항목이 없습니다."); return false; } else { if (order.getTotalPrice() > 0) { if (!order.hasCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } else { return true; } } else if (!(order.getTotalPrice() > 0)) { log.info("올바르지 않은 총 가격입니다."); return false; } } return true; }첫 번째는 캡슐화가 잘 지켜지지 않고 있습니다. 객체의 값을 지속적으로 getter 메서드를 가져오면서 확인하고 있습니다.이는 TDA(Tell, Don't Ask) 원칙을 지켜지지 않고 있고 객체가 그 자체의 역할을 하게끔 만들지 않았습니다. 두 번째는 읽는 사람으로 하여금 머리를 많이 쓰게 하고 있습니다. 머리를 많이 쓰게 한다는 것은 다음과 같은 이유에서 입니다.모든 조건문이 한 호흡에 이어져 있다.공백으로 각 작업간의 STEP을 구분하지 않았다.Depth가 깊다.부정 연산자 사용으로 인해서 조건을 한 번 더 이해해야 한다.이를 리팩토링 한다면 어떻게 할 수 있을까요? public boolean validateOrder(Order order) { // 주문 항목 확인 if (order.hasNoItems()) { log.info("주문 항목이 없습니다."); return false; } // 총 가격 확인 if (order.isTotalPriceInvalid()) { log.info("올바르지 않은 총 가격입니다."); return false; } // 사용자 정보 확인 if (!order.hasCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } return true; } 리팩토링한 코드는 위와 같습니다. Order 객체 스스로 판단할 수 있는 메서드로 조건문을 처리하여 TDA 원칙을 따랐습니다.공백을 둚으로서 각 작업의 STEP을 구분했습니다.3-Depth 까지 타고 들어가야하는 코드를 전부 1-Depth 이내에 처리했습니다.부정 연산자를 사용하기보단 더 의미있는 이름의 메소드를 만들어 직관적으로 조건문을 판단할 수 있도록 했습니다.과제를 수행하면서 느꼈던 것은 좋은 코드란 좋은 글을 작성하는 것과 마찬가지라는 느낌이었습니다. 좋은 글을 쓰는 첫 출발점은 단문 쓰기를 통해 호흡을 짧게하여 읽는 사람으로 하여금 부하를 느끼지 않게 하는 것이 중요했습니다. 문장의 마침표가 문장의 시작으로부터 너무 멀리 있게되면 이는 읽는 사람을 배려하지 않은 글쓰기이기 때문입니다. 클린 코드는 나만의 만족을 위한 것이 아니라 이타적인 마음을 다시 한번 갖게 되는 좋은 원칙인 것 같습니다. 두 번째 미션 : SOLID를 자신의 언어로 정리하기 SRP : Single Responsibility Principle단일 책임 원칙은 클래스 혹은 메서드, 함수는 한 가지 책임만 가져야 한다는 것입니다. 자동차를 예로 들어볼까요? 자동차 클래스를 작성한다면, 우리는 이 원칙을 지키기 위해 엔진, 연료, 네비게이션, 에어컨 조절, 음악 재생과 관련된 변수와 메서드를 전부 넣어놓으면 안됩니다. 자동차는 그저 여러 가지 요소의 조립이 끝난 채로 존재해야합니다. 그래서 우리는 엔진, 연료 시스템, 네비게이션, 오디오 클래스를 별도로 분리하고 그에 맞는 기능들을 작성해야 합니다. OCP - Open/Closed PrincipleOCP는 소프트웨어는 구성에 있어서 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다는 원칙입니다. 솔직히 많은 사람들이 이 이야기를 처음에 들었을 때 의구심을 품습니다. '어떻게 확장을 하는데 수정을 안할 수가 있어?' 라고요. 하지만 적어도 소프트웨어 세상에서는 가능합니다. 앞서 말했던 SRP를 지킨다면 말이죠. 만약 자동차 클래스에 오디오 관련 기능들을 전부 다 작성했다면 어떻게 되었을까요? 우리의 자동차에는 보스의 것도, 뱅앤올룹슨의 것도, 하만 카돈의 것도 들어갈 수 있습니다. 하지만 자동차 클래스에 오디오 관련 코드를 전부 작성했다면 자동차 클래스는 늘어나는 오디오 업체의 코드를 계속해서 생산해내야 합니다. 그러나 이전에 별도의 객체로 만들고 추상화까지 더했다면? 확장에 있어서 기존 코드를 수정하는 일은 없을 것이고 우리는 단순히 '추가'만 하면 될 것입니다. LSP - Liskov Substitution Principle리스코프 치환 원칙은 자식이 언제든지 부모를 대체할 수 있어야 한다는 원칙입니다. 다시 차량의 오디오 기능을 생각해봅시다. 오디오 인터페이스가 있고 오디오 인터페이스에 명세되어 있는 기능은 볼륨 켜키, 볼륨 끄기 입니다. 하지만 어느 한 회사의 특정 제품 클래스는 볼륨 켜키 기능이나 볼륨 끄기 기능이 기대한대로 동작하지 않는다면 어떻게 될까요? 예를 들어서 볼륨 끄기를 1씩 끄는게 아니라 한번에 0으로 만들어버린다거나 말이죠. 이렇게 되면 프로그램이 균일하게 동작하지 않을 것이고 서로가 서로를 완벽하게 대체할 수 없을 것입니다. 따라서 인터페이스를 준수하는 것이 LSP가 전달하고자 하는 메세지입니다. ISP - Interface Segregation PrincipleISP는 클라이언트가 사용하지 않는 인터페이스에 의존하지 않도록 하는 것입니다. 모든 자동차들은 구매할 때 고객이 원하는 옵션을 가지고 있습니다. 하지만 내 자동차에 내가 고르지 않은 옵션을 동작하는 버튼이 자리만 차지하고 있다면 어떻게 될까요? 이는 운전자에게 혼동을 줄 수 있고 불필요한 공간 낭비를 발생시킬 수 있습니다. 코드에서는 어떤가요? 특정 클래스가 구현하지 않아도 되는 부분을 구현해야할 것처럼 개발자에게 혼동을 줄 수 있고 이는 장애를 유발하거나 불필요한 용량 차지로 이어질 수 있습니다. 인터페이스는 가능한 범용적이 아닌 세부적으로 분리해야한다는 것이 ISP가 전하고자 하는 메세지입니다. DIP - Dependency Inversion PrincipleDIP는 고수준 모듈은 저수준 모듈에 의존해서는 안되고, 고수준 모듈과 저수준 모듈 모두 추상화에 의존해야 한다는 원칙입니다.이 역시 말이 어렵습니다. 저도 처음에 OCP 다음으로 어려웠던 것 같습니다. 하지만 위에서 자동차 예시로 다 말씀을 드렸습니다.자동차 클래스는 여러 인터페이스의 조합으로 이뤄져야 한다고 했습니다. 자동차 클래스는 가솔링 엔진, 전기 엔진과 같은 구체 클래스에 의존해서는 안됩니다. Engine 인터페이스가 있고 이를 구현한 가솔린 엔진과 전기 엔진이 있어야 합니다. 오디오 역시 오디오라는 인터페이스만 있을 뿐, 이를 구현한 각 제조사의 오디오가 있을 뿐이죠. 자동차 클래스는 따라서 어떤 특정 엔진이나 특정 오디오의 정보는 알 수 없습니다. 그저 인터페이스만 갖고 있을 뿐입니다.

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

이번 3주차에는 3단계 까지 수행한 내용을 적어보고 프로젝트를 수행하면서 든 생각 등을 적어보겠습니다.전체 코드는 아래의 깃허브 주소에서 확인하실 수 있습니다.https://github.com/wisehero/warming-up_mini-project/tree/master/src/main/java/com/example/warmingup_miniproject 문제 1. 팀 등록 기능 / 직원 등록 기능 / 팀 조회 기능 문제 1번은 그다지 어렵지 않았습니다. 아래 팀과 직원이라는 1:N 관계를 모델링해주고 기능을 작성하면 됩니다. 팀 등록 기능의 경우엔 동일한 팀이름이 존재할 수는 없으므로 서비스 로직에 다음과 같은 로직만 추가해주었습니다.직원 등록 기능의 경우엔 한 가지 예외만 처리해주었습니다. 보통 팀(혹은 부서)에는 Manager의 역할을 하는 팀장이 1명입니다. 물론 예외도 있습니다만 여기서는 팀에 팀장은 한 명만 존재한다고 가정하고 다음과 같이 로직을 완성했습니다.우선 등록하려는 팀이 있는 팀인지 확인한다. 존재하지 않으면 관련 예외를 던진다.팀이 존재한다면, 역할이 Manager로 정해지지 않았는지 확인한다. 이미 해당 팀에 매니저가 있는 경우, 이미 팀장이 존재한다는 예외를 던진다.위 두 가지 케이스를 통과했다면 팀을 할당하고 저장팀 정보 조회는 아래와 같이 작성했습니다. 그저 조회 메소드이니 특별한 것은 없습니다.다만, 응답 DTO에 필드가 늘어난다면 map()에 파라미터로 전달되는 부분을 축소할 필요가 있어보이는데 이 부분은 리팩토링 해야할 부분으로 남겨두었습니다. 아래는 각 기능을 수행했을 때 정상적으로 작동하는 것을 보여주는 스크린샷입니다. 문제 2. 출근 기능 / 퇴근 기능 / 특정 직원의 날짜별 근무 기간을 조회하는 기능 이 기능들은 다음과 같은 엣지 케이스가 있을 수 있습니다.등록되지 않은 직원이 출근하려는 경우출근한 직원이 또 다시 출근하려는 경우퇴근하려는 직원이 출근하지 않았던 경우그 날, 출근했다 퇴근한 직원이 다시 출근하려는 경우저는 이 출근, 퇴근이라는 기능에서 날짜를 정하는 부분을 내부적으로 LocalDate.now()로 잡았는데요. 두 번째, 세 번째 케이스의 경우 오늘 날짜에 출근을 이미했거나 퇴근을 시도할 때 '오늘' 출근한 기록이 없으면 퇴근이 기록될 수 없게 했습니다. 물론 출근 기능에 문제가 생길 수 있으나, 논리적으로 출근을 하지 않았으니 당연히 퇴근 기록이 남는 것도 말이 안된다고 봤습니다. 또한 저는 오늘 근무한 시간을 퇴근을 기록하면서 출근시간과 퇴근시간의 차이를 구해 기록하는 식으로 남겼기 때문에 퇴근 날짜만 남겼을 경우 엉뚱한 값이 기록될 수 있어 이렇게 정했습니다. 가장 고민이 되었던 것은 4번째였는데요. 저는 이미 당일날 출근을 했으면 다시 출근이 기록될 수 없게 했기 때문에 만약 하루에 출-퇴근을 2번 찍었다면 2개의 행이 들어갈 수가 없게되었습니다. 그래서 우선은 임시방편으로 퇴근시간을 null로 바꾸었는데요. 이렇게 되면 하루 총 근무 시간이 초과 근무 시간을 넘게되는 일이 발생할 수 있는데 이 문제를 해결할 다른 정책?을 고민해봐야겠습니다. 문제 2번의 전체 코드는 아래와 같습니다.@Service @RequiredArgsConstructor @Transactional(readOnly = true) public class AttendanceService { private final AttendanceRepository attendanceRepository; private final EmployeeRepository employeeRepository; private final DayOffRepository dayOffRepository; @Transactional public void recordGoToWorkTime(Long employeeId) { // 등록되지 않은 직원이 출근할 수 없다. Employee employee = employeeRepository.findById(employeeId).orElseThrow(EmployeeDoesNotExistException::new); LocalDate today = LocalDate.now(); Optional attendedEmployee = attendanceRepository.findAttendedEmployee(employee.getId(), today); // 연차를 이미 사용한 날짜엔 출근을 기록할 수 없다. if (dayOffRepository.existsByEmployeeIdAndDayOffDate(employee.getId(), today)) { throw new AttendanceTodayIsDayOffException(); } if (attendedEmployee.isPresent()) { Attendance attendance = attendedEmployee.get(); // 당일 출근과 퇴근이 모두 기록되었다면 퇴근 시간을 null로 업데이트 if (attendance.getGetOffWorkTime() != null) { attendance.recordGetOffWorkTime(null); return; } // 이미 당일날 출근을 등록한 경우 예외 발생 throw new AttendanceAlreadyArrivedException(); } attendanceRepository.save(new Attendance(employee)); } @Transactional public void recordGetOffWorkTime(Long employeeId) { // 퇴근하려는 직원이 당일 출근하지 않았을 경우엔 ERR Attendance attendance = attendanceRepository.findAttendedEmployee( employeeId, LocalDate.now()).orElseThrow(AttendanceGetOffNotAvailableException::new); attendance.recordGetOffWorkTime(LocalDateTime.now()); attendance.recordWorkingMinutes(); } public ResponseAttendanceInfoByEmployee getAttendanceInfoByEmployee(Long employeeId, YearMonth date) { Employee findEmployee = employeeRepository.findById(employeeId).orElseThrow(EmployeeDoesNotExistException::new); LocalDate startOfMonth = date.atDay(1); LocalDate endOfMonth = date.atEndOfMonth(); List attendanceInfo = attendanceRepository.findAttendanceByEmployeeId(findEmployee.getId(), startOfMonth, endOfMonth); List dayOffTaken = dayOffRepository.findDayOffTakenByEmployeeAndMonth( findEmployee.getId(), startOfMonth, endOfMonth); List details = attendanceInfo.stream() .map(attendance -> new AttendanceDetail(attendance.getGetOffWorkTime().toLocalDate(), attendance.getWorkingMinutes(), false)) .collect(Collectors.toList()); // 연차 정보도 AttendanceDetail 형태로 변환하여 details 리스트에 추가 List dayOffDetails = dayOffTaken.stream() .map(dayOff -> new AttendanceDetail(dayOff.getDayOffDate(), 0L, true)) .toList(); details.addAll(dayOffDetails); details.sort(Comparator.comparing(AttendanceDetail::date)); Long sum = details.stream().mapToLong(AttendanceDetail::workingMinutes) .sum(); return new ResponseAttendanceInfoByEmployee(details, sum); } } 문제 3. 연차 신청 / 연차 조회 / 특정 직원의 날짜별 근무 시간 조회 여기서는 연차와 관련된 정보를 따로 관리하는 엔티티를 만들었는데요. 지금 생각해보면 조금 아쉬웠던? 결정이었습니다. 왜냐하면 근태관리 시스템에선 보통 연차/반차/조퇴/초과근무/정상출퇴근을 함께 관리하고 있는데 Attedance에 이를 구분하는 코드를 삽입하는 속성을 추가해서 함께 관리했으면 연차를 위한 엔티티를 따로 만들 필요가 없었던 것입니다. 근태라는것의 유형을 분류해서 로직을 구성했으면 오히려 좀 더 응집도가 있었을 수 있었는데 저는 그렇게 하지 못했습니다. 그래서 위에 보시면 직원의 근태정보를 가져오는 부분에서 레포지토리를 세개나 주입을 받고 있습니다. 이 부분은 추후에 한 번 개선을 해볼만한 지점입니다. 연차를 신청할 때는 다음의 예외를 다뤄줘야 했는데요. 연차 사용 횟수가 없는 경우엔 연차를 신청할 수가 없다.연차 사용일 - 연차 신청일이 팀에서 정한 기한보다 작은 경우엔 연차를 신청할 수 없다.이미 연차를 신청한 날짜에 또 다시 연차를 신청할 수 없다.연차를 사용한 날에는 출근이 기록될 수 없도록 출근 기능에서도 예외 핸들링을 해줘야 한다.따라서 연차 신청은 다음과 같은 코드로 수행했습니다.여러 케이스를 다루다보니, 코드가 좀 길어졌는데 따로 연차 신청이 유효한지 판단하는 private 메서드를 만들어서 빼주도록 리팩토링하는 시간을 가져봐야겠습니다. 남은 연차를 조회하는 경우에는 이 Employee에 dayOffRemains라는 정수 필드를 추가했습니다. 그래서 연차 사용이 정상적으로 마무리 되었으면 subtractDayOffRemain()이라는 함수를 호출해서 연차 사용 횟수를 1회 깎아주는 방식을 채택했습니다. 연차 정보까지 포함한 근태정보를 가져오는 로직에서는 고민을 좀 많이 했는데요. 로직을 보시면보시면 로직이 굉장히 깁니다. 정상 출퇴근 정보를 갖고 있는 Attedance 테이블에서 조회를 해오고, 연차정보를 조회해오고, 이를 다시 날짜순으로 정렬을 해주고, 근무 시간의 총합을 구하는 스트림을 돌고 있습니다. 연산을 굉장히 많이하게 되는데요. 사실 더 좋은 방법이 없을까..? 쿼리로 한 번에 가져올 수는 없을까? 생각을 했는데 처음에 든 생각은, '음... 겨우 한 달짜리만 가져오는 거잖아?" 네 사실 조회하는 데이터나... 연산의 대상이되는 데이터의 크기가 크지 않습니다. 근데 또... 기간이 6개월이라면? 1년이라면...? 이라는 생각이 들기는 하는데 그래도 많은 양인가? 엄청난 통계성 데이터일만큼? 이라는 생각이 들어서 로직을 분리하는 것외에는 더이상의 리팩토링을 할 필요가 있을까 싶기도 하고... 또 로직이 단순해지려면 위에서 말했던 것처럼 그냥 연차를 Attendance에서 한번에 관리하는 것이 더 좋겠다는 생각이 들었습니다. 시간 관계상 프로젝트는 3단계까지 했지만 4단계까지 쭉 해볼 생각입니다. 이번 프로젝트를 하면서 변경에 유연한 설계를 할 수 있는지에 대한 시험대에 오른 것 같다는 생각이 들었습니다. 계속해서 리팩토링 해보고 더 많은 기능을 추가해보면서 실력을 갈고 닦아야겠습니다. 이런 좋은 과제를 준비해주신 태현 코치님에게 감사드립니다.

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

2주차는 좀 많이 아쉬운 주였습니다. 몸이 아파서 학습에 온전히 시간을 쓰지 못했고, 연휴에도 골골대면서 누워있던 시간이 많았습니다. 그래도 중간중간 기운이 좀 나거나 상태가 괜찮아지면 다시 책상에 앉아 코드를 작성했는데요. 미니 프로젝트는 Java 21, 스프링부트 3버전을 사용하고 있습니다. Java 버전을 21로 선택한 이유는 추후 태현님께서 Java 21과 관련된 강의를 출시할 것이라고 예고를 해주셨고 후에 Java 21을 적용할 수 있는 부분을 찾아 연습을 해보기 위해 선택했습니다. 종종 인텔리제이로 코딩을 하면서, Java 최신 기능을 적용할 수 있는 부분은 ToolTip으로 알려주었던 것 같은데, 아직까진 이러한 부분을 찾질 못했습니다. 이번 미니 프로젝트를 진행하면서 새롭게 시도한 부분은 record를 좀 더 적극적으로 사용하는 것이었습니다. 레코드를 사용하게 되면 기존의 DTO 클래스를 작성하는 것보다 좀 더 간결하게 DTO의 목적 자체에 맞는 코드를 작성할 수 있고 롬복과 관련된 애노테이션들을 사용할 필요가 없다는 점이 큰 장점으로 다가왔습니다. 프로젝트는 현재 1단계는 다 완성이 되었고 2단계를 수행하고 있습니다. 한 걸음 더!에 나와있는 edge-case들을 다루는 내용을 해결하는 과정에서 큰 재미를 느끼고 있습니다. 실제 개발에서도 이러한 부분을 사전에 얼마나 잡아내느냐에 따라 제품의 퀄리티와도 직결될 것 같은데, 이런 케이스들을 사전에 고안해내고 핸들링하는 부분에 있어서 경쟁력을 가지고 싶다고 생각이 들었습니다. 현재는 코드리뷰어를 구하지 못해서 GPT에게 코드 리뷰를 대신 부탁해주고 있는 실정인데, 초기에 매우 지저분했던 서비스 레이어가 그래도 나름 깔끔해졌습니다. 물론 여전히 레포지토리에 선언한 쿼리메서드의 메서드명이 좀 긴 것은 고쳐야할 부분입니다. isAttendToday의 경우는 그래도 나름 빨리 적절한 메서드명을 떠올렸는데 퇴근 시간을 기록하는 메서드의 경우는 잘 떠오르지 않아 냅둔 상태네요. 현재 이 부분에서 이미 같은 날의 출근과 퇴근을 모두 마친 직원이 다시 출근을 하려고하는 경우를 핸들링 해야하는데 좋은 방법이 없을 지 생각 중입니다. 미니 프로젝트에서 남은 과제들을 보면, 변경에 유연하게 대처할 수 있는 코드를 작성할 수있고, 설계를 할 수 있는지에 대한 역량을 시험할 수 있는 것 같습니다. 그래서 엔티티에 필드하나를 추가하거나, 코드 한 줄, 한 줄에도 근거를 담아보려고 노력하고 있습니다. 3단계와 4단계가 정말 그 시험대가 될 것 같아요. 부디 다음 주 한주는 최상의 컨디션으로 과제와 강의 모두 잘 병행할 수 있기를 바랍니다.

[워밍업 클럽 BE-0기] 7일차 과제 - JPA로의 전환, 그리고 더 다양한 API 만들

7일차 과제는 기존의 프로젝트를 JPA로 전환하고, 더 다양한 API를 만드는 것입니다.저는 이미 과제를 처음부터 JPA로 진행하고 있었으므로, 해당 부분을 생략하고 문제를 바로 보겠습니다. 첫 번째 문제는 다음의 스펙에 맞추어 API를 만드는 것입니다.HTTP method : GETHTTP path : /api/v1/fruit/countHTTP query : name -> 과일 이름HTTP 응답 Body 예시{ "count" : long } 코드는 다음과 같습니다!FruitControllerFruitServiceFruitRepository이름을 파라미터로 넘겨주면 그 이름과 일치하는 과일 엔티티들의 갯수를 반환하도록 했고요. 아래와 같이 요청을 보냈습니다.그리고 현재 제가 만든 Fruit 테이블의 상태는 아래와 같습니다. 사과가 3개 있으니 3개를 가져와야할 것입니다.정상적으로 3개가 출력되는 것을 확인할 수 있었습니다. 다음 문제는 팔리지 않은 과일들 중에서 특정 금액 이상, 혹은 특정 금액 이하의 과일 목록을 받아오는 것입니다.스펙은 아래와 같습니다HTTP method : GETHTTP path : /api/v1/fruit/listHTTP queryoption : "GTE" 혹은 "LTE"라는 문자열이 들어온다.GTE는 크거나 같다는 의미LTE는 작거나 같다는 의미price : 기준이 되는 금액이 들어온다.응답 Body 예시[{ "name" : String, "price" : long, "warehousingDate" : LocalDate, }, ... ] 저는 아래와 같이 코드를 작성했습니다.FruitControllerFruitServiceFruitRepository그리고 요청을 보내보았습니다.정상 작동을 확인했습니다.다만 아쉬운 점이 서비스레이어에서 엔티티를 DTO로 변환을 하는 과정인데.. 이것을 그냥 레포지토리에서 DTO로 조회를 하는 방식이 더 나을 것 같다는 생각이 들었습니다. 하지만 이렇게 되면 쿼리 애노테이션을 달아주어 SQL을 작성해줘야하는데 레포지토리에 있는 코드들이 길어질 것 같았습니다. 어떤 방식이 더 선호되는 지는 공부를 해보고 개선해봐야겠습니다. 저 변환을 하는 작업이, 필드가 늘면 늘수록 중간 연산의 코드가 점점 더 길어지게 되는 단점이 있다고 생각이 들었거든요. 그럼 오늘도 봐주셔서 감사드리고 모든 워밍업 클러버들의 무운을 빕니다.

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

사실 강의 수강은 워밍업 클럽이 열리기 전부터 듣고 있었어요. 이미 JPA로 전환하는 부분까지 다 넘어갔었습니다. 사실 이것때문에 30% 할인 쿠폰을 미리 받지 못한 것에 대해서는 조금 아쉽긴 했습니다 ㅋㅋㅋ. 강의를 수강하게 된 이유는 저는 국비교육을 수료한 이후로 다른 정량적 스펙이나 코딩테스트, 자기소개서에 시간을 너무 많이 쓰게 되었고 중간에 인턴이나 현재 재직중인 직장에서는 스프링 부트나 스프링 5이상 버전, JDK 11~21 버전을 사용하지 않는 환경에 있었어요. 그래서 최근 개발 트렌드나 버전에 따른 변화에 뒤쳐지지 않기 위해 강의를 수강하기 시작했습니다. 1주차 동안은 주로 강의를 다시 듣는 것은 아니었고 이미 들었던 강의, 강의를 들으면서 작성했던 코드들을 다시 한번 보게 되었어요. 이 과정에서 JPA를 주로 사용하는 바람에 JdbcTemplate을 잘 사용해본 적이 없어서 이에 다시 적응하는 시간이 되어서 좋았습니다. 그리고 정말 레이어드 아키텍처에 따른 모든 코드들을 오랜만에 작성하면서 예전에 국비 교육때 열심히 했던 시간들을 다시 한번 되새길 수 있었고, 취업 준비를 하면서 많이 꺾였던 마음을 다시 세울 이유와 동기를 얻는 과정이어서 좋았습니다. 아쉬웠던 점은 시간이 그렇게 많지 않아, 과제 수행 중에 발견한 문제점이나 궁금했던 점에 대해 따로 깊이 파볼 시간이 조금 부족했던 것이 있습니다. 아무래도 2월부터 회사에 다니게 되었고 이 루틴이 익숙치 않아 오는 문제점인것 같은데 어떻게든 해결책을 마련해서 극복해야겠습니다. 워밍업 클럽을 진행하면서, 혹은 강의를 수강하면서 스스로에게 그나마 좋았다고 말해줄 수 있는 점은 질문을 적극적으로 하는 자세였습니다. 아마도 태현님 강의에서 질문을 제일 많이 한 것 같아요. 그리고 그 질문들중 좋은 질문이라고 반응해주셔서 행복했고, 태현님이 제 질문에 답변을 주신 것을 다른 분들의 질문에 대한 답변으로 대신하시는 것을 보고 '내가 의미있는 질문을 했구나'하는 생각을 했습니다. 세상에 멍청한 질문은 없다지만, 그 질문들 가운데서도 핵심을 짚는, 가치가 높은 질문들은 있다고 생각을 하는데 그런 질문을 하는 사람이 되어간다는 느낌을 받았습니다. 앞으로도 그런 질문을 계속 던질 수 있는 개발자가 되어야겠다고 다짐했던 좋은 경험이었습니다. 미션 수행과 관련해서...미션 수행은 저 말고도 다른 분들도 크게 어렵지 않게 해결하셨을거 같아요. 다만 저의 경우엔 몇 가지 아쉬운점이 있었어요. 어노테이션 관련해서 딥다이브를 하는 과정에서 과연 '딥'하게 들어갔는지에 대해는 의문이었어요. 다른 분들은 어노테이션이 '마법'을 일으키는 과정을 따라들어가보면 '리플렉션'이라는 개념이 등장하는데 제가 이 리플렉션 코드를 직접 짜보거나 하지는 않았거든요. 반성해야할 지점이었습니다. 단순히 개념적인 것, 글만 읽고 끝내는 공부를 또 반복하게 된듯한 느낌이었거든요. 나머지 미션들이 크게.. 특별히 어려웠던 점은 없었는데 코치님께서 남겨주신 4일차 과제 피드백을 듣고 다음에 비슷한 동작을 수행하는 코드를 작성할 때 더 좋은 코드를 작성할 수 있는 법을 배웠어요. 코치님이 남기신 피드백 내용은 다음과 같습니다.제가 이 피드백에서 교훈을 얻은 이유는 코치님이 언급하신, 데이터베이스에서 데이터를 전달해주고, 서버에서 연산 작업을 처리하게 되어 네트워크 대역폭 증가와 서버 자원 사용량의 증가라는 효과를 불러일으키는 방식으로 코드를 작성했기 때문이에요. 그렇다면 왜 그런 코드를 작성했을까요?사실 그냥 이 과제가 SQL 문제로 주어졌다면, 저는 아무런 고민없이 데이터베이스에서 바로 연산을 하는 SQL문을 바로 짤 수 있었을 거에요. 하지만 서버 애플리케이션 프로그래밍을 배우면서 이런 얘기를 들었어요. '데이터베이스에서 비즈니스 로직을 처리하게 되면 DB 종속적으로 프로그래밍을 하게 되어 서버 애플리케이션의 존재 의미가 흐릿해진다.'실제로도 현재 근무하고 있는 회사에서는 비즈니스 로직이 오라클 데이터베이스의 프로시져에 몽땅 때려박혀있는 구조이고 저는 이것을 지금 개선하고 있기 때문에 DB라는 것에서 어떤 처리를 최소한으로 하려고 하는 습관이 생겼어요. 그리고 여기에 더해 강의를 통해 자바 스트림을 적극적으로 사용하는 것을 보고, 스트림 처리를 적극적으로 사용하는 것이 간결하고 명확하며 멋져보여서 이를 적극적으로 사용하는 것이 머리 속을 지배했습니다.하지만 저는 과제의 요구사항이 '통계성 데이터를 반환하는 것'이라는 것을 잊고 있었고 이에 따른 트레이드 오프를 고민하는 자세를 갖지 못하고 바로 서버에서 스트림으로 연산을 처리해야겠다는 사고에 지배를 당해 아래와 같이 코드를 작성했습니다.@Transactional(readOnly = true) public List fruitStat(String name) { fruitRepository.findFruitsByName(name); List findFruits = fruitRepository.findFruitsByName(name); if (findFruits.size() == 0) { throw new IllegalArgumentException("해당 이름을 갖고 있는 과일이 없습니다."); } Long salesAmount = findFruits.stream().filter(Fruit::getSold).mapToLong(Fruit::getPrice).sum(); Long notSalesAmount = findFruits.stream().filter(fruit -> !fruit.getSold()).mapToLong(Fruit::getPrice).sum(); return List.of(salesAmount, notSalesAmount); } 이름 하나를 넘겨받고 그 이름과 동일한 이름을 가진 과일을 모두 가져오고, 팔린 물건과 그렇지 않은 물건을 따로따로 계산해주고 있습니다. 하지만 저 코드는 Fruit 테이블에 엄청나게 많은 데이터가 있었다면, 합을 구하는데 오랜 시간이 걸릴 수 있음이 분명했습니다. 통계성 데이터 처리는 그냥 한꺼번에 디비에서 해서 넘겨주는 것이 더 컴퓨팅 자원을 덜 소모할 수 있는 방법이라는 것을 분명 공부했지만 하나의 문제를 해결할 수 있는 방법을 여러개 놓고 그 중에 고른다기보다 저는 기존에 배웠던 것을 새로 배운 것으로 덮어쓰기 해버리는 바람에 트레이드 오프를 고려하는 습관을 유지하지 못한 부끄러움이 있었습니다. 그래서 우선 오늘은 자고 내일 개선해보자라고 생각했으나 마침 6일차 과제에 JPA가 아닌 JdbcTemplate을 사용할 것을 가정하고 나온 과제 내용을 다시 보고 개선할 수 있는 기회를 얻었습니다. 그래서 작성한 코드는 아래와 같습니다.동일한 작업을 모두 SQL로 작성하고 이를 DB에서 처리하게 했습니다. 이렇게 하고 단순히 응답을 맵으로 감싸서 넘기는 방식을 취하고 있죠. 만약 통계 결과를 얻기 위한 데이터가 엄청 많다면 이러한 방식이 더 효율적일 것 같습니다. 다음엔 좀 더 많은 임의의 데이터를 넣고 코드를 시험해봐야겠습니다. 감사합니다.