인프런 워밍업 클럽 백엔드- devops 4주차 발자국

미션 https://dev-gongmyoung.tistory.com/62컨테이너 관련 기술은 도커만 알고 있었는데 이번 강의들을 들으며 containerd에 대해서도 알게 되었다. 이번 미션을 진행하며 미션에서 설명한 상황이 일어날 수 있음을 알게 되었다. 또 containerd에도 도커와 같이 같은 일들을 하는 명령어들이 있음을 알게 되었다. 이렇듯 다양한 기술들이 있는데 본질을 정확히 알고 있다면 명령어를 찾아서 사용하는 것을 어렵지 않을 것이라고 생각했다. 강의 수강이제 쿠버네티스를 활용해 배포에 대해 듣기 시작하였다. DevOps에 다양한 직군들이 있고 다양한 오픈소스들이 사용된다는 것을 알게 되었다. 또한 Jenkins를 처음 사용해보면서 그렇게 어렵지만은 않겠다는 생각을 했다. 쿠버네티스라는 기술에 관심을 가지게 된 이유가 바로 이 배포였다. 배포에 대해 잘 학습하고 이전 프로젝트를 쿠버네티스를 활용해 배포하는 것에 도전해보고 싶다. 회고벌써 마지막이라는 것이 실감이 나지 않는다. 강의를 마지막까지 다 들으며 잘 마무리하려고 노력해야겠다. 복습이 이렇게 오래 걸릴지 몰라 처음에 미뤄둔 것이 너무 아쉽다. 워밍업 클럽이 다 끝난 이후에라도 복습을 다 해 유종의 미를 거둬야겠다.

인프런 워밍업 클럽 백엔드- devops 3주차 발자국

미션https://dev-gongmyoung.tistory.com/57https://dev-gongmyoung.tistory.com/58https://dev-gongmyoung.tistory.com/59 쿠버네티스의 Object들을 미션을 수행하며 이해해 보았다. 강의를 들을 때 이해가 잘 안되던 부분들도 미션을 수행하며 동작을 확인해 보니 잘 이해되는 것 같다. 강의 수강쿠버네티스의 Object들에 대해 더 세세하게 배웠다. 'Object를 그려보며 쿠버네티스 이해' 강의에서 전체 object들을 이해할 때 어렵던 부분들도 다시 이해가 되었다. Probe라는 개념이 굉장히 신기했다. 쿠버네티스가 제공할 수 있는 안정성과 운영의 편리함이 이런 probe에 의해 제공된다는 것을 처음 알았다. 또 설정만 몇 개 수정해도 다른 효과를 낼 수 있는 것이 신기했다. 쿠버네티스는 정말 설정이 쉽지 않은 것 같다. 회고 한번 밀리다 보니 따라 잡는 것이 쉽지 않은 것 같다. 강의를 언제까지 꼭 들어야 한다는 것은 없지만 날짜가 있는데 밀리니 좀 조급해지는 것 같다. 이번주에는 따라잡을 수 있도록 2, 3배 더 노력해야 할 것 같다. 복습 블로그 작성도 생각보다 오래 걸렸다. 시간을 조금 더 보수적으로 잡고 해야 할 것 같다.

인프런 워밍업 클럽 백엔드- devops 2주차 발자국

미션https://dev-gongmyoung.tistory.com/56미션을 통해 쿠버네티스가 잘 설치되었는지 확인해 보았다. 스크립트로 간단하게 설치했는데 무게감 있게 설치하는 방법에서 배운 것들이 다 잘 적용되어 있는 것을 확인하였다. 일프로님이 스크립트를 고생하며 작성하였기에 이렇게 문제 없이 빠르게 설치할 수 있음을 알게 되었다. 추후에 나도 공식 문서를 보며 이렇게 스크립트 하나로 어려운 설치들을 쉽게 할 수 있게 정리할 수 있을까 생각이 들었다. 강의 수강쿠버네티스 생태계와 쿠버네티스를 사용하면 왜 편리한지에 대해 배웠다.이전 프로젝트에서 모니터링과 로깅을 적용할 때 생각해보면 프로젝트의 yml 파일에 모니터링, 로깅 툴에 대한 설정이 있고 gradle에서 툴들을 설정했었다.이런 부분들이 개발 프로젝트와 모니터링, 로깅 툴들이 엮여 있는 구조인 것 같다는 생각을 하였다.하지만 쿠버네티스를 사용하면 분리할 수 있어 의존도를 낮출 수 있다고 생각했다.이전 프로젝트에 쿠버네티스를 적용해 얼마나 더 편리해지는지 테스트 해보고 싶다. 회고이번 주는 많은 강의를 듣지 못하고 복습도 하지 못한 것 같다.부지런하게 했어야 했는데 그러지 못한 것 같아 아쉽다.또 복습을 하지 못해 기억에서 많이 휘발된 것 같다.다음주에는 이번주에 하지 못한만큼 더 힘들고 많겠지만 이번주에 못한만큼 다음주에는 최선을 다해봐야겠다.

