워밍업 클럽 3기 BE - 발자국 4주 차

1. 들어가며시간이 굉장히 빠르네요. 얼마전에 OT를 듣고 진도표가 굉장히 빡세다고 느껴졌었는데 워밍업 클럽이 마무리가 되었습니다. 👏👏저는 개인적으로 어느정도 강제성이 생겨서 더 좋았던 것 같습니다. 하지만 직장인이 하기에는 시간적으로 부담이 되는게 사실입니다... 어찌어찌 완강을 했고, 실제로 실무에서 조금씩 개념들을 적용해보는 시간들이 가지려고 합니다.그리고 아직 강의가 100% 저만의 키워드로 정리가 되지는 않았기 때문에 몇 번 회독을 해야할 것 같긴 합니다. 2. 학습했던 내용 나만의 키워드로 작성하기섹션 7. Mock을 마주하는 자세Test Double, Stubbingdummy실제 객체를 모방하기만 한 아무 동작도 안하고 아무 행위도 안하는 깡통 객체입니다.그래서 활용할 일은 거의 없습니다.fake실제 객체의 행위와 동일한 기능은 수행하나, 좀 더 단순한 형태로 수행을 합니다.그래서 프로덕션에서 쓰기에는 부족한 객체입니다.stub테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체입니다.spyStub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체입니다.mock행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체입니다.@MockMockito에서 제공하는 어노테이션으로, 테스트에서 사용할 가짜 객체(mock)를 생성합니다.주로 단위 테스트에서 의존성을 대체하기 위해 사용됩니다.@MockBeanSpring Boot의 테스트에서 사용되는 어노테이션으로, Spring ApplicationContext에 mock 객체를 등록합니다.주로 통합 테스트에서 사용되며, Spring의 의존성 주입을 통해 mock 객체를 주입받을 수 있습니다.@SpringBootTest와 함께 사용됩니다.@Spy한 객체에서 일부는 실제 객체의 기능을 쓰고 싶고 일부만 stubbing 을 하고 싶을 때 @Spy 를 사용합니다.@SpyBean@MockBean과 유사하지만, 실제 객체의 메서드를 호출할 수 있는 spy 객체를 생성합니다.@InjectMocks테스트 대상 클래스의 생성자, 필드, 또는 setter 메서드를 통해 mock 객체를 자동으로 주입합니다.주로 단위 테스트에서 사용됩니다.BDDMockitogiven-when-then 스타일로 작성을 도와주는 Mockito 를 감싼 것Classicist VS. MockistClassicist: 진짜 객체로 최대한 테스트를 해야한다Mockist: 각각 테스트를 잘 했으니 통합 테스트를 할 때는 다 Mocking 처리해서 기능 보장된 것들은 Mocking으로 빠르게 쳐내고 테스트를 빠른 시간안에 한다.개인적으로 둘 중 뭐가 중요하다보다는 테스트 코드를 잘 작성하는 게 중요한 것 같다. 섹션 8. 더 나은 테스트를 작성하기 위한 구체적 조언테스트 하나 당 목적은 하나!한 가지 테스트에서는 한 가지 목적의 검증만 수행하는게 좋음.완벽한 제어현재 시간, 랜덤 값, 외부 시스템과 연동하는 경우 등에 대해서 제어할 수 있게 설정하는게 중요테스트 환경의 독립성, 테스트 간 독립성팩토리 메서드 보다는 순수한 빌더나 순수한 생성자로만 테스트 given 절을 구성하는게 더 좋음공유 자원에 대한 것들은 사용하지 않아야 함.Test Fixture@BeforeAll 과 @BeforeEach 에 Test Fixture 구성하지 않기data.sql 에 Test Fixture 구성하지 않기Test Fixture 의 메서드는 필요한 파라미터로만 구성하기픽스처를 만들기 위한 빌더들을 한 곳에 모으는 것을 지양하기deleteAll(), deleteAllInBatch()테스트도 결국 비용관계 정도만 생각을 하면 충분히 벌크 연산인 deleteAllInBatch() 로 한번에 깔끔하게 날릴 수 있기 때문에 deleteAllInBatch() 사용이 낫다.@ParameterizedTest, @DynamicTest@ParameterizedTest: 딱 하나의 테스트 케이스인데 값을 여러 개로 바꿔보면서 테스트를 하고 싶은 경우@DynamicTest: 하나의 환경을 설정해놓고 사용자 시나리오 테스트수행 환경 통합하기빠른 시간 안에 효과적으로 테스트를 수행할 수 있을지 고민해야 함private method test할 필요가 없다.테스트에서만 필요한 코드최대한 지양하는것이 좋다. 3. 학습 회고저의 목표는 단순히 개념을 익히는 것이 아니라, "실무에서 직접 사용해보는 것"입니다.물론 키워드만 알고 있어도 도움이 되겠지만, 직접 적용해 본 경험이 있는 것과 없는 것의 차이는 매우 크다고 생각합니다.이번 과정에서 정말 많은 개념과 기술을 배웠고, 이제는 이를 실제 코드로 구현하고, 직접 사용해보면서 제 것으로 만들어야겠죠.배움에서 그치지 않고, 실무에서도 활용할 수 있는 개발자로 성장해 나가겠습니다! 🚀🔥 정말 도움이 많이 되는 강의 2개였습니다.워밍업 클럽 같은 더 좋은 기회가 있다면 또 참여하고 싶네요. 4. 미션 회고미션 Day 16, 18크게 어려운 미션은 없었습니다. 간단한 키워드 정리만 있었죠.미션이 쉬웠던 이유는 아마 테스트 코드 강의에서 과부하가 걸릴거라고 생각했던 것 같습니다. ㅋㅋㅋ처음 강의를 들을 때 기존에 작성했던 테스트 코드는 사실 테스트 코드라고 부르기 어려웠던 것 같습니다.우빈님이 소개해준 테스트 방식이 정답은 아니지만 굉장히 많은 도움이 됐던 것은 사실이고 현재도 소개받은 테스트 방식으로 작성하고 있습니다.조금씩 적절하게 응용할 수 있는 좋은 자산이 되었습니다!

