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

인프런 워밍업 클럽 2기 발자국 4주차1. 한 주의 정리드디어 마지막 주차이다. 이번 주차는 Layerd Architecture에서 Presentation Layer와Test Double 그리고 테스트를 작성하기 위한 팁들, 마지막으로 부록이 있다. 마지막 페이즈답게 테스트를 위한 지식공유자님의 개인적인 견해와 팁들이 많이 녹아져 있는 강의들이라 좋았다. ✅ 섹션 6. Presentation Layer Test표현 계층에 대한 테스트를 작성하는 방법에 대해 배움,중요한 것은 비즈니스 로직이 들어가는 것이 아니라 넘겨온 값들에 대한 검증이라고 생각한다고 하더라,나 또한 동의한다. ✅ 섹션 7. Mock을 대하는 자세Test Double에 대해 배우고 각 객체의 사용법 그리고 지식공유자님의 개인적 견해가 들어가 있다. 처음으론 Stub과 Mock! 많이 헷갈렸는데Stub은 상태 검증Mock은 행위 검증이라는 관점에서 접근하는 방법을 배웠다. 다음은 Mock하면 항상 나오는 말인데, Classicist VS Mockist이다. 우선 나는 Classicist쪽에 더 가깝다. Mocking을 하면 항상 통과할텐데..(왜냐면 그렇게 짜여지니까)실제상황에서의 다양한 변인들을 통제할 수 있을까? 하는 생각이다. 그렇지만 완고한 고전파는 아니고 Mocking하고 넘어가도 되는 부분은 충분히 그럴 수 있다는 생각이다. ✅ 섹션 8. 더 나은 테스트를 작성하기 위한 구체적 조언완전 농축 액기스 섹션이다.지식공유자님께서 여지껏 겪어오면서 고민하고, 또 좋았던 경험을 바탕으로 팁들을 녹여놓은 섹션이다.다른 섹션들도 물론 군데군데 그것들이 녹여져있지만, 이 섹션에서는 아예 그냥 키워드를 퍼먹여준다.꼭꼭 씹고 내 것으로 만들자. ✅ 섹션 9. Appendix부록인데 부록이 아니다.우선 처음은 테스트 코드를 조금 친숙히 다가가는 법, 아닌 말로 뭐 만드는게 없는데 테스트코드를 어떻게 짜요? 란 생각이 은연 중에 있었다.그런 나의 썩은 정신 상태를 고쳐줄 수 있는 좋은 방법이었다. Spring REST Docs는 확실히 Swagger와는 다른 장점을 보인다.나는 Docs쪽을 더 선호하는 데 이 강의에서 말한 Swagger의 단점이 나는 아주 치명적으로 느껴져서이다. ✅ 섹션 10. Outro그 동안 학습했던 것들에 대한 정리와 조언..? 사람들은 매번 겪어야 깨닫는 특성이 있는데.나 또한 마찬가지고, 어찌됐든 테스트를 짜는게 느린게 아니라 빠른거다 라는 것은 점점 피부로 느껴진다. 흔히 나는 게임에 비유를 하는데 테스트 코드는 공략이다. 이 요구사항을 어떻게 해치울 지 공략이 있다면, 프로덕션 코드는 공략대로 가면 된다. 근데 공략이 없다면.. 좀 더 오래걸리더라 .. 2. 미션이번 주차에서는 Layerd Architecture 구조의 레이어 별 특징과 어떻게 테스트하면 좋을 지 그리고 @Mock, @MockBean, @Spy, @SpyBean, @InjectMock에 대한 정리와예시 테스트의 시나리오 재배치 2가지의 미션이 있었다. 하나하나 작성하기 양이 좀 되어 따로 블로그에 작성한 링크를 참조하려 한다. ✅ 미션 Day-15https://romanc3.tistory.com/131 ✅ 미션 Day-18https://romanc3.tistory.com/132 🤔 내 생각을 정리하자면강의도 좋았지만, 워밍업 클럽 자체가 좋은 기획 같다.동일한 관심사를 가진 사람들과 같은 강의를 보며 다른 생각을 경험할 수 있다는 점이 아주 좋았고,지식 공유자님과 면대면은 아니더라도 의견을 주고 받을 수 있는 공간을 제공 받을 수 있다는 것이 큰 이득으로 다가왔다. 잘하고 싶다면, 잘하는 사람을 모방 하라는 말이 있다.모방을 우습게 보는데.. 따라하기란 쉬운게 아니다. 결국 똑같이 따라할 수 있다는 것은 똑같은 실력이란 것이다.그러한 관점에서 나는 내가 생각하기에 좋은 개발자 분들을 많이 알 수 있게 된 기회였다. 언제까지나 테스트에 매몰되어 있지는 말고, 얼른 마무리해서 습관적으로 테스트를 작성하고 또 다른 부분을 신경쓸 수 있는 개발자로 거듭나길 연습해야겠다 😃

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