인프런 워밍업 클럽 백엔드- devops 1주차 발자국

강의 수강https://dev-gongmyoung.tistory.com/54https://dev-gongmyoung.tistory.com/55 쿠버네티스 관련 용어들을 흐름에 따라 배웠다.이야기처럼 흐름을 따라가며 용어들을 이해하니 더 잘 이해되는 것 같다. 쿠버네티스를 설치하는 방법에 대해 배웠다.늘 이런 환경 설정이 어렵고 오류도 많이 발생하고 자료를 찾는 것도 나의 상황과 다른 것들이 많았다.이번에 공식 문서를 따라가며 왜 스크립트에 그런 명령어들이 작성 되었는지 이해하니 공식 문서의 힘을 알게 되었다.추후에는 환경을 설정할 때 두려움 없이 공식 문서를 따라가며 환경 설정을 시도해 볼 것 같다. 회고쿠버네티스가 어렵다고 하지만 강의를 들어보니 처음 듣는 용어부터 알아야 할 것이 많을 것 같다는 생각이 들었다.또 일프로님의 어마어마한 강의에 깜짝 놀랐지만 머리에는 잘 들어오는 것 같다.복습을 역시 해보니 더 잘 이해되고 기억에도 남는 것 같다.하지만 그만큼 시간도 더 오래 걸리는 것 같다.이번주에는 많은 양을 하지 못했지만 다음주부터는 일정에 맞게 바로바로 진행해 봐야겠다.

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

인프런 워밍업 클럽인프런 워밍업 클럽 스터디는 실무에 필요한 지식을 다질 수 있는 지식공유자 주도 스터디 프로그램이다. 지식공유자가 직접 운영하는 스터디에 참여하고, 실무 지식과 인사이트를 얻을 수 있는 좋은 프로그램이다. 참여 이유이전에 들어보면 좋은 강의로 추천 받았던 강의가 우빈님의 Readable Code와 테스트 코드 강의였다. 이전 인프런 워밍업 클럽 2기 때 할인 쿠폰을 제공해줘서 강의를 구매하고 2기에는 참여하지 못했었다. 이번에 3기를 진행한다는 소식을 듣고 참여하게 되었다. 좋은 강의를 들으면서 지식 공유자님이 제공하는 과제와 라이브 세션까지 들을 수 있었기에 참여를 결심하였다. 또 늘 강의 듣는 것을 미뤘는데 이번 기회에 끝내보자는 마음도 있었다. 좋았던 점우선 빠른 시간 내에 강의를 듣고 과제를 진행해야 한다는 점이 좋았다. 과제를 진행하기 위해서는 강의를 들어야 했기에 강의를 미룰 수가 없었다. 그리고 2번의 중간 점검에서 실제 작성한 리팩토링한 코드와 테스트 코드를 코드 리뷰 해주시는 것도 좋았다. 비록 나는 내 코드가 부족하고 리뷰 받기에도 많은 시간을 들이지 않았던 것 같아 신청을 하지 않았지만 다른 참여자분들의 코드 리뷰를 보면서도 많이 배울 수 있었다. 마지막으로 강의가 너무 좋았다. 추천 받는 이유가 있는 강의였다. 이 강의를 듣고 개발에 있어 다시 눈이 떠지는 느낌이였다. 읽기 좋은 코드가 무엇인지에 대해 알게 되었고 테스트 코드에 대해서도 알게 되었다. 이후에 이것들을 적용해 보고 싶다는 마음이 생겼고 개발에 다시 흥미가 생긴 기분이였다. 회고인프런 워밍업 클럽에 참여한 것은 정말 만족스러운 경험이였다. 비록 워밍업 클럽을 진행하면서 뭔가 바뻐서 과제에 조금 더 시간을 쏟지 못한 것이 아쉬웠다. 강의를 한 2~3번 반복해서 들으면서 과제나 강의의 코드들을 리팩토링하고 테스트 코드를 작성해보고 싶었는데 그렇지 못한 점도 아쉬움으로 남는다. 비록 인프런 워밍업 클럽은 끝났지만 다시 강의를 빠르게 보면서 내 것으로 더 만들어 봐야겠다. 다음에 또 인프런 워밍업 클럽이 진행된다면 CS 지식 파트에 지원해보려고 한다. 그 때는 더 열심히 해서 우수 러너까지 도전해봐야겠다.