워밍업 클럽 3기 BE - 발자국 3주 차

1. 들어가며테스트 코드 강의는 미리 봤었고, 그 때 굉장히 오래 걸렸던 것 같네요. 아마 커리큘럼대로 따라가려면 굉장히 힘들었을 것 같아요...이번 주차 내용은 저한테는 굉장히 도움이 많이 됐었던 내용이였습니다.실제로 참고해서 회사 프로젝트에 테스트 코드를 적용하기도 했었구요.테스트 코드에 대한 막연한 두려움을 없애준 강의라서 정말 듣기 잘했다고 생각한 강의였습니다. 2. 학습했던 내용 나만의 키워드로 작성하기섹션 6. Spring & JPA 기반 테스트Layered Architecture관심사의 분리 때문에 레이어를 분리단위 테스트 VS. 통합 테스트여러 객체가 협력해서 어떤 하나의 기능을 동작한다면 통합테스트가 필요함단위 테스트만으로 커버하기 어려운 영역들이 생기기 때문IoC, DI, AOPORM, 패러다임의 불일치, HibernateSpring Data JPA@SpringBootTest VS. @DataJpaTest VS. @WebMvcTest@SpringBootTest스프링에서 통합 테스트를 위해 제공하는 에노테이션@SpringBootTest 에는 트랜잭션이 달려있지 않음 -> 더 선호@DataJpaTestjpa 관련된 빈들만 주입해서 서버를 띄워주기 때문@WebMvcTest컨트롤러 레이어만 딱 떼서 테스트를 하기 위해 컨트롤러 관련 빈들만 올릴 수 있는 가벼운 테스트 어노테이션@Controller와 @ControllerAdvice 등과 같은 빈만 주입 됨 @Transactional (readOnly = true)읽기 전용으로 하면 CRUD 작업 중에 CUD 작업이 동작하지 않음CQRSCommand 와 Query 를 분리해서 서로 연관이 없게끔 하려는 것@RestControllerAdvice, @ExceptionHandler커스텀 예외를 사용해서 처리하는 것도 자주 쓰이는 방법Spring bean validation@NotNull, @NotEmpty, @NotBlank, ...컨트롤러에서는 최소한의 검증만 하고 도메인 레이어나 서비스 레이어에서 검증할 것들은 따로 처리해서 책임을 잘 분리하기MockMvc MockMvc 란 Mock(가짜) 객체를 사용해 스프링 MVC 동작을 재현할 수 있는 테스트 프레임워크ObjectMapper@MockBean스프링 컨테이너에 mockito 로 만든 Mock 객체를 넣어주는 역할예시로, ProductService 빈에다가 적용을 하면 ProductService Mock 객체를 대신 스프링 컨테이너에 넣어줌 3. 학습 회고너무나 바쁜 한 주를 보냈습니다. 정신이 없었네요.옛날에 정리한 내용과 인강을 2배속으로 다시 봤습니다. 분명 정리를 했는데 처음 듣는 것 같은 내용들이 있어서 당황하긴 했습니다 ㅎㅎ.. 역시 완전히 자신의 것으로 만드려면 수많은 반복이 필요한 것 같네요.이번 기회에 반복할 수 있어서 좋은 기회였다고 생각합니다.특히 반복하면서 옛날에 들을 때는 인지하지 못했던 실무적인 관점이 다시 보이더라구요? 굉장히 의미 있었던 것 같습니다. 4. 미션 회고미션 Day 11사실 이번 미션은 회고하기가 애매합니다.냉정하게 저 스스로에 대한 평가를 하자면 열심히 했다고 보기가 어렵기 때문이죠.스프링 기반이 아니라서 단순히 미션의 기준에 맞춰서 필요하다고 생각한 것만 처리했습니다. (사실 코틀린 스터디를 따로 시작했는데 여기에 에너지를 너무 쏟아서,,,)다음주 라이브 시간에 딴 분들의 코드 리뷰를 보면 깨달음과 반성을 동시에 할 것만 같네요.. 😅😅😅

