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

이번주 학습 내용각 컨트롤러, 서비스, DAO 부분에서 테스트 하는 방법을 공부했다.Persistence LayerPersistence Layer란, CRUD 가 일어나는, DataBase 를 통해 값을 저장하거나, 읽어오는 부분의 역할에 대한 테스트 이다.간단한 조건을 통해 (Where 구문이 포함된) 데이터를 조회하게 될 때, 내가 의도한 조건으로 필터링 된 데이터가 잘 도착하는지 검사할 떄나,데이터를 저장하거나, 수정하는 로직의 경우, 어떤 부분을 어떤 방법으로 수정하는지와, 수정된 값이 내가 의도한 대로 잘 작동하는지 확인을 하기 위한 테스트이다.위 테스트는 비지니스에 대한 로직이 포함되어서는 안되며, CRUD 쿼리 자체를 검증하는 부분이라고 봐야한다.Business LayerBusiness Layer 에서는 실제 우리 도메인에서 가진 서비스단에서 수행되는 Business 로직에 대해서 검증하며, Persistence Layer 의 테스트를 포함해 작성하는 것이 좋다.성공 케이스인 A 메소드를 수행해 저장된 값이 1 > 2로 변경되는 부분에 대해서도 당연히 테스트가 진행되어야 하지만, A메소드 수행 도중 예외 상황을 만났을 때, 어떤 메시지를 가진 예외가 발생하는지 까지 테스트에 포함되어야 한다.그리고, 비즈니스 로직을 수행하다가 실패할 경우, 한 단위의 트랜잭션에 포함 시켜, 수행 이전 상태로 돌아가도록 설정해야 한다.추가적으로, 서비스에 대한 설계가 이루어 질때, 항상 요구사항을 정리 후, 테스트 부터 작성하고 예외의 경우는 무엇이 있으며, 해당 상황의 경계값 테스트를 통해 로직에 기반한 테스트를 하지 않도록 가장 주의해서 작성해야 하는 부분이라고 생각한다.Presentation LayerPresentation Layer 에서는 외부 세계로 부터 데이터를 받아오는 Controller 에 대한 테스트를 주로 담고 있으며, 요청되는 파라미터 값에 대한 큰 기준의 유효성 체크 (빈 값이 들어오면 안되는 값) 등에 대한 검증을 할 수 있으며, Controller 계층은 Service 와 의존관계를 거의 항상 맺고있기 때문에, 외부에서 넘어오는 값에 대해 검증을 위해서, 하위 계층에서 일어나는 일들을 Mocking 처리하고, 하위 계층에서 일어날 Business 로직에 대해서는 위 Business Layer 와 Persistence Layer 에서 검증할 수 있도록 한다.위 상황에서 보면, Presentation Layer 와 Business Layer 에서 각각 유효성 체크를 하고 있는 것을 한 곳으로 묶는게 어떨지에 대한 생각이 들 수 있다.하지만, VO 단위에서 예외로 생각되는 부분과 내가 작성한 비지니스 로직에서 생각되는 예외를 분리해 처리함으로 서, 좀더 명확한 Exception Message 를 가진 상세한 예외를 처리할 수 있으며, 동일한 메소드가 재사용 되기 위해서는 VO에서는 특정 비지니스 로직에 종속되지 않은 범용적 예외 상황에 대해서만 처리 되도록 작성해야 하며,이를 항상 염두에 두고 한 설계를 하도록 하자!좋았던점 (Liked)이전에 테스트를 설계하면서 테스트가 어렵다 생각하고, TDD방식을 지키며 하지 못했던 내 사고의 방식이 어떤식으로 변경되어야 하는지 조금은 알아가고 있는 것 같다.아쉬웠던 점 (Lacked)이번주도, 신경쓸 시간이 많이 없어 미션이 아직 밀려 있는 부분이 있다. Day 18 미션은 적어도 월요일까지 스스로라도 완료할 예정이다..배운 점 (Learned)어느정도 범위까지 테스트가 작성되어야 하는지, 내가 작성하면서느낀 테스트의 필요성을 이미 강의에서 설명해주고 계서서 많은 도움이 됬다.앞으로 바라는 점(Longed for)다음주 금요일 이전까지 남은 강의와 미션들을 전부 마무리 해보면서 비록 진도표 대로 따라가진 못했지만, 내 스스로라도 마무리 할 수 있도록 마무리하겠다!

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