인프런 워밍업 클럽 백엔드-code 4주차 발자국

학습 요약 및 회고Layered Architecture에서 Layer를 분리해서 테스트 하는 방법을 배웠다.각 Layer의 특징도 달랐고 특징에 따라 테스트하는 방법도 달랐다. 단위 테스트 위주로 테스트해야 하는 곳, 통합 테스트를 적절히 섞어야 하는 곳, Mock을 사용해야 하는 곳 등 다 다르다는 것을 느꼈다. 그리고 Mockito 라이브러리에 대해서 배웠다. 이전에 늘 테스트 할 때 필요한 객체를 생성하는데 지쳐 테스트를 포기했던 기억이 있다. 이런 어려움을 해결할 수 있는 방법이 있다는 것을 알았다. 내가 원하는 결과를 반환하게 설정할 수도 있고 또는 객체의 행동을 그대로 가져올 수도 있는 것이 놀라웠다. Mockito 라이브러리를 잘 알고 있다면 테스트하기 어려운 부분도 쉽게 테스트할 수 있고 다양한 기능들을 테스트할 수 있을 것 같다는 생각이 들었다. 중요한 기능이여도 번거롭고 어려운 테스트라고 포기하는 경우가 줄고 테스트 커버리지를 높힐 수 있을 것 같다는 생각이 들었다. 마지막으로 테스트에 대한 다양한 조언을 들었다. 테스트를 작성할 때에도 많은 고민이 필요한 것 같다. 배운 조언들을 테스트 코드에 녹이고 테스트 코드도 읽기 좋은 코드로 작성하도록 노력을 해야 할 것 같다. 테스트 코드를 잘 짜는 방법은 역시 계속 연습해보는 것 밖에 없는 것 같다. 다양한 기능을 테스트 해보며 '어떻게 더 좋은 테스트 코드를 짤지', '어떻게 더 테스트하기 좋은 코드를 짤지' 등을 고민해 보며 좋은 코드를 짜려고 노력해야 할 것 같다. 미션Day 16 미션 : 각 Layer의 특징과 어떻게 테스트하면 좋을지에 대해 작성하는 미션이였다. 각 layer의 특징을 작성하고 각 layer를 테스트할 때 특별하게 했던 방법들을 작성해 봤다. 각 layer마다 다른 layer들과는 다른 테스트 방법들이 있었던 것 같다. 그런 것을 위주로 작성해 봤다. https://inf.run/6AFn9 Day 18 미션 : Mock 관련 annotation들을 비교하고 테스트 항목을 배치하는 미션이였다. Mock 관련 annotation들에 도드라지는 특징들을 작성하려고 하였다. 예를 들면 @Spy는 @Mock과 달리 '특정 기능만 Mocking하고 나머지 기능은 원본 객체와 동일하게 수행' 하는 특징 등을 작성했다. 테스트 항목을 배치하는 미션은 어떤 것을 테스트 하려고 하는지에 주목했다. 이것이 테스트 코드를 작성하는데 가장 중요한 것 같다. 어떤 것을 테스트 하려고 하는지를 when에 넣고 해당 테스트에만 중요한 것들을 각각의 given에 넣는 것이 포인트라고 생각했다. https://inf.run/xoG6G

