해결된 질문
작성
·
226
2
게시글 구현까지 보고 질문드립니다!
지식공유자님의 깊이가 느껴지는 강의인 것 같습니다.. 구현 난이도(저점-고점)에 상관없이 쭉쭉 구현해나가시는게 대단하십니다
조그맣게 몇가지 질문이 있습니다
강의와 관련된 질문과 그렇지 않은 질문이 섞여있는점 양해부탁드립니다..!
테스트코드
@Test를 만드시고, 따로 밑에 메서드를 추가하시는건 반복호출을 위해서인게 맞을까요!? 그렇다면 JUnit의 @ParameterizedTest, @CsvSource 이거를 활용하면 좋을것같은데 사용 안하신 이유나 실무에서 요거를 잘 안쓰시는지 궁금합니다!
저도 WebClient나 RestClient로 api테스트를 하긴 하는데요! 그 API Docs 만들어주는 RestDocs는 테스트객체: RestTemplate, WebTestClient, RestClient 와 테스트방법(WebMvcTest, SpringBootTest)과 상관없이 플러그인만 추가하면 api docs가 만들어지는걸까요? 지식공유자님은 현업에서 Swagger, RestDocs중에 어떤걸 쓰시는지 궁금합니다
TestContainer 등의 방법은 사용하지 않으시는지!?
JPA & Spring
Controller에서 @PageableDefault()로 받는 방법은 주로 사용되지 않는 것일까요..?
DTO로 반환해서 Response를 내려주시긴 하시지만 ResponseBody나 ResponseEntity 등으로 감싸서 내려주시지는 않으시는데, 이유가 있으신지요!?
강의에서처럼 커버링인덱스와 무한스크롤을 구현하려면 nativeQuery를 사용하지 않고 JPA와Hibernate로 해결하는 방법(JQPL/QueryDsl/Creteria)이나 Raw Library(Spring Data JDBC/JdbcTemplate)으로 해결하는 방법은 없는걸까요?
Next
제가 아직 모든 강의를 다 본것은 아니지만.. 챕터를 보면 각각 다른 모듈끼리 Join을 하는 경우는 없는 것 같아보입니다..! 혹시 나중에 또 강의를 내신다면 샤드키와 DB 이중화의 fail over에 대한 실전강의, 다른 DB 스키마, 모듈을 사용하는 상황에 하나의 View에 다건의 Join이 들어갈 경우 설계 방법..이나
DDD, 클린 아키텍처에 대해서도 다룰 에정이 있으신지 궁금합니다!
마지막 덧붙임
정말 잘 보고 있습니다!! 미취업자(취준생)에 비해서 중-고급 경력직은 그렇게 많지 않아서 강의 수요가 적기도 하고 각자 나름의 위치에서 배운 self best practice가 있어서 그들만의 생각이나 태클이 들어올 수 있을 것 같은데..
이런저런 이유에도 불구하고 이런 귀한 중고급 강의를 내주셔서 정말 감사합니다!
강의 끝까지 수강하고 궁금한점 생기면 종종 질문 올리겠습니다
답변 1
2
보키님, 안녕하세요!
강의 수강하시느라 고생 많으시고, 좋은 말씀 주셔서 감사합니다!
테스트코드
@Test를 만드시고, 따로 밑에 메서드를 추가하시는건 반복호출을 위해서인게 맞을까요!? 그렇다면 JUnit의 @ParameterizedTest, @CsvSource 이거를 활용하면 좋을것같은데 사용 안하신 이유나 실무에서 요거를 잘 안쓰시는지 궁금합니다!
단순히 제 주변(저 포함)에서 잘 쓰지 않아서 낯설었을 뿐이고, 익숙한 방식의 제 경험에 기인했다고 봐주시면 될 것 같습니다.
저도 방금 해당 기능들 다시 찾아봤는데 실무에서도 활용해보면 좋을 것 같네요!
이 부분은 오히려 제가 배워갑니다. 좋은 내용 공유 감사합니다!
저도 WebClient나 RestClient로 api테스트를 하긴 하는데요! 그 API Docs 만들어주는 RestDocs는 테스트객체: RestTemplate, WebTestClient, RestClient 와 테스트방법(WebMvcTest, SpringBootTest)과 상관없이 플러그인만 추가하면 api docs가 만들어지는걸까요? 지식공유자님은 현업에서 Swagger, RestDocs중에 어떤걸 쓰시는지 궁금합니다
현재 전 주로 Swagger를 활용하고 있으나 RestDocs도 현업에서 많이 사용됩니다.
api docs에 대해서는 제가 직접 만들어본건 아닌데,
테스트에 사용한 RestClient의 경우, 실행된 서버 애플리케이션 호출을 위해 임의로 선언해본거라, 일반적인 테스트 또는 문서 도구와 자동으로 통합되진 않을 것으로 예상되네요. (저도 직접 테스트해본건 아니고 찾아보니 테스트코드에서 문서 생성을 위해 RestDocs 연동에 대해 코드 작성 과정이 필요한 것 같네요)
TestContainer 등의 방법은 사용하지 않으시는지!?
이것도 필요에 따라 적절히 사용할 수 있습니다!
강의에서는 테스트를 엄청 꼼꼼하게 다 만든 것도 아니라, 굳이 필요성을 못느껴서 활용하지 않았네요.
현재 강의에서도, 로직 점검하는 단위테스트야 문제 없다지만, API로 직접 호출 테스트(RestClient로 요청)해보는 것은 실제 DB(로컬 개발환경이긴 하지만)에 데이터가 다 들어가고 있는 상황이라 미비한 부분이긴 합니다.
강의에서는 테스트 데이터 준비 과정이 장시간 소요되어 사용하지 않았는데(그냥 로컬 MySQL(Redis/Kafka) 컨테이너를 테스트 전용으로 사용), 이런 곳에 활용해보면 적절할 수 있습니다!
JPA & Spring
Controller에서 @PageableDefault()로 받는 방법은 주로 사용되지 않는 것일까요..?
이러한 부분은,
개인적인 취향 차이일수도 있고, 모르고 있었을 수도 있고, 어떤걸 쓰든 유의미하게 큰 차이가 없다면 익숙한 방식을 택할 수도 있는데요!
저는 해당 애노테이션 모르고 있기도 했고 그냥 파라미터 받는게 익숙하고 편해서 사용했습니다!
뭐가 더 낫다라는 정답은 없어서 필요에 따라 충분히 사용하셔도 됩니다!
DTO로 반환해서 Response를 내려주시긴 하시지만 ResponseBody나 ResponseEntity 등으로 감싸서 내려주시지는 않으시는데, 이유가 있으신지요!?
이 부분도 선호도 차이일 수도 있고, 굳이 사용할 이유가 없어서 그럴 수도 있는데요.
필요한 상황(응답 헤더나 상태 코드를 커스텀 한다든지 등)이면 적용해도 문제 없습니다!
강의에서는 마땅히 그러한 동작이 없어서 굳이 적용 안한 것이라 봐주시면 됩니다!
강의에서처럼 커버링인덱스와 무한스크롤을 구현하려면 nativeQuery를 사용하지 않고 JPA와Hibernate로 해결하는 방법(JQPL/QueryDsl/Creteria)이나 Raw Library(Spring Data JDBC/JdbcTemplate)으로 해결하는 방법은 없는걸까요?
강의에서 JPA를 사용하긴 했지만, 최대한 JPA에 의존하지 않고 개발을 진행하고자 했습니다.
(개인적인 취향이라 조심스럽지만 JPA를 딱히 선호하진 않는 이유도 있습니다)
그래서 데이터베이스에서 동일하게 쿼리를 직접 실행해볼 수도 있고, 실제 쿼리를 바로 확인할 수 있는 nativeQuery로 작성했습니다.
다른 방법에 대해서는,
무한스크롤 같은 경우 단순히 정렬 + 필터링 조건만 추가하면 되는거라 다른 방법으로도 모두 해결 가능할 것 같고,
커버링 인덱스 경우에도 서브쿼리를 지원하지 않으면 articleId만 먼저 뽑아낸 뒤에, 이후에 articleId로 쿼리를 한번 더 보내서 데이터를 가져오면 되므로(즉, articleId와 데이터 가져오는 쿼리 각각 나눠서, 애플리케이션에서 쿼리를 2번 요청하는 형태), 모두 해결 가능할 것 같습니다!
이건 직접 코드를 만들어본건 아니지만, 필요하다면 만들어보셔도 좋을 것 같네요!
답변에 뭐든 정답이 없다는 뉘앙스가 많아서 당혹스러우실 수 있을 것 같은데요,
사실 어떠한 기술(또는 방법론)이든 검토해보고 문제가 없다면, 상황에 적절하다면, 그리고 팀에 납득만 된다면, 뭐든 적용해볼 수 있습니다!
언급주신 내용들은, "실무에서는 사용하지 않는다"라기보단, 필요하다면 사용해도 된다?정도로 인지해도 충분할 것 같네요!
뭐든 딱히 문제될 내용들은 아닌 것 같습니다.
그냥 제가 강의에서 마땅히 적용할 필요가 없어서/익숙치 않아서/몰라서 사용 안했을 뿐이라고 봐주시면 됩니다!
Next
제가 아직 모든 강의를 다 본것은 아니지만.. 챕터를 보면 각각 다른 모듈끼리 Join을 하는 경우는 없는 것 같아보입니다..! 혹시 나중에 또 강의를 내신다면 샤드키와 DB 이중화의 fail over에 대한 실전강의, 다른 DB 스키마, 모듈을 사용하는 상황에 하나의 View에 다건의 Join이 들어갈 경우 설계 방법..이나 DDD, 클린 아키텍처에 대해서도 다룰 에정이 있으신지 궁금합니다!
"하나의 View에 다건의 Join이 들어갈 경우 설계 방법"에 대해서는 게시글 조회 최적화 강의에서 살펴봅니다!
다음 강의로는 여러 주제들 사이에서 계속 고민 중인데, 입문 강의는 잘 만들어진게 너무 많아서 어려운 강의로 변별력을 가지고자 하니 난이도가 만만치 않아서 계속 고민중이긴 하네요..!
일단 구상중인건 아마 대규모 시스템 시리즈로 SNS 피드(인스타그램/트위터같은) 만들기를 해볼 것 같습니다. (이것도 확정은 아니고, 미정입니다. 제대로 만들고자 하면 너무 어렵고 복잡해지네요 😅 )
외에는 캐시전략, 스케줄러, 대기열 등.. 고민 중이네요.
물론 DDD, 클린 아키텍처도 만들고자 하는 강의 주제 후보군에 있습니다.
애초에 본 강의에서도 해당 방법론 적용하여 개발해볼까 싶기도 했는데,
"대규모"라는 초점을 벗어나는 주제에 대해서 설명할 내용이 많아질 것 같더라고요.
수강생 분들도 "대규모"를 배우러왔는데 다른 방법론에 초점이 맞춰져있는게 당황스러우실 수 있을 것 같았고, 괜히 익숙치 않은 개념에 고생할 것 같더라고요.
사실 이러한 방법론들은 저도 복잡한 시스템을 지속적으로 개발 및 개선하면서 뒤늦게 와닿던 부분이 있어서..
한시적으로 진행하며 간단할 수 밖에 없는 강의 수준의 요구사항에 적용하면서 납득 가능한 수준으로 설명하는게 정말 어려울 것 같더라고요..!
그래서 본 강의에서 "도메인"이란 용어 조차도 일부러 사용하질 않았던 것이네요.
이 부분은 과연 제가 잘 만들어낼 수 있을지 계속 고민해보겠습니다!
근데 요즘 본업도 바쁘고 강의 준비도 쉽지 않아서, 다음 강의가 언제 오픈될 수 있을지는 모르겠네요.. 😅
미취업자(취준생)에 비해서 중-고급 경력직은 그렇게 많지 않아서 강의 수요가 적기도 하고 각자 나름의 위치에서 배운 self best practice가 있어서 그들만의 생각이나 태클이 들어올 수 있을 것 같은데..
이런저런 이유에도 불구하고 이런 귀한 중고급 강의를 내주셔서 정말 감사합니다!
저야말로 귀한 시간과 비용 내주시며 강의 수강해주셔서 감사합니다!! 😄
취준생 시절 항상 초급 강의만 있고 중고급 강의가 없던게 아쉬웠던 것 같아요.
초급 강의나 책에서는 매번 똑같은 게시판 CRUD만 개발하고,
중급 강의도 실무 개발보단 대부분 프레임워크 이론에만 치우쳐져있고,
그렇다고 마땅히 실무 관점에서의 고난이도의 강의는 잘 없고(개인적으로 쿼리를 꼭 먼저 살펴보는데, 대부분 인덱스 조차 제대로 다루지 않는..)
막상 어려운 책은 특정 주제에 대해서만 깊게 들어가기 때문에 갑자기 뜬금없이 어려워지고,
대기업에서 대규모는 요구한다지만 그래서 그게 뭐고 어떻게 다루는지?
CS랑 어떻게 접목시켜내는 건지?
이런 것들이 정말 가려운 부분이었고,
이러한 강의가 있었으면 좋았을 것 같아서 만들어보았습니다.
물론 제 강의도 만능은 아니고 부족한 부분도 많지만요..! (요즘에는 좋은 강의가 정말 많아졌더라고요)
"그들만의 생각이나 태클이 들어올 수 있을 것 같은데"
이 부분은 사실 저 보단 비교도 안될 정도로 잘하시는 분들이 하도 많아서 지금도 무섭긴 합니다.
혹여나 잘못된게 있다면 괜한 비판이 들어오진 않을지 걱정되는 부분도 있습니다.
근데 어차피 정답은 없는 것이고, 건전하게 피드백 받으면 오히려 저도 배울 수 있는 것이라고 좋게 생각하려고 합니다..! ㅋㅋㅋ
질문 남겨주신 것 보니 공부도 많이 하시고, 직접 고민도 많이 하시는 분이라는게 느껴지네요.
혹시 궁금한 점 더 있으시면 편히 문의주시고, 앞으로도 편하게 질문 주세요!
남은 강의도 화이팅입니다!
답변 감사합니다!!
저도 정답은 없다고 생각합니다(No Silver Bullet)
특히나 큰 규모일수록 다양한 방법이 나오고.. 모로가도 서울로 가면 되니깐요!
맞는 말씀, 좋은 말씀들 다 감사합니다
24년에 회사다니면서 인프런 41개 강의를 완강할정도로 열심히 했습니다!!
배움에는 비용을 아끼지 않아서 쿠케님 강의라면 꾸준히 다른 강의도 신청할 것 같습니다 🙂
나중에 개인적으로 쿠케님과 커피챗이나 링크드인으로 대화할 기회가 생겼으면 좋을것같아요..!! ㅎㅎ
전 주니어 개발자입니다!