워밍업 클럽 3기 BE - 발자국 2주 차

1. 들어가며어쩌다보니 2추 차까지 왔네요? 이번주는 일이 많아서 정신없이 보냈습니다.게다가 클린코드 리팩토링 실습 미션이 있었습니다.아쉽게도 리팩토링을 깔끔하게 마무리 짓지 못해서 코드 리뷰 신청은 못했네요.. 후회할 일이 늘어났습니다... 😢어쨌든 미션 덕분에 지난주 강의를 꽤 여러번 반복해서 들었는데요, 생각보다 더 많은 인사이트를 얻었습니다.그리고 갈 길이 참 멀다는 사실도 알게 되었죠 ㅎ... 2. 학습했던 내용 나만의 키워드로 작성하기섹션 6. 코드 다듬기좋은 주석주석이 많다는 것은 가독성이 좋지 않은 코드주석이 필요한 경우는 히스토리를 알 수 없을 경우변수와 메서드 나열 순서변수는 사용하는 순서대로공개 메서드를 상단에 위치하고, 비공개 메서드 하단에 위치패키지 나누기기능 유지보수하기기능 유지보수하기정렬 단축키, linting, style - sonarlint, editorconfig 섹션 7. 리팩토링 연습Optionalreturn null / Optional 파라미터 사용은 안티패턴객체에 메시지 보내기공개 메서드를 통해 객체끼리 협력하기객체의 책임과 응집도 - IO 통합, 일급컬렉션, display(), Order 추출추상화 관점의 차이 - FileHandler구현에 초점을 맞춘 추상화 VS 도메인 개념에 초점을 맞춘 추상화 섹션 8. 기억하면 좋은 조언들능동적 읽기 오버 엔지니어링구현체가 하나인 인터페이스너무 이른 추상화은탄환은 없다클린 코드도 은탄환 x항상 정답인 기술은 없음. 경험이 중요! 섹션 3. 단위 테스트수동 테스트, 자동화 테스트 Junit5, AssertJ단위 테스트: 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트Junit5: 단위 테스트를 위한 프레임워크AssertJ: 테스트 코드 작성을 원활하게 돕는 테스트 라이브러리해피 케이스, 예외 케이스항상 예외 케이스가 있는지 고민하고 테스트를 작성해야 함경계값 테스트먼저 테스트 케이스를 세분화하고 경계값이 존재하는 경우는 경계값에서 항상 테스트를 할 수 있도록 고민을 하는게 중요테스트하기 쉬운/어려운 영역 (순수함수)관측할 때마다 다른 값에 의존하는 코드우리가 작성한 코드가 외부 세계에 영향을 주는 코드 섹션 4.TDD: Test Driven DevelopmentTDD테스트를 먼저 작성한 후에 그를 통해 기능을 만들고 그 다음에 기능을 수정할 때 테스트의 도움을 받을 수 있도록 하는 개발 방법론 중에 하나레드 - 그린 - 리팩토링레드: 실패하는 테스트를 먼저 작성하는 단계그린: 테스트가 통과할 수 있는 최소한의 코딩을 하는 단계리팩토링: 테스트를 통과하는 것을 유지하면서 구현 코드를 개선하는 단계섹션 5. 테스트는 []다@DisplayName - 도메인 정책, 용어를 사용한 명확한 문장DisplayName을 섬세하게!1. 명사의 나열보다 문장으로2. 테스트 행위에 대한 결과까지 기술하기3. 도메인 용어를 사용하여 한층 추상화된 내용을 담기4. 테스트의 현상을 중점으로 기술하지 말 것Given / When / Then - 주어진 환경, 행동, 상태 변화Given : 시나리오 진행에 필요한 모든 준비 과정 (객체, 값, 상태 등) When : 시나리오 행동 진행Then : 시나리오 진행에 대한 결과 명시, 검증TDD vs BDD 3. 학습 회고컴퓨터 공학과를 나왔고 실무에서 몇 년을 일했지만 객체 지향으로 코드를 작성하는 방법은 배운적이 없는 것 같습니다.캡, 추, 상, 다가 뭔지는 알고, SOLID가 뭔지는 알지만 코드에 잘 적용이 됐는지는 항상 의문이였죠.이 강의는 정말 기대했던 것 보다 더 많은 인사이트를 얻는 강의였습니다. 아마 당분간은 몇 번 더 돌려볼 것 같네요.그래도 지금까지 여러 블로그나 책들을 읽으면서 객체 지향적으로 코드를 작성하려고 노력했었는데요, 강의와 어느정도 결이 비슷하더라구요. 가는 길이 얼추 올바른 길이였다는 사실이 안심이 됩니다. 테스트 코드 강의는 정말 빠르게 봤던 것 같습니다. 강의가 출시되자마자 바로 봤었죠.그 때는 테스트 코드를 잘 작성하는 게 뭔지 모르기도 했고, 주변에서도 작성하는 사람이 단 한명도 없었기에 정말 도움이 되는 강의였습니다.이번에 속도 3배로 다시 쭉 훑었는데 처음 들었을 때 생각이 많이 났습니다.당시에는 몰랐는데 지금은 테스트 코드를 작성하는데 부담이 없는 것을 보니 성장하긴 했나봅니다. ㅋㅋ 4. 미션 회고미션 Day 7개인적으로 이번 미션에 대해 나에게 점수를 매긴다면 좋은 점수를 주지 못할 것 같네요.강의에서 배운 내용을 제대로 적용하지 못했다는 생각이 듭니다.(변명을 해보자면 시간이 너무 부족했다는... 💦💦) 저는 인터페이스로 빼서 구현하는 방법으로 코드를 꽤 많이 작성합니다. 그리고 객체를 조합으로 풀어서 코드를 작성하는 것을 선호합니다.그래서 리팩토링이 쉬울 줄 알았는데요, 강의 내용을 어떻게든 쑤셔넣으려고 하니까 잘 안되더라구요.. 😭아직은 이론과 실전에 갭이 있다는 뜻이겠죠?더 열심히 해야겠습니다!! 그리고 금요일에 진행된 코드 리뷰는 재미있었습니다. 😆😆😆딴 사람들이 작성한 코드를 편하게 리뷰하는 우빈님한테 감탄했던 것 같네요.역시 세상은 넓고 고수는 많다는?