워밍업 클럽 3기 Code 과정 Day 18 미션

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 차이 @MockMockito의 기본 Mock 객체 생성객체의 동작 지정 안하면 기본 값 반환Spring Context 없이도 사용 가능 @MockBeanSpring이 관리하는 특정 Bean을 Mock 객체로 대체하는 것Spring Context 내에서 효과가 있음@SpringBootTest나 @WebMvcTest에서 사용MockBean말고 다른 Bean들은 실제 Bean 사용 가능@Autowired로 Mock 객체를 주입 @SpyMockito의 Spy 객체 생성특정 기능만 Mocking하고 나머지 기능은 원본 객체와 동일하게 수행when().thenReturn()으로 특정 메서드의 동작만 변경 가능Mock의 verify 메서드와 비슷 @SpyBeanSpring이 관리하는 특정 Bean을 Spy로 대체하는 것Spring Context 내에서 효과가 있음Bean을 일부만 Mocking하는 것@SpyBean이 인터페이스인 경우 구현체가 Spring Context에 등록되어 있어야 에러 발생 X @InjectionMocks@Mock이나 @Spy로 생성된 객체를 자동으로 주입생성자, 필드, setter를 통해 주입 가능수동으로 주입할 필요 없이 Mockito가 알아서 주입해줌 2. 테스트 항목 @BeforeEach, given절, when절에 배치"@BeforeEach void setUp() { 0-1. 사용자 생성에 필요한 내용 준비 0-2. 사용자 생성 0-3. 게시물 생성에 필요한 내용 준비 0-4. 게시물 생성 } @DisplayName(""사용자가 댓글을 작성할 수 있다."") @Test void writeComment() { // given 1-1. 댓글 생성에 필요한 내용 준비 // when 1-2. 댓글 생성 // then 검증 } @DisplayName(""사용자가 댓글을 수정할 수 있다."") @Test void updateComment() { // given 2-1. 댓글 생성에 필요한 내용 준비 2-2. 댓글 생성 // when 2-3. 댓글 수정 // then 검증 } @DisplayName(""자신이 작성한 댓글이 아니면 수정할 수 없다."") @Test void cannotUpdateCommentWhenUserIsNotWriter() { // given 3-1. 사용자2 생성에 필요한 내용 준비 3-2. 사용자2 생성 3-3. 사용자1의 댓글 생성에 필요한 내용 준비 3-4. 사용자1의 댓글 생성 // when 3-5. 사용자2가 사용자1의 댓글 수정 시도 // then 검증 }" Why?각 테스트에서 검증하려는 것이 무엇인지 고민해봤다.1번 테스트는 댓글 작성 가능 여부2번 테스트는 댓글 수정 가능 여부3번 테스트는 자신 외의 다른 사람이 댓글 수정 불가능 여부 그렇다면 검증하려는 것이 when에 들어가야 한다고 생각했다.그리고 이에 필요한 것들을 given에 넣었다. 그런데 사용자 생성과 게시물 생성은 각 테스트의 given에 공통적이라고 생각해 @BeforeEach로 넣었다.given에도 각 테스트에 필요한 것들만 준비하는 것이 좋다고 생각했다.

워밍업 클럽 3기 Code 과정 Day 16 미션