이번주 학습 내용테스트를 작성을 위해 생각하는 요령과 테스트를 왜 필요한지 등 테스트에 관해서 학습했다.테스트 작성을 위해 고민 해나가는 과정새로운 요구사항이 들어왔을 때, 요구사항이 잘 정의 되었는지, 암묵적으로 이야기 되지 않은 내용이 있거나, 아직 고려하지 못한 예외상황에 대한 처리가 필요할지 확인을 해야한다.테스트 케이스들을 세분화 해서, 해피 케이스 말고도, 예외 케이스인 경우도, 개발자가 예상한 상황이 되는지 체크할 수 있다.예외 케이스의 경우, 경계값 (범위나 구간, 날짜 등)으로 체크를 하는 것이 좋다.TDD 방식코드 구현이전, 테스트를 작성 후, 구현을 통해 테스트가 구현과정을 주도로 하는 방법TDD 방식은 다음과 같은 과정을 거친다RED 실패하는 테스트 작성GREEN 테스트 통과를 위한 최소 작업REFACTOR 구현 코드 개선 하며, 테스트 통과를 유지하도록 한다.장점테스트를 먼저 작성한 뒤, 구현을 하게 된다면, 테스트하기 어려운 영역(관측할 떄마다 다른 값에 의존을 하거나, 외부 세계에 영향을 주는 코드)들에 대해서 외부 파라미터 등으로 넘겨주도록 해, 해당 부분도 테스트 가능한 코드를 작성할 수 있다.내가 작성하는 코드에 대해서, 자주, 빠르게 피드백 받을 수 있게된다. (테스트 케이스 확인만으로 가능)구현 후 테스트를 작성하게 되면, 구현부에 의존한 테스트에 대해서만 생각하게 될 수 있어, 놓치기 쉬운 엣지 케이스들에 대해서도 고려할 수 있게 된다.테스트를 통해 보장해야할 기능목록이 생성 되 있어, 과감한 리팩토링도 가능하게 된다.BDD 방식개발자가 아닌 사람이 봐도 이해할 수 있을만한 추상화 수준을 테스트에 적용하는 것함수 단위의 테스트 보다 시나리오에 기반한 테스트케이스 자체에 집중하여 테스트 한다.Given / When / ThenGiven : 시나리오 진행에 필요한 모든 준비 과정When : 시나리오 행동 진행Then : 시나리오 진행에 따른 결과 명시, 검증BDD방식으로 테스트를 작성 한다면, 테스트 코드로 프로덕션의 기능을 명시하는 문서의 역할을 할 수 있다.해당 방식으로 작성된 테스트를 보고, 코드를 이해하는 다양한 시각과 관점을 키워갈 수 있고, 팀단위로 관리된 테스트 들은 다른 사람들이 어떤 관점으로 테스트를 작성했는지를 통해 팀의 자산으로 관리될 수 있다.좋았던점 (Liked)테스트 코드를 좀더 알아가고 싶어서 깃에 스프링 부트 소스등 잘 만들어진 테스트 코드가 무엇이 있는지 찾아보는 시간을 가졌다.아쉬웠던 점 (Lacked)이번주에 회사 회식과, 타 일정이 많아 미션에 쏟은 시간도 짧았고, 이번주에는 강의도 많이 밀렸다..내가 저번주에 2주만에 완강을 하면서 끝난듯이 너무 쉬는 시간이 많았던것 같다.다시 마음을 다잡고 완강할 수 있도록 해야겠다.배운 점 (Learned)이전에, 테스트 코드를 TDD 방식으로 작성해보고자 했었던 적이 있었는데, 그때는 TDD의 장점에 대해서 전혀 파악하지 못하고, 어떻게 사고해야 하는지, 테스트가 진짜 의미는 있는걸까 하는 의문점이 지금은 조금씩 해결되 가고 있는 느낌이다. 강의를 잘 쫓아가며, 테스트에 대해 더 빠져보아야 겠다.앞으로 바라는 점(Longed for)일단 이번주에 진행하지 못한 부분이 커서.. 진도에 맞추어 진행할 수 있도록 열심히 쫓아가야겠다!

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

