[인프런워밍업클럽2기] 완주 후기

드디어 인프런 워밍업 클럽 2기를 수료하였습니다. 시작할 때 만 해도 '음~ 충분하지'라고 생각 했었는데, 매일 2~3시간 분량의 강의를 듣는 것은 만만치 않았습니다. 특히 마지막 주차때에는 채용 프로세스와 동시에 진행하려다보니 과제 1개를 포기하고 말았어요. 😢이번 인프런 워밍업 클럽을 진행하면서 가장 가치있다고 느낀 순간은 동료 러너분들이었어요.정말 열심히, 성실하게 공부하시는 분들이 많다보니 뒤쳐지고 싶지 않아서, 낙오하고 싶지 않아서 이 악물고 달렸던 것 같습니다.객체지향스러운 코드를 작성하다보면 '이 한줄을 메서드로 묶는 것이 맞을까?', '이 역할이 여기에 있는게 맞나?'같은 의문들을 해소할 수 있는 소중한 시간이었습니다.강의에서도 우빈 코치님께서 언급해주시지만 디스코드 커뮤니티에서 질의응답으로 그런 궁금증을 해결할 수 있는 귀한 기회였어요.다음 워밍업 클럽은 어떤 코치님들이 어떤 강의로 진행될지 궁금하네요. 이상 후기 마치겠습니다. 😃

[인프런워밍업클럽2기] 4주차 발자국

마무리하며드디어 길고도 짧은 4주가 지나갔습니다.진행중인 채용 프로세스 일정 때문에 마지막 주차는 거의 제대로 하지 못한 점이 매우 아쉬웠습니다. 결국 마지막 과제는 제출하지 못했어요. 우빈님의 Practical Test: 실용적인 테스트 가이드 강의는 한번 더 정주행하려고 합니다.단순한 단위 테스트는 작성할 수 있지만 비즈니스 요구사항이 들어오면 어떻게 하는 것이 좋을지 고민이 많이 되어서 반복 훈련을 해봐야겠습니다.

[인프런워밍업클럽2기] DAY 15 미션

MissionLayered Architecture 의 Layer 별 특징과 테스트 방법을 정리해보세요. Layered Architecture일반적으로 계층 구조 아키텍처는 3-Layered Architecture라고 해서 Presentation, Business, Persistence 3개의 레이어로 나누는 것이 일반적이다. 최근 DDD 바람이 불면서 Domain 레이어라고 4-Layered Architecture 바람이 불고 있는데 이는 논외로 하자.Presentation Layer외부 사용자와 통신을 담당하면서 Business Layer로 요청을 전달하고, 응답을 사용자에게 반환하는 역할을 담당한다.주로 외부 요청의 유효성 검증과 각 비즈니스 작업 결과를 사용자에게 정해진 포맷으로 내려주기 위한 포매팅 작업을 한다.만약 테스트를 한다면 MockMvc를 사용한 단위테스트, 아니면 통합 테스트를 해볼 수 있을 것이다.Business Layer어플리케이션의 비즈니스 기능을 처리한다. 서비스가 제공하는 기능의 실질적인 처리를 담당하며 트랜잭션을 적용할 수 있다. 그렇기 때문에 비즈니스 레이어의 작업 단위를 관심과 책임에 맞게 적절하게 분리하는 것이 중요하다.테스트를 진행한다면 Mockito를 사용해 단위 테스트를 진행할 수도 있고, 통합 테스트로 실제 DB 에서 조회해와서 처리하는 것을 확인할 수 있을 것이다.Persistence Layer데이터베이스 같은 저장 장치와 상호작용을 하는 부분이다. DAO, Repsitory라는 이름으로 불리기도 하였다. 이 계층에서는 비즈니스 로직이 들어가지 않도록 관리를 기울여야한다. 조회해온 정보를 비즈니스 레이어에 전달해주기 위해 가공처리를 하기도 한다.테스트를 진행한다면 통합테스트를 진행한다. 영속성 계층을 단위테스트 한다면 비즈니스 레이어에 전달해주기 위한 가공처리를 테스트 할 수 있을 것이다.

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