미션 내용Layered Architecture의 레이어별로1) 어떤 특징이 있고2) 어떻게 테스트를 하면 좋을지자기만의 언어로 정리해보기 Persistence Layer특징DB와 상호작용하는 LayerDB에 값을 넣고 가져오는 로직을 담당비즈니스 가공 로직이 있으면 X (역할과 책임 분리)데이터 CRUD에 집중단위 테스트 느낌 어떻게 테스트 하면 좋을지?사용하는 기술 (ex : jpa, querydsl, jpql)을 내가 잘 사용해서 DB와 상호 작용하는지 테스트기술을 잘못 사용하면 원하는 데이터를 받아올 수 없음jpa의 경우에도 쿼리 메서드를 잘 짜주겠지만 혹시 내가 메서드명을 잘못 지었을 수도 있기에 쿼리 메서드에 대해서도 테스트주로 List 형태로 메서드의 반환 값이 많이 반환될 것이기에 hasSize, extracting, containsExactlyInAnyOrder 메서드 활용하면 좋음데이터를 직접 넣기에 데이터 만드는 메서드가 정의되어 있으면 조금 더 보기 좋음 Business Layer특징비즈니스 로직이 구현된 곳도메인 객체의 로직도 존재트랜잭션 관련된 것에 주의해야 함persistence layer와 상호 작용persistence layer와 business layer 통합 테스트 느낌 어떻게 테스트 하면 좋을지?비즈니스 로직, 도메인 객체의 로직을 수행하는 메서드들에 대해 테스트 진행 (단위 테스트)각 로직들 메서드 단위로 분리를 잘하여 테스트하기 용이하게 해야 함LocalDateTime과 같이 테스트하기 어려운 것들이 존재한다면 분리하고 파라미터로 받게 하여 테스트 용이하게 해야 함도메인과 관련된 validation은 이 layer에서 테스트를 진행하는 것이 더 역할과 책임이 분리된 것역시 데이터 많이 만들기에 데이터 만드는 메서드 있으면 좋음 Presentation Layer특징외부와 상호작용하는 곳api로 파라미터를 받거나 값을 내려주는 곳응답 처리, 예외 처리, validation이 중요한 곳하위 layer들과 분리해서 테스트하는 곳단위 테스트 느낌 어떻게 테스트 하면 좋을지?하위 layer들과 분리해서 테스트하는 것이 좋다.이를 위해 MockMvc 및 mock 객체 사용andExpect 메서드를 잘 활용해야 함공통 응답이 잘 내려가는지 테스트 필요예외 발생 시 원하는 포맷, 메시지 등이 잘 응답되는지 테스트 필요쿼리 파라미터에 대한 validation 잘 이뤄지는지 테스트 필요여기에서의 validation은 기본적인 @NotNull, @NotBlank 같은 것을 테스트business layer의 validation과 분리하는 것이 필요

인프런 워밍업 클럽 백엔드-code 3주차 발자국

학습 요약테스트 코드 작성에 대해 배웠다.테스트 코드는 어찌 보면 간단하다고 생각하는데 늘 손이 가지 않고 어렵다고 느껴졌다.생각해보면 assertThat 같은 몇 개의 함수만 사용해서 같은지 확인하면 되는데 왜 어려운가 싶었는데 작성된 코드의 문제였던 것 같다.단위 테스트에서 중요한 것은 아래와 같다는 것을 알게 되었다.테스트 세분화 하기테스트하기 어려운 영역 분리테스트하기 어려운 영역 분리하는 것이 정말 어려운 것 같다.예를 들어 입력을 받는 부분이나 LocalDateTime 같은 시간이 사용되는 부분이 테스트하기 어려운 영역이다.이런 영역들을 메서드에서 분리해 상위에서 파라미터로 받게 코드를 잘 짜놔야 테스트하기 쉬운 것 같다.또한 application.yml에서 dev와 test의 profile을 분리하여 test에서는 데이터를 직접 넣게 하는 것도 알게 되었다.dev에서 data.sql로 데이터를 미리 넣어놨을 때 테스트하기 어려운 것을 보았다.이때 test의 profile을 분리해 test에서는 자기가 원하는 데이터들을 넣어서 테스트 해야 한다는 것을 알게 되었다.이전에는 테스트할 때 객체를 생성해서 직접 넣는 것이 굉장히 어려웠던 기억이 난다.이런 경우 역시 테스트하기 어렵게 코드를 짠 경험이였던 것 같다.데이터를 쉽게 만들고 테스트할 수 있게 메서드를 분리하거나 해야 할 것 같다.또한 테스트 코드도 문서라는 것도 배웠다.@DisplayName을 사용해 테스트코드가 어떤 것을 테스트 하는지 잘 보여줘야 한다.또한 BDD 스타일로 작성하니 더 테스트코드가 잘 읽힌다는 것을 알게 되었다.하지만 테스트코드에서 데이터를 여러 개 복잡하게 만들어서 넣는 경우 테스트코드의 given절이 굉장히 길어지고 더러워지는 것 같다.이 경우 어떻게 해야 할지 조금 더 고민해 봐야 할 것 같다.미션Day11 미션 : 스터디카페 코드에 대해 테스트코드를 작성해 보는 미션이였다.나는 LockerPass, SeatPass, PassOrder에 대해 테스트코드를 작성하였다.각 도메인 클래스 모두 비즈니스 로직들이 많이 들어있었기에 어떤 것을 테스트 할지 잘 보인 것 같다.PassOrder의 경우 전체 금액을 계산하거나 할인을 계산하는 로직에 대해서도 테스트 하였다.그리고 SeatPass의 경우 Locker를 사용할 수 있는지 없는지를 체크하는 로직에 대해 테스트 하였다.LockerPass의 경우 LockerPass와 SeatPass가 같은 고정권인지에 대해 테스트 하였다 .https://github.com/CJ-1998/readable-code/tree/test/src/test/java/cleancode/studycafe/tobe/modelhappy case와 반대에 대해 테스트를 작성했었다.이렇게 2개씩 할 수 있어서 7개를 작성할 수 있었던 것 같다.이것들 이외에는 어떤 것을 테스트 해야 할지 잘 보이지 않았던 것 같다.어떤 것을 테스트 해야 할지, 할 수 있는지, 어떤 테스트코드를 짜야 하는지 보는 눈을 길러야 할 것 같다. 회고읽기 좋은 코드에 이어서 테스트코드에 대해 학습했다.읽기 좋은 코드를 짜야 테스트 코드도 잘 짤 수 있는 것 같다.또 어떤 것을 테스트 해야 하고 테스트 해야 하지만 어떻게 테스트 할 수 있을지 고민을 많이 해보면서 테스트코드를 작성하는 능력을 키워야 할 것 같다.늘 멀고 어렵게 느껴졌지만 이번 기회를 통해 테스트코드도 이전 프로젝트에 적용해 봐야 할 것 같다.