2주차 클럽 스터디 회고이번주 학습 내용객체지향 적용 하는 방법에 대해서 학습했다.실무에서는 보통 상속 보다 타 객체를 조합하고, 여러개의 구체를 바꾸어가며 사용할 경우 인터페이스를 활용해 설계를 해야 함을 알았다.Value Object (VO)도메인의 어떤 개념을 추상화 하여 표현한 객체로, 객체를 값으로 취급하기 위해, 불변성, 동등성, 유효성 검증을 보장하도록 설계해야 한다.불변성필드의 값이 변하지 않아야 한다. 생성되는 값들은 final (변하지 않는 값) 으로 선언하고, Setter를 사용하면 안된다.동등성객체의 주소가 서로 다르더라도, 내부의 값이 동일하면 같은 객체로 취급해야 한다. (HashCode, equals 재정의를 통해)유효성 검증생성자를 통해 객체를 생성할 때, 객체가 가진 특성에 따라 유효성 검증을 통해 객체가 항상 자신이 가진 역할을 수행할 수 있도록 보장해야한다.Entity 와의 차이점Entity 는 VO에서, 모든 값이 동일할 때만 같은 객체로 인식하는 것이아니라, 식별자가 존재해 해당 식별자가 같을 경우 동일한 Entity 로 인지하며, 시간에 따라 변화한 Entity로 이해할 수 있다.일급 컬렉션단 하나의 Collection 을 가지고 있는 객체이며, 해당 컬렉션을 추상화 시켜 가공로직을 담고 있어, 테스트를 용이하게 만들어 주는 것.하지만, 일급 컬렉션은 가공로직을 가지고 있기 때문에, 일급컬렉션을 통해 특정 조건을 만족하는 반환할 때, 새로운 콜렉션으로 반환 시켜주어야 한다. (외부에서 해당 컬렉션을 조작하지 못하도록)도메인 개념은 만드는 것이 아니라 개념을 찾아가는 것이다.내가 만들어갈 도메인들은 만들어질 기능의 성격에 따라서 관점에 따라서 여러가지 도메인이 만들어질 수 있으며, 만들어질 부분의 성격을 이해해 개념을 찾아가는 과정이다.좋았던점 (Liked)이전주에는 기한에 맞추어서 하지 못했던 부분까지, 2주만에 전체 강의를 완강에 성공했다!이번주차 미션으로 주어진 리팩토링은 고민을 하고, 일이 있어 제 시간에 마무리하지는 못했지만,내가 지금까지 배운 내용을 강의를 보지 않고 직접 고민해보고 나만의 리팩토링을 하고, 라이브 중간점검을 통해 코드리뷰를 하는 부분을 보며, 개선해갈 방향을 알아가게 되었다!아쉬웠던 점 (Lacked)코드리뷰를 제시간에 완료하지 못해 신청하지 못했다..나도 꼭 리뷰를 받아보려고 내가 저번주 주말에 계획한대로 시간을 할애하지 못해 결국 개인 리팩토링 완료를 신청기간내에 하지 못했고, 하루정도 늦춰져서 마무리했다. (마무리 했더라도 내가 작성한 부분에 대해 반성을 많이 했을 것 같다.)물론, 내가 코드리뷰 받지 못했어도, 우빈님이 라이브 때 내가 궁금했던 점은 거의 풀렸으며..3주차에서는, 다른 코드리뷰를 받으신 분들 처럼, readme.md 파일이나, 물어볼 부분의 소주제를 알고, 정리하도록 하는 좀더 기록을 하고, 공유할 수 있도록 할 것이다!배운 점 (Learned)Optional 이라는 Null을 반환할 때 명시적으로 표현해 주는 방법이 왜 필요한지 알게 되었다.앞으로 과제를 통해서나, 기록한 내용을 꼼꼼히 하나하나 분류를 나눠서 진행을 해야함을 알게되었다..앞으로 바라는 점(Longed for)실무에서 지금까지 배운 읽기 좋은 코드 작성하는 방법을 매일매일 상기하며 적용시켜 볼 것이다.아무리 내가 이 강의에 대해 기록을 했다고 하더라도, 계속 고민하고 살펴보지 않는다면, 결국에 다시배우기 이전으로 하나하나 돌아가는 것 같다.. 이제는 작은 한파일 작업할때 정렬하는 부분 부터 시작해서코드를 작업하고 배운부분을 하나하나 적용할 부분은 없는지 이걸 몸에 습관으로 배게 할 것이다!

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