시작하며벌써 워밍업 클럽을 시작한지 3주가 되었다. 시간이 정말 빠른 것 같다.진도 따라가랴, 과제 제출하랴 정신없게 보내다보니 하나도 밀리지 않은 나를 발견했을 때 꽤 뿌듯했다.전체 회고는 다음 발자국에서 진행하고 이번 발자국에서는 테스트 코드에 관해서 회고해보고자 한다.3주차 회고 (KPT)Keep계획표에 맞춰서 진도 밀리지 않고 잘 수강했다.과제를 밀리지 않고 제출했다.ProblemDAY 12 과제에서 run() 메서드 테스트 코드가 아쉬웠다. 어떤 방식이 맞을지 잘 모르겠다. 기존 코드를 더 잘게 쪼개야할 것 같다는 생각이 들었다.Try강의를 다 듣고 다시한번 DAY 12 과제 테스트 코드를 짜고 리팩토링을 해보자. 정리이번 강의를 들으면서 Layer 별 테스트 코드 작성에 대해서 생각해보게 되었다. 평소 Persistence layer는 테스트를 잘 하지 않았다. 왜냐면 테스트 코드를 작성하더라도 해피케이스만 작성할 것이기 때문에 의미가 있을까? 라는 생각이 들었다.영속성 레이어의 테스트 코드를 "의미 없는 테스트 코드"라고 생각했던 것인데, 실무를 하면서 영속성 테스트 코드가 도움이 되었던 적이 있었나 고민을 해봤다.Spring Boot 버전을 2.7에서 3.2로 올릴 때 hibernate 버전이 업그레이드 되면서 런타임 에러가 발생한 적이 있었다. 이를 생각하면 또 좋은 것 같기도 하다 ㅎ..

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

시작하며벌써 인프런 워밍업 클럽 2기를 시작한지 2주일이 되었습니다.제가 참여한 스터디는 하루에 2~3시간씩 들어야하는 스터디였는데요. 현재 쉬는 중이 아니었다면 완주하지 못했을 것 같습니다. 다행이도(?) 쉬는 중이라 2주차까지 완주할 수 있었네요. 강의 회고 (KPT)Keep강의를 기한 내에 다 들었다.Problem없음Try이어서 진행할 강의는 진도를 조금 더 빠르게 빼보기 과제 회고 (KPT)KeepConsole 출력 부분을 Converter로 빼서 도메인 로직과 분리Problem이용권과 사물함 이용권 도메인에 대한 고민시간을 넘겨서 다음날 코드 다시 보는 것을 하지 못함 Try다음 과제는 미리미리 화요일에 시도해보겠습니다~

[인프런워밍업클럽2기] 1주차 발자국