인프런 워밍업 클럽 백엔드-code 2주차 발자국

학습 요약 & 회고읽기 좋은 코드와 객체 지향이전에는 읽기 좋은 코드와 객체 지향과 관련이 없다고 생각했다. 객체 지향은 그냥 프로그래밍의 하나의 방법이자 개념이라고 생각했다. 늘 코드를 작성하기 전에 객체가 어떤 것이 있는지 식별하고 어떤 관계를 가지고 이런 것에 집중했던 것 같다. 하지만 이번 강의를 들으며 놀라운 경험을 했다. 객체 지향적으로 짤 수록 더 읽기 좋은 코드가 되는 것을 느꼈다. SOLID 원칙도 왜 중요한지 깨닫게 되었다. SOLID 원칙을 지키지 않고 여러 책임이 혼재된 코드는 당연히 읽기 어려울 수 밖에 없다. 그리고 이전에 이펙티브 자바 책을 읽으며 '아 이런 것이 자바로 코딩할 때 좋은 점들이고 기술이구나' 이정도로 생각했다. 왜 상속보다 조합이 좋은지, 일급 컬렉션을 사용해야 하는지 잘 모르고 그냥 유지보수하기 좋으니까, 상속은 결합도가 높으니까 이렇게 받아드렸다. 그렇다 보니 이펙티브 자바를 이해할 때 어려움이 있었고 잘 기억에도 남지 않았던 것 같다. 이번 강의를 들으면서 이펙티브 자바에 나왔던 개념들을 적용하며 읽기 좋은 코드가 되는 것을 보았다. 이렇게 객체지향의 개념을 적용하니 코드가 읽기 더 수월해짐을 느꼈다. 그러면서 다시 이펙티브 자바를 읽어보고 어떻게 적용해 읽기 좋은 코드를 작성할 수 있을지 고민해봐야 겠다. 미션Day 7 미션 : 스터디 카페 키오스크 프로그램을 읽기 좋은 코드로 바꾸는 미션 우선 section 2, 3에서 배운 간단한 리팩토링을 진행하려고 했다. if-else문을 피하고 빠른 return을 하려고 했다. 또한 공통적인 코드들이 보여 메서드로 추출하려고 했다. if문으로 패스 종류에 따라 분기되던 것들을 메서드로 추출했다. 하지만 마지막 locker 관련된 부분이 달라 어려움을 겪었다. 어찌저찌 메서드로 패스 종류 받도록 추출하기는 했지만 뭔가 억지스러운 것 같다. 하지만 아직 객체지향을 적용해 읽기 좋은 코드로 만들기는 익숙하지 않은 것 같다. 리팩토링한 코드가 여전히 여러 책임을 가지고 관심사가 모여 있는 느낌이다. 하지만 어떻게 분리를 해야 할지, 어떻게 객체지향적으로 메시지를 주고 받게 할지 잘 보이지 않는 것 같다. 지뢰 찾기를 다시 강의를 보며 리팩토링 해보고 한번 더 새롭게 리팩토링에 도전해 봐야 겠다.