인프런 워밍업 클럽 2기 발자국 3주차1. 한 주의 정리이번 주차부터는 테스트 코드 학습이 시작됐다.테스트 코드는 뭔가 짜야지 짜야지 하면서, 처음 하려고 하면 뜬 구름 같은..?마치 헬스장을 PT 없이 처음 가는 기분일까..? 아무래도 유튜브나 이런걸 보고 할 순 있지만 뭔가처음가면 런닝머신만 뛰고 오기 부지기수이다.나에게 테스트 코드는 그런 느낌이었다. 혼자서 짜면 굉장히 얇은 층만 건들이다가 마는 것 같은..? 3주차에서는 일단 내가 건들이던 층까지라크게 다를 것은 없었지만 그럼에도 많은 것들을 배웠다. ✅ 섹션 2. 테스트는 왜 필요할까?테스트의 필요성에 대해 먼저 간략히 알려주는 섹션이다.여기서 말씀 주신 것들의 대부분이 공부를 하거나 일을 할 때 테스트 코드가 없는 경우에 느낀 불편함들이 있었다.이 섹션에서는 그러한 불편한 부분들 그리고 테스트 코드 자체로 발생할 수 있는 불편함들에 대해 정리 해주고 있다. ✅ 섹션 3. 단위 테스트가장 쉽게 접근할 수 있고 또 빠르게 테스트를 할 수 있는 단위 테스트에 대해 학습했다.단위 테스트를 작성하는 기법이나 프레임워크 등 그리고 어떤 것들을 테스트해야 하는 지 생각하는 방식 등을 알 수 있어 조금은 테스트에 있어 어색한 나에게 좋은 섹션이었다.특히 테스트하기 어려운 것과 쉬운 것을 구분하고 테스트하기 쉬운 구조로 변경하는 방법이 꽤 도움이 되었다.반면에 테스트하기 쉽게 프로덕트를 변경하는 것이 옳은 것인가? 에 대해 한번 고민하게 되었다 ✅ 섹션 4. Test Driven Development한 동안 엄청나게 많은 사람들을 괴롭힌 TDD이다강의에서 간략한 요약으론 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론RED : 실패하는 테스트 작성GREEN : (빠른 시간 내에) 테스트 통과 최소한의 코딩REFACTOR : 구현 코드 개선 테스트 통과 유지 위와 같이 안내해준다. 이 장에 대해선 좀 모호하다. 나는 TDD를 옹호하고 긍정적인 쪽은 아니다.그러나 테스트 코드는 중요하다고 생각한다. 프로덕트를 먼저 짜든 테스트를 먼저 짜든 중요한 것은 그 본질이라 생각하며나는 그 부분이 요구사항을 만족하며 최대한 꼼꼼한 기능 구현이라고 생각한다. ✅ 섹션 5. 테스트는 [ ] 다괄호 안의 내용을 말하는 것이 강의의 스포일까..? 두루뭉술하게 말하자면테스트 자체도 보기 쉽게 작성을 해야한다는 강의 내용이었다.@DisplayName을 명확히 작성한다든지 gwt나 gw&t 방식으로 구분지어 테스트를 작성하여 보기 쉽게 만들어 주는게 좋지 않을까요? 하는 관점이었다. ✅ 섹션 6. Spring & JPA 기반 테스트쓸 건 많은데 쓰기엔 좀.. 강의 내용을 너무 적나라하게 내보낼까봐 조심스럽다.그리고 나 또한 강의의 내용을 그대로 옮기는 회고를 선호하지 않기에.. 이 장에서는 Layerd Architecture에서 많이 활용되는 방식의 테스트 구조를 설명하고아랫단에서부터 올라가고 있다. 우선 이번 주차에선[6-2] Business Layer까지라 나눠서 작성하기도 애매하고.. 일단은 이 강의의 가장 핵심 부분이지 않나 싶다 섹션 6과 7은 그 밖에도 테스트 상황에서 발생할 수 있는 여러 문제 상황들을 상세하게 재연해주시므로 도움이 많이 되는 장이다. 2. 미션이번 주차에서는 테스트 코드를 작성하는 미션이 진행됐다.코드의 양이 꽤 많으므로 github 링크를 같이 첨부하며 어떤 식으로 접근 했는 지 설명하겠다. https://github.com/ckaanf/readable-code/tree/mission/day-12 ✅ 아래부터 차근 차근처음 테스트가 하나도 없는 코드를 받으면 숨이 턱..왜냐하면 테스트 상황에 대한 구조부터 하나하나 쌓아 올려가야 하기 때문이다.그나마 이 프로젝트는 Spring이 아니었기에 여러 Mock들이나 스프링 Bean에 의해 발생하는 문제는 없어서 다행이었다. 타고타고타고나는 일단 메인 비즈니스 로직에서 메서드를 계속 타고 최하단 까지 내려 가는 것으로 먼저 테스트 코드를 작성했다. 거기서 객체 수준의 테스트가 필요하다고 생각되면 작성을 하였고 또 역으로 그 객체를 사용하는 위치로 가서 테스트 코드를 작성했다. 미션은 테스트 코드 작성두 번째로는 테스트를 위한 프로덕트의 변경은 하지 않았다.그저 내가 생각하기에 필요하다고 생각되는 테스트 케이스는 작성하되 그것이 통과하도록 프로덕트를 변경하진 않았다. 이번 미션은 테스트 코드 작성이지 리팩토링이나 기능의 변경이 아니라고 생각했기 때문이다.그렇기에 실패하는 테스트도 존재하며, 그것은 의도된 것임을 밝힌다 최대한 독립적으로마지막으로는 최대한 독립적으로 짜려고 했다. 서로의 테스트가 서로에게 영향을 주지 않도록, 그리고 프로덕트의 코드의 변경이 테스트의 영향을 주지 않도록,또한 테스트하려고 하는 When 외에 변경을 반영하지 않도록 말이다. 🤔 내 생각을 정리하자면테스트 코드는 분명 중요하다.그러나 테스트 코드는 테스트 코드여야 한다.그 책임을 넘어 프로덕트의 책임까지 침범하거나 그 이상의 권한이 주어져서는 안된다고 생각한다. 이번에 적은 양의 코드지만 테스트를 짜면서 느낀 것은 이 적은 양도 꽤 많은 테스트가 필요한데 프로덕트 코드의 테스트는 얼마나 복잡할까?그리고 그걸 지속가능하게 관리하려면 어떻게 해야할까? 등에 대한 생각을 하게 됐다. 다음 주에는 그런 것을 바탕으로 테스트 코드를 관리하는 방법들이나테스트 코드를 분리하는 방법에 대해 같이 공부하면서 강의를 마무리 해야겠다.

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