본 회고는 인프런 박우빈 지식공유자님의 Readable Code: 읽기 좋은 코드를 작성하는 사고법 강의를 듣고 작성된 내용입니다.총평 예상했던 것 보다 하루에 들어야하는 강의 분량이 많아서 힘들었다. 하지만 실무를 하면서 고민했던 부분들이 조금이나마 해결이 된 것에 보람을 느꼈다.그리고 영어 공부를 할 필요성을 느꼈다. Readable하기 위해서 중요한 것은 네이밍이라고 생각한다. 아무리 열심히 추상화를 하고 결합도를 낮춰도 변수와 메서드 이름이 의도를 담지 못한다면 의미가 없는 것 이라고 생각한다.이 생각을 한 이유는 강의를 보면서 지식 공유자님의 네이밍에 무릎을 탁 쳤기 때문이다. 나였다면 어떻게 했을까를 생각해보니 너무 초라했다. KPT 회고 Keep강의를 들으면서 나에게 필요했던, 내가 고민 했던 부분들을 위주로 정리해 나갔다.코드를 따라가면서 나라면 어떻게 수정 했을 지 고민하고 비교해보았다.Problem미션을 위한 정도까지만 강의를 듣고 DAY 5의 분량을 수강하지 못하였다. 한번 미루니 분량이 걷잡을 수 없이 늘어나버렸다. Try강의를 미리 들어놔야겠다.학습 내용 요약 읽기 좋은, 가독성이 좋은 코드를 짜야하는 이유는 무엇일까? 나는 코드를 읽을 때 생각없이 읽혀야한다고 생각한다. 문제 해결을 위해서 혹은 기능 수정을 위해서 기존 코드를 읽을 때 코드를 잘못 이해하게 된다면 잘 동작하던 부분에도 문제가 생길 수 있다. 그리고 우리의 개발 기간이 배로 늘어날 것이다. 어찌되었던 개발자는 회사의 제품을 잘 만들어서 그로 인해 회사에 수익을 가져다줘야하는 역할을 맡고 있기 때문이다. 개발 기간이 줄어들면 그만큼 투입되는 인건비가 줄어드는 것 일 테니까 말이다. 읽기 좋은 코드를 짜기 위해서는 아래 항목들에 신경을 써야한다.네이밍추상화Depth 그리고 공백 즉 비즈니스가 담고있는 내용을 쉽게 읽히게 해야한다.객체 지향 코드가 무조건 가독성이 좋고 어느 상황에서든 적용되어야하는 패러다임은 아니다. 상황에 따라서 절차 지향 코드가 더 적절할 때도 있을테니까.그렇지만 알고서 안쓰는거랑 모르고 안쓰는 것, 잘못알고 잘못 쓰는 것은 다르다. 강의에서는 객체 지향 패러다임에 대해서 여러 세션을 할당해서 설명하고 있다.흔히들 객체지향에서 이야기하는 SOLID, 캡추상다 같은 특징들은 구글 검색만 해도 나오니까 넘어가도록 하겠다.미션 회고이번 주차의 미션은 실생활의 행동을 추상화, 코드를 리팩토링하고 SOLID를 정의하기 였다.정의와 추상화는 어렵지 않았지만 코드 리팩토링은 약간의 고민이 필요했다.이유는 유효성 검증을 ealry return할 때, Order의 사용자가 유효한지를 Order가 검사하는 것이 맞을까? 라는 고민을 했었다.나의 결론은 Order도 User의 정보를 갖고있기 때문에 Order 레벨에서 User에 대한 검사정도는 필요하다고 판단했다. User가 null일 수도 있으니까 말이다.다음 미션은 리팩토링해보기인데 정말 기대된다. 아자아자

[인프런워밍업클럽2기] DAY 4 미션

코드 리팩토링요구사항 사용자가 생성한 '주문'이 유효한지 확인해야한다.주문 항목은 1개 이상이어야한다.주문 전체 가격은 1원 이상이어야 한다.주문한 사용자 정보는 필수 정보이다.Order는 주문 객체이고, 필요하다면 Order에 추가 메서드를 만들 수 있다.필요하다면 메서드를 추출할 수 있다.public boolean validate(Order order) { if (order.isEmpty()) { log.info("주문 항목이 없습니다."); return false; } if (order.isInvalidPrice()) { log.info("올바르지 않은 총 가격입니다."); return false; } if (order.isInvalidUser()) { log.info("사용자 정보가 없습니다."); return false; } return true; }SOLIDSingle Responsibility Principle (단일 책임 원칙)하나의 모듈은 하나에 대한 책임만을 가져야한다.클래스 내부 private 메서드가 많거나 단위테스트가 애매한 경우에는 책임을 분리하는 것을 고려할 수 있다. Open-Close Principle (개방-폐쇄 원칙)확장에 열려있고 수정엔 닫혀있어야한다.새로운 기능을 추가할 때 기존 기능에 영향 없이 추가할 수 있어야한다. 즉 서로간의 의존 관계를 최소화해야한다.이 원칙은 B기능을 추가하였는데 A기능 테스트가 깨짐으로써도 확인할 수 있다.Liskov Substitution Principle (리스코프 치환 원칙)부모 클래스의 역할을 자식이 대체할 수 있어야한다.List 인터페이스의 구현체를 LinkedList에서 ArrayList로 변경하더라도 결과가 동일해야한다.Interface Segregation Principle (인터페이스 분리 원칙)하나의 인터페이스가 많은 책임을 가지고 있다면 인터페이스를 분리해야한다.Dependency Inversion Principle (의존관계 역전 원칙)구현체를 직접 사용하는 것 보다 추상화 된 것을 바라보는 것이 확장에 용이하다.List를 사용하는 것이 ArrayList를 사용하는 것 보다 확장에 유리하다.