1주차 클럽 스터디 회고이번주 학습 내용추상화의 개념은 중요한 정보를 가려내고 덜 중요한 정보를 제거하여 도메인 내에서 명명한 항목을 보고 어떤 행위, 어떤 정보를 담고 있는지 파악 가능하도록 하는것 읽기 좋은 코드를 작성하기 위해서 신경써야 할 부분추상화할 때, 하나의 책임으로 묶기 어려울 경우, 여러 부분으로 나눠야 한다.어떤 항목의 이름을 지을때, 단수와 복수를 구분해서 사용하고, 이름을 줄이지 않으면서 명명해야 한다.메소드의 이름을 지을 경우, 메소드 시그니처 (메소드 명 + 파라미터)를 통해 어떤 정보를 가지고 어떤 행위를 하는지명확하게 표현할 수 있도록 해야한다.** 한 파일 안에서, 추상화 레벨이 동등하게 (자연스럽게 읽으면서 지나갈 수 있도록) 구성해야 한다.상수를 사용할 경우, 매직 넘버/스트링 과 같이 이름을 짓고 사용해야 한다.Early return 을 사용해 else if/else 의 사용이 꼭 필요한 경우가 아닌 경우 지양해야 한다.사용할 변수는 가깝게 선언해야 한다.!사용을 피하고 반대되는 사항이 있을경우 반대되는 의미를 담도록 명명하고, 반대되는 의미가 여러개일 경우 부정어를 통해 명명하는 것이 좋다.의도한 예외와 예상하지 못한 예외를 구분해서 관리해 예상하지 못한 예외를 분석을 통해 줄여가야한다.객체지향 프로그래밍을 제대로 활용하기 위해 SOLID 원칙을 지켜가며 고민해가면서 설계해야 한다. 좋았던점 (Liked) 모든 강의를 들으면서 파악한 내용들을 Notion 에 기록했다. 회고록, 강의에 대한 과제를 진행하거나, 내가 내용을 정리할 때 내가 적은 내용을 보고 기억을 떠올리기 좋았다. 실무에 적용을 해보았다. 회사에서 진행하는 프로젝트에서, 한 도메인에서 호출하는 함수들이 자연스럽게 읽으면서 지나갈 수 있도록 메소드 명들을 변경해봤으며, 결과물을 보았을 때 뿌듯했다. 아쉬웠던 점 (Lacked) 스터디 일정에 맞추어 진행하지 못했다. 매번 과제 제출일이 기한 전날 저녁 6시를 넘어서 작업이 끝내서 겨우겨우 제출했다.. 매일 시간을 더 할애해서 미리미리 준비하고, 여유있게 작업할 수 있도록 해야겠다! SOLID, stream API 등 더 궁금한 부분이 있었지만 더 조사해보지 못했다. 매번 시간에 쫓겨서 하다보니 더 궁금하고 찾아보고 싶은 부분이 있었으나, 순간 기억하고 따로 기록하지 않아서 궁금했다가 까먹은 항목이 있다. 해당 부분들을 다시 강의를 들어보며 정리하는 시간을 가질 수 있도록 해야겠다. 배운 점 (Learned) 단축키의 장점을 배워가고 있다. 매번 마우스로 이리저리 옮겨가며 작업하던 부분을 단축키를 통해 훨씬 빨리 움직일 수 있음을 배웠다. 우빈님의 강의를 따라가기 위해서 기록 이외에 단축키를 통해 이동하실 때, 나는 마우스를 써서 못따라갈 경우가 많았는데, 메소드 추출, 생성자 호출(?) 등 점점 자연스럽게 단축키 사용이 익숙해져 가고 있다. 사고를 해야하는 방식 과 무엇을 더 고민해야할지 배우고 있는것 같다. 물론 아직까지 경험도 많이 없고 미흡하지만, 어느쪽으로 고민해야하고, 어떤 경우에 분리가 필요하고, 메소드를 언제 만들어 야 할지를 조금씩 깨달아 가는 것 같다. 코드를 따라하며 어느 부분은 더 신경을 써야겠다를 내가 먼저 생각한 떄도 한 두번 있 었는데, 그때마다 너무 신기하고 기분이 좋았다. 앞으로 바라는 점(Longed for) 공부시간을 늘리고, 기록을 좀더 자세하게 해야겠다. 보통 3시간 강의를 들을때 내가 정리해가며 강의를 들으면 5시간 이상 필요한 것 같다.. 이렇게 해도 가끔 놓히는 부분이 생겼었으니, 주말에 따라갈 수 있도록 궁금한 내용을 기록하고, 많은 것을 얻을 수 있도록 노력해야겠다!