[인프런 워밍업 클럽 백엔드 스터디 2기] 4주차 발자국

이전내용 : 클린코드[인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국[인프런 워밍업 클럽 백엔드 스터디 2기] 2주차 발자국테스트 코드[인프런 워밍업 클럽 백엔드 스터디 2기] 3주차 발자국Mock을 마주하는 자세Test Doubl,e StubbingDummy : 아무 것도 하지 않은 깡통 객체Fake : 단순한 형태로 동일한 기능은 수행하나 , 프로덕션에서 쓰기에는 부족한 객체 Stub : 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체Spy : Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체. 일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있다.mock : 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체Stub : 상태 검증Mock : 행위 검증@Mock, @MockBean, @Spy, @SpyBean @InJectMocks[설명링크] 더 나은 테스트를 작성하기 위한 구체적 조언한 문단에 한 주제!완벽하게 제어하기객체 내부에서 랜던값을 테스트 코드로 비교할 수 없다면 DI를 통해서 외부에서 주입받아서 테스트 코드를 작성하자테스트 환경의 독립성을 보장하자순수한 생성자로만 테스트 기본절을 구성하는 게 더 좋다. (.SQL 파일로 데이터를 인입받는 것을 지양하자)두 가지 이상의 테스가 하나의 자원을 공유한다. 공유자원을 사용하지말고 독립적으로 사용하자.Text Fixture 클렌징DeleteAllInBatch를 사용하는 것을 추천 (DeleteAll은 많은 쿼리가 실행이됨.)기본적으로 클래스 위에 @Transaction을 사용하나 배치 같은 트랜잭션이 혼용되는 곳에서 DeleteAllInBatch을 많이 사용함.테스트 수행도 비용이다. 환경 통합하기❗❗IntegrationTestSupport 추상클래스를 상속 받아서 테스트 코드를 만듦.이를통해서 Spring Boot 띄우는 횟수를 줄이고 최적화를 진행할 수 있음.@ActiveProfiles("test") @SpringBootTest public abstract class IntegrationTestSupport { } @WebMvcTest(controller = { OrderController.class, ProductController.class }) public abstract class ControllerTestSuport { } 테스트를 작성하는 마음가짐테스트를 왜 해야 되는가? 테스트 코드는 귀찮은 작업이다. 하지만 왜 해야 되는지 마음속에 명확히 인지하고 있어야지 귀찮음을 이기고 테스트를 작성할 수 있다.최적의 상황을 판별하고 맞게 도구를 빠르게 사용을 할 수 있어야 진짜 프로다. 지속적으로 도구를 사용하는 방법을 연습하고, 타협하지 않는 마음으로 테스트를 작성해 나가면 미래의 수많은 시간을 아낄 수 있다. 4주차 회고클린코드와 테스트코드 학습의 마지막 날입니다.올해 1월부터 시작한 프로젝트의 오픈 날짜가 10월 28일과 겹치면서 야근도 많았지만, 끝까지 완주해낸 제 자신이 뿌듯합니다. 클린코드와 테스트코드는 실무에서 정말 필수적인 요소라고 생각합니다. 이번 기회에 배운 것들을 혼자만 실천하는 것이 아니라, 동료들과 공유하고 함께 좋은 코딩 습관을 만들어가가도록 하겠습니다. 2024년이 얼마 남지 않았지만, 올해 가장 잘한 일 중 하나라고 자부하고 앞으로도 이러한 원칙들을 항상 인지하면서 코드를 작성하도록 하겠습니다.감사합니다.

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

이전내용 : 클린코드[인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국[인프런 워밍업 클럽 백엔드 스터디 2기] 2주차 발자국오늘은 3주차 Practical Testing: 실용적인 테스트 가이드를 시작하는 한주로 강의에 대해정리하도록 하겠습니다.개인적으로 세션2 테스트는 왜필요한가? 라는 강좌가 제일 중요하다고 생각하였습니다. 테스트를 왜 해야 되는지?테스트 코드는 귀찮지만, 테스트 코드를 구현하지 않는 코드는경험과 감에 의존한다피드백이 늦다.유지보수가 어렵다.소프트웨어이 신뢰성이 떨어진다 라고 전달하였습니다.변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야 한다.변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야된다.빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다. 그렇다면 테스트 코드를 구현한 코드의 장점은빠른 피드백자동화안정감자동화 테스트를통해 비교적 빠른 시간 안에 버그를 발견하고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.소프트웨어의 빠른 변화를 지원한다.팀원들의 집단 지성을 팀 차원의 이익으로 승격시킨다.가까이 보면 느리지만, 멀리 보면 가장 빠르다.이라고 전달하였습니다.저는 과거부터 현재까지 이어져 온 코드를 유지보수하고, 동시에 신규 개발도 진행하고 있습니다. 과거에 작성된 소스코드는 각 구성원들이 큰 책임을 가지고 유지하고 있어, 문제가 발생했을 때 사이드 이펙트나 우회하는 코드 등의 여러 요소를 신경 써야 하는 상황이 많습니다. 이로 인해 신규 입사자(신입, 경력자 모두)들이 코드를 수정하기가 매우 까다로워졌습니다. 그 결과, 작은 기능 하나를 추가할 때도 많은 비용이 소모되고, 신규 개발에 집중할 여유조차 없게 된 것입니다.이 문제를 해결하기 위해 저는 테스트 코드를 도입하자는 의견을 제시했습니다. "우리 소스는 현재 신규 입사자들이 접근하기에 허들이 너무 높기 때문에, 문서화와 프로젝트 히스토리를 테스트 코드로 대체하자"는 것이 제 의견이었습니다. 처음에는 팀원들이 함께 구현에 동참했지만, 곧 저 혼자 테스트 코드를 작성하게 되었습니다. 워낙 업무 속도가 빠르게 진행되다 보니, 테스트 코드 도입을 강요할 수는 없었습니다.그럼에도 제가 생각하는 테스트 코드는 코딩을 더 재미있고 확신 있게 할 수 있는 도구라는 것입니다. 신입 시절, 배포 전 문제가 생길까 긴장했던 경험이 많았고, 코드가 제대로 작동할지 확신이 들지 않았습니다. 그러나 테스트 코드를 도입한 이후에는 빠르게 피드백을 받을 수 있었고, 그로 인해 구현 과정이 훨씬 더 재미있어졌으며, 코딩에 대한 확신도 커졌습니다. 따라서 귀찮더라도 테스트 코드를 한번 작성해보고 재미를 느끼는 것도 좋다고 생각됩니다.@Display Named을 섬세하게테스코드를 구현하면서 제일 어려운 부분이 Display Name이라고 생각합니다. DisplayName을 상세하게 작성하지 않으면 미래에 내가 다시봐도 어떤것을 테스트하려고 하였는가 헷갈리고, 또한 문서 대신에 작성하는 테스트코드가 더 어렵게 느껴질 수 있습니다. 때문에 강의에서는 아래와 같이 예시를 들면서 전달하였습니다.음료 1개 추가 테스트 -> 음료를 1개 추가할 수 있다.[명사의 나열보다 문장 형태로 작성하려고 노력해야된다.]~ 테스트는 지양해야된다.음료를 1개 추가할 수 있다. -> 음료를 1개 추가하면 주문 목록에 담긴다.[테스트 행위에 대한 결과까지 기술하는게 좋다]특정 시간 이전에 주문을 생성하면 실패한다. -> 영업 시작 시간 이전에는 주문을 생성할 수 없다.[도메인 용어를 사용하여 한층 추상화된 내용을 담기]메서드 자체의 관점보다 도메인 정책 관점[테스트의 현상을 중점으로 기술하지 말 것 (~ 실패, 성공 등)] 지속하고 싶은 부분제가 생각했던 부분보다 좀 더 상세하게 디스플레이 네임을 녹일 수 있게 해봐야겠다.라고 생각하였고, 디스플레이 네임이 생각나지 않는다면 지금 작성하는 글을 되돌아봐야겠다고 생각하였습니다. 아쉬웠던 점현업이 오픈 시점이 점점 다가와서 직접 구현을 하면서 강의를 듣지 못하였지만, 그래도 강의를 보면서 어떻게 적용하면 좋을지 인사이트를 얻을 수 있어서 좋았습니다.시도해볼 점직접 구현해 보면서, 장점을 공유할 수 있게 습득하겠습니다.3주차 Practical Testing: 실용적인 테스트 가이드주요 학습 내용:테스트의 필요성테스트 코드 미구현 시 문제점테스트 코드 구현의 장점@DisplayName 작성법명사 나열 대신 문장 형태로 작성테스트 행위와 결과 모두 기술도메인 용어 사용 및 추상화테스트 현상보다 도메인 정책 중심으로 기술가장 인상 깊었던 두 가지 개념:테스트 코드의 실질적 가치문서화와 프로젝트 히스토리 대체 가능코딩을 더 재미있고 확신 있게 만드는 도구@DisplayName의 중요성미래의 자신과 동료를 위한 명확한 설명테스트 의도와 결과를 명확히 전달개선 및 실천 계획:지속할 점더 상세하고 명확한 DisplayName 작성테스트 코드 작성 시 현재 작성 중인 코드 되돌아보기아쉬웠던 점현업 일정으로 인한 실습 부족시도해볼 점직접 구현을 통한 테스트 코드의 장점 습득팀 내 테스트 코드 장점 공유

[인프런 워밍업 클럽 백엔드 스터디 2기] 2주차 발자국

오늘은 2주차 Readable Code의 완강시점으로 한 주간 진행되었던 강의에 대해 정리하고, 배우고 느낀 점을 적도록 하겠습니다. Day -7 리팩토링 연습섹션7 리팩토링 연습을 듣고 작성한 글입니다.메서드 추출로 추상화 레벨 맞추기Optional을 통한 null 반환 안하기객체에 메시지를 보내서 물어보자객체의 책임과 응집도 - IO 통합, 일급컬렉션, display(), Order 추출추상화 관점의 차이 - FileHandler 해당하는 내용에서 2가지가 가장 크게 와닿았습니다. 첫 번째 - 추상화 레벨 맞추기이부분은 이전에 [인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국 에 작성하였습니다.간단한 정리하자면고수준 추상화 레벨은 소스코드에 전반적인 흐름에 대한 내용입니다.저수준 레벨은 세부사항에 대해 작성하는 코드입니다. 하지만 실무에서는 추상화 레벨을 고려하지 않고 코드를 구현하다 보면 개발자가 쉽게 피로해지고, 유지보수하기 어렵다. 때문에 지속적으로 인지하고 변경하자는 내용이였습니다. 두 번째 - 데이터에 대한 추상화 스펙제가 강의를 보면서 제일 중요하다고 생각했던 부분은 방법에대한 추상화가 아닌 어떤 데이터를 필요로 하는지에 대한 스펙을 뽑느게 더 나은 추상화라는 구문이였습니다.데이터 중심의 추상화와 방법 중심의 추상화를 비교하면, 개발에서 중요한 것은 어떤 데이터를 필요로 하는지 정의하고 이를 통해 시스템의 요구 사항을 명확히 하는 것이라는 점 이였습니다.개발 초기에는 종종 구현 방법에 집중하여, "어떻게 코드를 작성할 것인가"에 대해 고민하게 됩니다. 예를 들어, 스타크래프트 게임에서 "배럭을 통해 마린, 파이어뱃, 고스트를 생산"한다고 가정했을 때, 일반적인 구현은 각 유닛을 객체로 만들고, 사용자가 선택할 때마다 객체를 생성하는 방식일 수 있습니다. 이 접근법은 구체적인 객체와 그 생성 방법에 중점을 둡니다.그러나, 의존성 역전 원칙(DIP, Dependency Inversion Principle)을 적용하면, 유닛에 대한 데이터를 추상화하고 이를 생성자를 통해 전달받는 방식으로 코드를 구성할 수 있습니다. 이렇게 하면 구체적인 구현에서 벗어나 유연한 객체 구조를 만들 수 있습니다. 구체적으로는, 배럭이 직접 유닛 객체를 생성하는 것이 아니라, 유닛의 속성(이름, 공격력, 체력 등)에 대한 데이터만을 전달받고 유닛 객체는 외부에서 주입된 데이터를 기반으로 생성되는 구조로 전환됩니다.이와 같은 방식으로 데이터를 추상화하면 다음과 같은 장점이 있습니다:확장성: 새로운 유닛이 추가되더라도, 별도의 객체 생성 코드 변경 없이 데이터만 추가하면 됩니다.유연성: 유닛 생성 방법이 변경되더라도, 추상화된 데이터를 기반으로 유닛을 생성하므로, 코드 수정이 최소화됩니다.재사용성: 동일한 추상화된 구조를 다른 상황에서도 쉽게 적용할 수 있습니다.따라서, 방법에 초점을 맞추기보다는 필요한 데이터의 스펙을 먼저 정의하고 추상화하는 것이 더 나은 설계로 이어질 수 있다는 것을 전달해주었고, 저에게 크게 와닿았습니다. 지속하고 싶은 부분이번 클린 코드를 들으면서 기존에 들었던 내용과 새로운 내용들이 많이 있었습니다. 알고 있던 내용들은 다시 상기시킬 수 있어서 너무 좋았으며, 새로운 내용들은 지속적으로 인지하도록 노력할 것입니다. 그러기 위해 개인 블로그에 정리할 예정이며, 개발에 대해 고민이 있을 때 꺼내 보도록 하겠습니다. 아쉬웠던 점코드 리뷰를 받을 수 있는 자리가 있었는데 날짜를 잘못 봐서 못해봤다는 것이 너무나도 아쉬웠고, 다음에는 미션을 좀 일찍 끝내서 리뷰를 받을 수 있게 할 것입니다.추가적으로 코드 리뷰 상세하게 해주셔서 감사합니다.시도해볼 점같은 프로젝트를 진행하는 팀원들에게도 공유한다면 지금보다 더 성장할 수 있는 개발자가 될 것이라고 생각되었고, 공유하는 자리를 주도적으로 만들어 보도록 하겠습니다.2주차 Readable Code 강의 정리주요 학습 내용리팩토링 연습메서드 추출로 추상화 레벨 맞추기Optional을 통한 null 반환 지양객체에 메시지 보내기객체의 책임과 응집도추상화 관점의 차이가장 인상 깊었던 두 가지 개념1. 추상화 레벨 맞추기고수준 추상화: 소스코드의 전반적인 흐름저수준 추상화: 세부사항중요성: 코드 가독성 향상 및 유지보수 용이성2. 데이터에 대한 추상화 스펙방법보다 필요한 데이터 스펙 정의가 중요데이터 중심 추상화 vs 방법 중심 추상화예시: 스타크래프트 유닛 생산 시스템장점: 확장성, 유연성, 재사용성 향상개선 및 실천 계획지속할 점학습 내용 개인 블로그에 정리개발 시 학습 내용 적극 활용아쉬웠던 점코드 리뷰 기회를 놓친 것향후 미션 일정 조율 필요시도해볼 점팀원들과 학습 내용 공유공유 자리 주도적으로 만들기

[인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국

기존에 프로젝트를 진행하면서 테스트 코드를 작성하고 싶은 니즈가 있었기 때문에, 여러 인터넷 강의를 보던 중 [Practical Testing: 실용적인 테스트 가이드]라는 인터넷 강의를 보게 되었습니다. 책으로 보던 테스트 코드와 다르게 실무에서 어떻게 사용하는지 상세하게 설명해 주는 것이 좋아 완강하게 되었고, 실무에서도 직접 사용하였습니다.2개월 후 이메일을 통해 인프런 워밍업 클럽이라는 메일을 확인하게 되었습니다. 업무와 개인 프로젝트를 진행하느라 바쁘지만 다른 사람들의 개발 방식과 내가 개발 적으로 놓치고 있는 것이 많을 것이라는 생각에 참여하게 되었습니다. Day 2 "추상과 구체"1. "추상과 구체"에 대하여 인터넷 강의를 듣고 작성하게 되었습니다.스타크래프트 배럭의 유닛 생성 과정 1. 유닛 생성 주문 사용자가 배럭에서 어떤 유닛을 생성할지 선택하는 단계입니다. 배럭에서는 마린, 파이어뱃, 매딕, 고스트 등 다양한 유닛을 생성할 수 있으며, 선택 방식은 마우스 클릭이나 단축키를 통해 이루어집니다. 핵심은 배럭이 "유닛 생성 주문"을 받기만 하면, 그 다음 과정은 자동으로 진행된다는 점입니다. 2. 유닛 생성 유닛이 생성되는 과정입니다. 각 유닛마다 사용하는 무기나 특성이 다르지만, 결국 배럭에서 유닛이 "생성된다"는 본질적인 행위는 동일합니다. 예를 들어, 마린은 총을 쏘고, 파이어뱃은 화염방사기를 쓰고, 고스트는 저격총을 들고 있지만, 이 모든 유닛들은 결국 배럭에서 생성된다는 공통점을 가지고 있습니다. 3. 유닛 생성 알림 유닛이 완성되면 사용자에게 이를 알려주는 단계입니다. 사운드를 통해 알릴 수도 있고, 미니맵에 표시될 수도 있습니다. 중요한 것은 유닛이 생성되었음을 사용자에게 확실히 전달하는 것입니다. 정리 배럭에서 유닛을 생성하는 과정은 크게 "유닛 생성 주문 → 유닛 생성 → 유닛 생성 알림"의 흐름을 따릅니다. 유닛마다 특성은 다르지만, 이 과정은 본질적으로 동일하며, 이를 통해 유닛 생성의 핵심 개념을 추상화할 수 있습니다.추상과 구체에서 내가 생각했던 핵심은추상화는 중요한 정보는 가려내어 남기고, 덜 중요한 정보는 생략하여 버린다.라는 말이었습니다. 그렇다면 어떻게 하면 이런 추상화를 잘하는 방법이 있을까라는 생각을 하게 되었습니다.이름 짓기이름을 짓는다는 행위는 추상적 사고를 기반으로 한다. 표현하고자 하는 구체에서 정말 중요한 핵심 개념만을 추출하여 잘 드러내게 표현한다는 말입니다. 그렇다면 어떻게 하면 이름을 잘 지을 수 있을까?단수와 복수를 구분하고이름을 줄이지 않고은어/방언을 사용하지 않고좋은 코드를 보고 습득하는 것 입니다. 추상화 레벨고수준 레벨은 소스코드에 전반적인 흐름에 대한 내용입니다.저수준 레벨은 세부사항에 대해 작성하는 코드입니다. 제가 현재까지 협업했던 실무에서 생각보다 추상화 레벨이 비슷한 분류로 묶여있던 프로젝트는 별로 없었던 것 같습니다. 함수로 호출하기 전에 for, if while 저 수준의 추상화 레벨에서 고 수준의 추상화 레벨을 동작시키는 경우도 많았고, [고수준 > 저 수준 > 고수준 >저 수준 ]으로 들어가는 함수들이 즐비하게 있었습니다. 그렇다면 어떻게 하면 일관성 있게 추상화 레벨을 지킬 수 있을까라는 생각을 하게 되었습니다이는 소스코드의 수정과 변경을 무서워하면 안 되는 것 같습니다. 예를 들면 초기에 코드를 작성하다가 기획서가 변경될 수도 있고, 스스로 잘못 구성하다 문득 좋은 방법이 떠오를 수도 있습니다. 이때 벌써 많은 시간과 코드를 구성해서 알고 있으면서도 넘어가는 경우가 저 또한 많았습니다. 하지만 결국에는 우회해서 코드의 추상화 레벨을 맞추지도 않고 작성했던 코드들이 미래에는 분석하기도 힘들고, 수정하고 있는 제 자신을 발견하니 넘어가면 안 되겠구나 생각하게 되었고, 현재는 시간이 걸리더라도 변경하고 추상화 레벨을 인지하면서 작성하려고 노력하고하고 있습니다. Day 4 SOLID를 활용하여 아래 코드를 수정S - Single Responsibility Principle (SRP) : 정의: 클래스는 단 하나의 책임만 가져야 한다.O - Open/Closed Principle (OCP) : 소프트웨어 엔티티는 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다.L - Liskov Substitution Principle (LSP) : 자식 클래스는 부모 클래스에서 호출하는 동작에 대체가 가능해야 한다.I - Interface Segregation Principle (ISP) : 하나의 일반적인 인터페이스보다는 여러 개의 구체적인 인터페이스가 더 좋다.D - Dependency Inversion Principle (DIP) : 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.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; }관점 지향으로 변경클래스에는 단 하나의 책임만 가져야 한다.현재 클래스를 전체가 작성되어 있지 않지만, 각각의 유호성 체크를 Order에서 만 진행하는 것이 과연 단 하나의 책임인가?라는 생각이 들었습니다.때문에 아래와 같이 item, items, user3개의 객체를 만들고 역할과 책임을 분리하게 작성하였습니다.item.java@Getter public class Item { private Long id; private String name; private BigDecimal price; @Builder public Item(Long id, String name, BigDecimal price) { this.id = id; this.name = name; this.price = price; } }Items.javapublic class Items { private final List itemList; public Items(List itemList) { this.itemList = List.copyOf(itemList); } boolean isItemNotAvailable() { return CollectionUtils.isEmpty(itemList); } public boolean isInvalidTotalPrice() { return calculateTotalPrice().compareTo(BigDecimal.ZERO) User.java@Getter public class User { private Long id; private String name; @Builder public User(Long id, String name) { this.id = id; this.name = name; } public boolean isNullCustomerInfo() { return Objects.isNull(id); } }이를 통해서 아래의 validateOrder에서 어떤 데이터들이 올바르지 않는구나를 한눈에 볼 수 있게 변환하였습니다.@Slf4j @Getter public class Order { private Items items; private User user; @Builder public Order(Items items, User user) { this.items = items; this.user = user; } public boolean validateOrder() { if (items.isItemNotAvailable()) { log.info("주문 항목이 없습니다."); return false; } if (items.isInvalidTotalPrice()) { log.info("올바르지 않은 총 가격입니다."); return false; } if (user.isNullCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } return true; } } 지속하고 싶은 부분이제 1주 차 발자국이 완료하였습니다. 클린 코드에 다시 생각해 볼 수 있는 기회였으며 강의 내용은 하나같이 전부 필요한 내용이라고 생각됩니다. 습관이라는 게 마음대로 쉽게 변하지 않는다고 생각합니다. 인지하고 변화하려는 끊임없는 노력이 필요하다고 생각되고, 회고를 통해 항상 볼 수 있는 예제를 잘 만들어놓으면 크게 도움이 된다고 생각하고 작성하도록 하겠습니다. 아쉬웠던 점아직 1주 차이지만 생각보다 혼자 하고 있다는 생각이 더 드는것 같습니다. 다른 사람들의 작성한 내용은 볼 수 있어서 좋았지만 생각보다 피드백이 없었던 것 같습니다. 1기 2기 3기 ~ 이후에 좋은 개발자들 분들과 함께 피드백을 많이 받을 수 있으면 좋겠다는 생각이 들었고, 저 또한 노력하도록 하겠습니다. 시도해볼 점앞으로 많이 남았지만 완강하고, 미션을 완료하게 된다면 여기에서 머무르는 것이 아니라 주도적으로 회사에서도 진행해 봐도 좋을 것 같습니다. 남들에게 공유해 주면서 많은 지식을 쌓을 수 있을 것 같습니다. 감사합니다.실용적인 테스트와 클린 코드 학습 회고학습 배경[Practical Testing: 실용적인 테스트 가이드] 강의를 수강하며 실무에서 적용 가능한 테스트 작성법 학습인프런 워밍업 클럽 참여를 통한 추가 학습 진행Day 2: "추상과 구체" 학습 내용스타크래프트 배럭의 유닛 생성 과정 예시유닛 생성 주문사용자가 배럭에서 유닛(마린, 파이어뱃, 매딕, 고스트 등) 선택마우스 클릭이나 단축키로 주문주문 후 과정은 자동 진행유닛 생성각 유닛별 특성은 다르지만 '생성'이라는 본질적 행위는 동일예: 마린(총), 파이어뱃(화염방사기), 고스트(저격총)유닛 생성 알림사운드나 미니맵 표시를 통한 알림사용자에게 명확한 피드백 제공추상화에 대한 인사이트추상화의 핵심중요 정보는 유지하고 덜 중요한 정보는 생략효과적인 이름 짓기 원칙단수/복수 구분하기축약어 사용 피하기은어/방언 사용 피하기좋은 코드 참고하기추상화 레벨고수준: 전반적인 흐름저수준: 세부 구현 사항실무 적용시 개선점일관된 추상화 레벨 유지필요시 과감한 리팩토링코드 수정을 두려워하지 않기Day 4: SOLID 원칙 적용 실습SOLID 원칙 요약SRP: 단일 책임 원칙OCP: 개방-폐쇄 원칙LSP: 리스코프 치환 원칙ISP: 인터페이스 분리 원칙DIP: 의존관계 역전 원칙코드 리팩토링 예시리팩토링 전 코드에서 다음과 같이 개선:역할 분리Item: 상품 정보 관리Items: 상품 목록 및 검증User: 사용자 정보 및 검증Order: 주문 검증 통합회고좋았던 점클린 코드에 대한 새로운 시각 획득실무 적용 가능한 구체적 예제 학습지속적인 개선을 위한 동기부여아쉬운 점참여자 간 피드백 부족보다 활발한 상호작용 필요향후 계획강의 완강 및 미션 수행학습 내용 회사 업무 적용동료들과 지식 공유