인프런 워밍업 클럽 2기 발자국 2주차1. 한 주의 정리나머지 뒤의 섹션을 들었고, 직접 리팩토링을 해보니 역시 의도적으로연습하지 않으면 익숙해지기 힘들겠다는 생각이 들었다. ✅ 섹션 6. 코드 다듬기섹션 6의 코드 다듬기는 발견하지 못한 버그를 잡는 다거나 알고리즘의 교체패키지를 정리하고, 변수의 파라미터의 순서 등을 정리하는 등 다양한 리팩토링이 진행된다.알고리즘에 대해서,나는 좀 긍정적인 시각이다.알고리즘에 대해 굉장히 중요하다고 생각하고 활용을 잘 해야한다고 생각하는데,그렇지 않은 입장도 있다. ✅ 섹션 7. 리팩토링 연습본격적으로 코드가 하나 주어지고 해당 코드를 리팩토링 하는 연습을 진행했다.워밍업 클럽의 미션으로도 진행한 해당 리팩토링은 아래의 미션에서 정리하도록 하겠다. 여기서는 확실히 개개인의 관점에 따라 같은 코드가 각자 다르게 리팩토링 되는 걸 경험 할 수 있었다.그 관점이 모두 납득이 가는 충분한 이유였고, 그렇기에 리팩토링과 클린 코드에 대한 이 스터디의 소중함을 느꼈다.2. 미션이번 주차는 직접 리팩토링을 하는 미션을 진행했다.꽤 긴데 가볍게 정리를 해보도록 하자. ✅ 리팩토링나는 크게는 내부와 외부,그리고 객체의 책임과 협력 관점에서 리팩토링을 진행했다. 전체 코드는 Github를 참고하는 게 낫겠다.https://github.com/ckaanf/readable-code/tree/mission/day-7 InputHandler/OutHandler를 바라보는 관점나는 여기서 두 클래스가 행위만 하도록 변경했다.저 클래스에 Message를 던지고 두 객체는 입력을 받거나 출력을 하거나 하는 행위만을 실행한다.그렇기에 입력을 받는 것은 입력을 받아야할 객체,출력을 하는 것은 출력을 해야할 객체로 옮겼는데. 생각해보니 그렇게 하니 입출력의 변경에 따라 객체에 변경사항이 생긴다는 관점이 있었고,"입/출력 양식" 이것이 과연 객체가 가지고 있어야 할 책임인가? 에 대해 다시 생각해보게 되었다. 중복 제거80%가 똑같고 20%만 다른 로직들에 대한 중복제거즉 거의 대부분은 비슷하나 살짝의 분기문이나 팩터의 추가로 달라지는 로직에 대해서 어떻게 처리해야하나 고민이 있었다.이 부분을 Optional로 강의에서는 해결하는 데, 나는 그 부분까지는 고려하지 못했으나 비슷하게는 처리했다.그러나 null 객체에 대한 안정성이 좀 떨어지는 것 같아 강의를 보고 다른 관점에 대해 알게 됐다. 🤔 내 생각을 정리하자면확실히 이론적인 것을 실제로 적용하려하니 아직은 어색하고 머리가 굳는 듯한 느낌을 받았다.역시 의도적으로 자주 생각하고 적용해보는 것이 중요할 것 같다. 여담으로 중간 점검에서 다양한 질문들과 다른 분들에 대한 코드 리뷰까지 정성스레 해주시는 것을 보고정말 괜찮은 강의를 골랐고, 인프런 워밍업 클럽이 좋은 기회였다는 것을 다시 한번 느끼게 됐다.

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