워밍업 클럽 3기 BE - 발자국 1주 차

1. 들어가며원래 인프런 워밍업 클럽 스터디 1기를 신청하려고 했었는데 업무에 치이다보니 3기까지 미뤄졌네요.테스트 코드 강의가 올라오자마자 바로 완강을 했었는데 정말 도움이 많이 돼서 꼭 한 번 인프런 워밍업 클럽 스터디를 해보자고 생각했었습니다.이제 1주가 지났는데, 신청하길 잘했다고 생각합니다.특히 다른 러너분들 미션을 보는데 역시 고수분들이 많더라구요?혼자 공부하는 것 보단 같이 하는게 성장하는데 도움이 된다는 사실을 또 한 번 느꼈습니다. 2. 학습했던 내용 나만의 키워드로 작성하기섹션 2. 추상추상과 구체추상으로부터 구체를 유추할 수 있어야 함추상화 과정에서 중요한 정보를 부각시켜야 함해석자가 동일하게 공유하는 문맥(context)이 있어야 함즉, ‘적절한 추상화’ 는 해당 도메인의 문맥안에서, 정말 중요한 핵심 개념만 남겨서 표현하는 것이름 짓기 / 메서드 선언부추상화의 가장 대표적인 행위 하나를 꼽으라면 이름을 짓는 것추상화 레벨하나의 세계 안에서는, 추상화 레벨이 동등해야 한다.why? 그래야 코드를 읽기가 수월함매직 넘버, 매직 스트링상수를 추출하는 것도 추상화 행위 섹션 3. 논리, 사고의 흐름뇌 메모리 적게 쓰기 (인지적 경제성)인지적 경제성은 최소한의 인지로 최대의 효율을 내보자는 의미코드를 작성할 때도 마찬가지로 인지적 경제성을 추구하도록 작성하기Early return기억해야 되는 정보가 많은 상태라면 전부 기억하지 않는 방향으로 리팩토링을 하는게 효과적사고의 depth 줄이기무조건 1 depth로 만들기 X추상화를 통한 사고 과정의 depth를 줄이는 것이 중요사용할 변수는 가깝게 선언하기공백 라인공백 라인도 의미를 가짐복잡한 로직의 의미 단위를 나누어 보여주는 역할부정어다른 도메인 표현이나 혹은 다른 영단어를 사용정 안된다면 부정연산자를 써서 사고를 두 번 할 바에는 메서드 자체에 그냥 부정의 의미 (is not, does not, never 등등)를 담는 식으로 활용해피 케이스, 예외 처리예외가 발생할 가능성을 낮추는 것이 가장 중요의도한 예외와 예상 하지 못한 예외를 구분하기가 중요 섹션 4. 객체 지향 패러다임객체, 협력과 책임, 관심사의 분리, 높은 응집도와 낮은 결합도관심사에 따라 객체를 분리하게 되면 각 객체는 특정한 관심사로만 이루어짐특정한 관심사로 이루어진 객체는 높은 응집도를 가지며 다른 객체와 협력할 때 낮은 결합도를 가짐 getter/setter 자제하기, 객체에 메시지 보내기setter는 최대한 지양하기getter를 남발하는 건 무례하면서 폭력적인 행위공개 메서드를 통해 객체끼리 협력하기SOLID: SRP, OCP, LSP, ISP, DIPSRP변경이 있을 때 파급 효과가 적어야 한다.변경이 있을 때 하나의 클래스, 하나의 지점만 고쳐야 한다.OCP인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현인터페이스를 구현한 새로운 클래스를 만드는 것은 기존 코드를 변경한게 아니라 확장에는 열려 있고 변경에 닫혀 있다.LSP하위 클래스는 인터페이스 규약을 다 지켜야 한다.하위 클래스를 대신 사용하더라도 의도대로 동작해야 한다.ISP하나의 범용적인 인터페이스보다 적당히 분리된 인터페이스 여러개가 낫다.DIP구현체를 바라보지 말고 인터페이스를 바라봐야한다.추상화에 의존해야지 구체화에 의존하면 안된다.DI/IoCIoC내가 호출하는게 아니라 프레임워크 같은게 대신 호출DI의존 관계 '주입' 섹션 5. 객체 지향 적용하기상속과 조합 조합을 활용하는 것이 더 좋은 설계why? 상속은 결합도가 높기 때문Value Object, EntityVO는 도메인의 개념을 추상화한 객체, 불변성, 동등성, 유효성 검증을 보장해야 함Entity는 식별자가 존재하며, 식별자가 같으면 동등한 객체로 취급일급 컬렉션컬렉션으로 Wrapping한 객체를 뜻Enum상수의 집합, 상수들에 대한 로직을 담을 수 있음추상화와 다형성 활용하여 반복되는 if문 제거. OCP 지키기OCP를 지기키 위해서 변화하는 것과 변하지 않는 것을 구분해서 생각해야 함변하는 것조건 & 행위 (= 구체)변하지 않는 것조건을 만족하는가? / 행위를 수행한다. (= 추상)숨겨져 있는 도메인 개념 도출하기도메인 지식은 만드는 것이 아니라 발견하는 것 3. 학습 회고평범한 기업에서 소위 말하는 좋은 코드를 작성하는 개발자는 생각보다 희귀한 것 같습니다.아쉽게도 시간에 쫓기기 때문이겠죠. 저 역시 시간이 없어 기능 구현만 마무리하고 리팩토링은 뒤로 미루는 경험을 했었고, 지금도 하고 있습니다.후에 리팩토링을 하면 좋겠지만 대부분의 개발자들은 뒤를 돌아볼 시간이 없죠.그래서 혼자 리팩토링을 하더라도 좋은 코드를 보고 배울 기회가 굉장히 적습니다.결국 혼자 보는 시야는 한계가 있기 때문에 어느 순간 갇히는 느낌을 받죠.강의에서는 코드를 순차적으로 바꿔나갑니다.메서드 명부터 SOLID를 적용하는 법까지 어떤 코드가 좀 더 나은 코드인지 방향을 제시하죠.그래서 시야가 넓어진 느낌을 받았습니다.다른 사람이 작성한 코드를 볼 수 있었기 때문이죠. 객체 지향 언어만 사용한 코드가 아니라 객체 지향으로 작성한 코드를요.기회가 있을 때마다 조금씩 적용을 해볼 생각입니다. 그래서 추상화를 적용해 읽기 좋은 코드가 되도록 노력해야겠습니다. 😄 4. 미션 회고미션 Day 2강의를 듣기 전 미션부터 확인을 했습니다.미션을 보자마자 '책'이 좋은 예시라고 생각했었는데 강의에서 바로 언급해서.. 😂무슨 예시가 있을까 생각하다가 사실 추상과 구체는 거의 모든 곳에서 사용된다고 결론을 내렸습니다.보통 어떤 행동을 한 후에 자세하게 말을 하는 경우보단 간략하게 의도만 파악하도록 말하기 때문이죠.그래서 음식을 먹는 행동을 예시로 미션을 제출했습니다. 미션 Day 4미션 Day 4미션 코드를 보자마자 코드가 씁.... 물론 실무에는 이것보다 정도가 심한 코드도 훨씬 많긴 합니다.중복 분기문과 부정 연산자를 포함한 조건식을 리팩토링해서 한 눈에 보이도록 처리했습니다.추가로 개인적으로도 Early return은 코드를 깔끔하게 만들어준다고 생각합니다. 저도 실무에서 코드를 작성할 때 else문을 잘 쓰지 않게 되더라구요.하지만 글을 쓰면서 아쉽다는 생각을 했습니다."Order 객체 안에서 검증 로직을 처리할까?"하다가 미션의 의도에 벗어나나 싶어서 메서드만 작성했는데요,회고를 작성하면서 미션을 다시 읽어보니 원하는 것은 Order를 파라미터로 넘겨서 처리하는 게 아니라 Order 객체 안에서 검증로직을 만들라는 것 같다는 생각이 들었네요. SOLID에 대하여 자기만의 언어로 정리하기는 개인적으로 의미가 있던 미션이였습니다.좋은 코드를 작성하기 위해서 계속 SOLID에 대한 고민을 하고 있었거든요.머릿속으로 생각만 하고 있었는데 글로 정리를 하니까 좀 더 선명해지는 느낌을 받았습니다.그리고 강의의 리팩토링되는 코드를 보면서 제가 생각했던 방향과 얼추 맞았다고 보여져서 다행이였습니다. 😃