인프런 워밍업 클럽 2기 발자국 1주차1. 한 주의 정리박우빈님의 읽기 좋은 코드를 작성하는 사고법을섹션1 ~ 섹션5까지 들었다.양으로 보면 적지 않았으나, 내용의 큰 어려움은 없어 강의를 보는 것에 부담은 없었다.편하게 보고 생각을 좀 많이 하게 되는 강의이다.한 주간 강의를 복기해보자.✅ 섹션 2. 추상추상에서는 클린 코드를 추구하는 이유와 추상화 과정에 대해 학습했다.추상화를 거치는 사고 과정 그리고, 단어(변수, 메서드 이름, 클래스 이름 etc.,)와 메서드 그 자체를 추상화 시키는 것에 대해 학습했다. ✅ 섹션 3. 논리, 사고의 흐름논리,사고의 흐름 섹션에서는 추상적인 기법 대신에 조금 더 밀접하게 관련이 있는 것들에 대해 학습했다.예를 들어 Early return 이라든 지 indent를 줄이는 등, 개발자가 개발하는 입장에서보다 읽는 입장을 고려하여 사고를 최대한 적게, 그리고 직관적으로 코드를이해할 수 있도록 짜는 방법에 대해 학습했다. ✅ 섹션 4. 객체 지향 패러다임객체 지향 패러다임 섹션은 객체를 설계하고 지속 가능하고 읽기 좋은 객체로 발전해나가는 방법에 대해 학습했다. 기본적으로는 SOLID에 근간을 두어 설계 했으나, 객체 그 자체가 적절한 책임과 역할을 수행할 수 있도록 만드는 것이 중요했다. ✅ 섹션 5. 객체 지향 적용하기섹션5에서는 4에서 만든 객체를 토대로 활용하는 것을 학습했다.상속과 조합VO일급 컬렉션EnumInterface 활용과 같이 조금은 어려울 수 있으나 제일 흥미로운 부분이었다.사실 이 부분을 어떻게 극한까지 활용하느냐가 자바 개발자의 실력 중 하나이지 않을까? 하는 생각도 했다.2. 두 개의 미션이번 주차는 간단한 사고를 하는 미션 한개와 그리고 직접 해보는 미션 한 개가 주어졌다.어떤 방식으로 접근했고 해결 했는 지에 대해 복기하자. ✅ 추상화첫 번째는 추상화 미션이다. 추상 : 부동산 - 자산의 개념으로 추상화 됨 구체 :1. 아파트 - 특정 위치에 있는 주거용 건물로, 가족 단위의 주거 공간을 제공하며, 시장에서 거래되는 금전적인 정량 지표가 있음2. 상업용 빌딩 - 기업이나 상점이 운영되는 공간으로, 임대 수익을 창출할 수 있는 자산3. 토지 : 개발 가능성이 있는 임야... 등 다양한 자산을 추상화하여 묶어서 부동산으로 표기 나는 위와 같이 이 미션을 제출했는데, 일반적인 제출자들과는 좀 다른 방식으로 접근한 것 같다.많은 분들이 추상화 - 구체화에 대해 중점을 두었는데,나는 이걸 인터페이스와 같은 느낌으로 접근하고 해결했다.부동산이라는 인터페이스에 다양한 구현체가 있다. 여기서 일단 한번 추상화가 들어간다.그리고 부동산이라는 것 자체도 말 그대로 업무를 진행하는 장소인 그것이 있고,경제적 가치를 아우르는 부동산이라는 개념이 또 존재한다.여기서 또 한 번의 추상화가 들어간다. 나는 이 개념이 굉장히 추상화 레벨이 높은 고수준의 추상화라고 생각했기에 제출했다. ✅ 리팩토링 & SOLID에 대해 나만의 정리이 부분은 많이 길기에 따로 블로그에 빼서 작성을 했다.그러나 간략히 요약하자면,이 미션도 최대한 주어진 것에 만족하고 그 이상의 것을 덜어내려 노력했다.첫 번째로 섹션3을 토대로하는 배경이 있기에 3에서 다루지 않은 방식들은 시도하지 않았으며,SOLID에 대한 정리는... 나 스스로는 사람마다 정리가 다르다면 원칙이 아니지 않나? 라는 생각으로SOLID를 실천하는 나만의 방법..? 이런식으로 접근하여 작성했다. 이-공계에서 흔히 정리, 이론, 원리, 정의등 비슷한 뉘앙스의 단어가 많다.면밀히 살피면 그 뜻이 조금씩은 다르다. 우리가 다룬 SOLID는 principle을 약어로 쓴다.원리(原理, principle)는 사물이나 현상의 근본이 되는 이치로 기초가 되는 근거 또는 보편적 진리위와 같은 내용이 principle의 사전적 정의이며, 이렇기에 나는 나만의 정리가 아닌 나만의 실천 방법으로 이 미션을 접근 한 것이다. https://romanc3.tistory.com/130위 내용은 따로 블로그에 작성해뒀다.🤔 내 생각을 정리하자면섹션 5까지 듣고 생각을 정리하자면, 섹션 2와 3은 조금은 더 사고와 밀접하고4와 5는 기법에 가깝다는 생각을 했다. 물론 사고도 포함 하겠지만 말이다. 여기까지 들으면서, 새로운 사고법과 그리고 객체를 만드는 다양한 관점을 알 수 있어서 좋았다.이것은 비단 강의 뿐만 아니라 워밍업 클럽을 통해 다양한 사람들의 해결 방법을 볼 수 있다는 것이 큰 장점 이지 않았나 싶다. 반면에 아쉬웠던 점은 무릇 이러한 부분들이 다 그렇듯 체화 하기가 어렵다는 점이다.마치 가끔씩 쓰는 단축키 처럼 평소에는 까먹고 필요할 때 다시 찾아본다. 분명 그 단축키가 유용함에도 말이다. 그럼에도 아예 존재를 모르는 것과 아! 그런게 있었지? 하고 생각이 나는 것은 다른 부분이라 생각한다.이 강의를 통해 그런 것을 미리 알아가는 것은 분명 좋은 경험이다. 앞으로는 한번 씩 해서는 체화 시키기 힘든 이러한 부분들은 의도적으로 계속 생각하고 따로 간단한 기능들을 만들어가면서 훈련해봐야겠다는 생각을 한다.