안녕하세요 강사님, 강의 잘 보고 있습니다. 이동 로직을 정리하다가 보호(가드) 로직 중복에 대해 질문드립니다.현재 구조에서 Game.tryMove()에서 player.canMove(dir)로 먼저 확인하고, Player.move(dir) 내부에서도 canMove(dir)를 다시 확인하여 막습니다.즉, 이동 가능 여부 판정이 두 번 수행됩니다.// Game private void tryMove(Direction dir) { if (player.canMove(dir)) { // 1차 player.move(dir); // 내부의 2차 showRoom(); } else showBlocked(); } // Player public void move(Direction dir) { if (!canMove(dir)) throw new IllegalArgumentException(); this.position = this.position.shift(dir); } 두 번의 가드가 필요한 이유가 있을까요? SRP/TDA 관점에서는 Game의 판정을 제거하고 player.tryMove(dir)만 호출해 결과만 처리하는 패턴이 더 적절한지, 혹은 move()만 두고 예외로 제어하는 방식을 권장하시는지 궁금합니다. 

안녕하세요. 좋은 강의 감사합니다. 덕분에 객체지향에 대한 이해가 많이 정리되었습니다.3-2 강의를 보다 메서드 크기 관련해서 궁금한 점이 있어 질문드립니다.콘솔 입력 의존성(12:17) 부분에서 입력을 분리하는 예시로 아래와 같이 nextLine() 호출을 별도 메서드로 추출하신 것으로 이해했습니다.private String input(){ return Scanner.nextLine(); }그런데 이 관점이라면, 입력 “수집(I/O)” 뿐 아니라 “입력 파싱(문법)”도 별도의 책임으로 분리해야 하는 것 아닌지 고민이 됩니다. 예를 들어:private String[] inputParsing(String input){ return input().toLowerCase().trim().split("\\s+"); }강사님의 강의 및 "객체지향의 사실과 오해" 책을 읽고 난 뒤, SRP의 책임을 ‘하나의 변경 이유’로 보았습니다.위의 콘솔 입력(nextLine)을 분리한 건 입력 장치 변경이라는 액터에 대한 책임 분리로 이해했습니다.그렇다면 입력 파싱(toLowerCase/trim/split)은 명령 문법 변경이라는 또 다른 액터에 대한 책임이므로, 이 역시 별도로 분리해야 SRP를 완전히 지키는 게 아닐까요? 물론 이렇게까지 분리하면 가독성이 떨어질 수 있고, 실제로는 변경 가능성도 낮아 “가치가 작은 분리”로 느껴지기도 합니다. 강사님의 의견이 궁금합니다!+ 외에도 추상화 수준을 맞추기 위한 메서드 추출(9:25) 강의 자료에isRunning 함수의 반환이 void로 되어있으나 실제 내부에선 running == true를 반환합니다. github 코드 상에는 해당 함수가 없어보입니다.

강사님, 강의 잘 듣고 있습니다.강의 중 jest에서 한글로 적을 때는 test, 영어로 적을 때는 it으로 적는 게 가독성이 좋다고 설명해주셨는데, 실무 팀에서는 이런 네이밍 컨벤션을 어떻게 정하고 유지하는지, 혹시 Prettier, ESLint 같은 도구로 특정 스타일(예: test만 사용)을 강제하는 경우도 있는지 궁금합니다.

안녕하세요. 좋은 강의 감사합니다.값 객체에 대한 내용을 듣고 궁금했던 점이 있었는데, 섹션 4 퀴즈를 풀면서 해소되는 동시에 새로운 질문이 생겼습니다.값 객체를 사용하는 메소드를 과도하게 호출하여 OOM(Out of Memory)이 발생할 것으로 예상되는 경우, 이를 어떻게 회피할 수 있는지 궁금합니다.아직 강의를 전부 듣지 않아서 이후에 나올 내용일 수도 있겠지만, 지금 드는 생각으로는 Map을 이용해 내부적으로 캐시를 구현하여 메모리 사용량을 줄이는 방법이 떠오르는데, 이 접근법이 맞을지 궁금합니다.

선배 개발자로서 알려주시는 강의 내용들이 정말 좋았는데요, 그와 더불어 앞으로 주니어 백엔드 개발자로서 어떤 역량을 조금 더 집중해서 키우면 좋을지 조언을 부탁드리고 싶습니다.또, 아직 이를 수도 있지만 이직을 준비할 때 도움이 될 만한 공부 방향이나 추천해주실 만한 책이 있다면 알려주시면 감사하겠습니다. 강의 중간중간 소개해주시는 책들이 많아서 최근에 또 추천해주실 책이 생기셨는지 궁금합니다.

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요. 안녕하세요.좋은 강의 재밌게 수강하고 있습니다!강의를 들으면서 의식적으로 테스트 코드를 작성하기 위해 노력하고 있습니다.  학습하다 보니 테스트 코드에 대한 부분을 정량적인 지표로 활용할 수 있는 커버리지라는 지표가 있다는 것을 알게 되었는데요. 제가 개발하는 부분은 도메인이 복잡한 프로젝트는 아니다 보니, 주로 Service Layer와 Presentation Layer 위주로 작성하게 되더라구요. queryDSL이나 native query를 이용해 복잡한 쿼리를 작성하게 되면, 가끔 Persistence Layer까지 작성하게 되는 것 같습니다. 그러다 보니, 도메인 패키지가 아닌 Config 등 global 패키지에 존재하는 코드나 Persistence Layer의 테스트 코드가 커버리지가 낮고, Persistence Layer의 커버리지도 낮아서 그런지 보통 프로젝트의 라인 커버리지가 60% 전후를 기록하고 있는 것 같습니다. 우빈님께서는 커버리지를 어떤 식으로 활용하시는지 궁금합니다! 커버리지 자체를 신경쓰기 보다는 말씀해주신 대로 미래를 위해 의미가 있는 테스트 코드를 작성하고 싶은데, 커버리지도 활용하는 방법이 있는지? 그리고 주로 어떤 레이어 위주로 테스트 코드를 작성하시는지 궁금합니다!읽어주셔서 감사합니다.

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요.  BDD 설명하시면서 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준을 권장한다고 하셨는데요  작성한 테스트를 따로 문서화 하기도 하시는지 궁금합니다!

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요.  단위테스트할때 항상 궁금했던 점이단순한 CRUD도 테스트코드를 구현해주는 게 맞는걸까요?JPA 기능을 그대로 적는? 느낌이 나서 굳이 필요한 테스트코드인가 하는 생각이 항상 드는데 왜 구현했는지에 대한 시나리오를 @DisplayName 적곤 하지만 뭔가 불필요하다는 생각이 가끔 들기도 하는데 다 적는 게 맞는거겠죠??

pdf의 17~18 페이지, 강의의 4:54Reader를 reader 패키지에서 game 패키지로 이동시켜 reader 패키지가 game 패키지를 의존하게 만들 수 있다고 하셨는데 패키지란게 Java의 기능인가요? 그렇다면 C++에 대응될 만한 기능이 있을까요?

강사님은 Classicist 쪽에 속하셔서 Service를 테스트할 경우 Repo도 포함한다고 하셨었는데 Controller에서는 MockMvc를 활용하셔서 따로 테스트한 것으로 알고 있습니다.컨트롤러 - 서비스, 레포지토리의 관계와 서비스 - 레포지토리의 관계에서 어떤 차이점 때문에 이렇게 구성하신 것인지 궁금합니다.

서비스를 소형 단위로 테스트하기 위해 Fake 클래스를 구현하는 실습을 진행하셨는데요.테스트 코드는 결국 구현된 기능이 정상적으로 동작하는지 검증하기 위한 것이라고 생각하는데요~그런데 H2 DB를 직접 띄워 테스트하는 방식과 비교했을 때, Fake 객체를 활용한 방식은 구현 방식에 따라 실제 동작과의 괴리가 생길 수도 있을 것 같은데, 이런 접근이 실제로 효과적인 테스트 방법인지 궁금합니다!

ERD 가장자리에 있는 도메인들은 선행적으로 존재해야하는 도메인들이 있다보니 테스트 코드 작성 시 given 부분이 너무 길어져요.어떻게 짜는게 좋은지 의견 부탁드립니다!!

좋은 강의 감사합니다. 강의를 들으면서 객체지향 설계 원칙에 맞춰 코드를 짜다보면 나중에 되돌아봤을때 의도했던 안했던 시중에 알려져있는 디자인 패턴과 유사한 방향으로 코드가 만들어질 것 같다는 생각을 했습니다. 강사님께서는 디자인패턴을 어떻게 바라보고 계시고 디자인 패턴을 의도해가며 구현할 때와 아닐때가 있으신지도 궁금합니다~!!감사합니다~!!

안녕하세요!AbstractReader로부터 파싱에 대한 책임을 분리하여 Parser라는 클래스를 새로 생성하는 내용 잘 들었습니다!여기서 궁금한 것이 생겨 질문 남깁니다..!DatabaseReader, RedisReader, FileReader / CsvParser, JsonParser, XmlParser 구성은 총 9가지의 경우의 수가 나올 수 있을 것 같은데요만약 '(DatabaseReader, XmlParser)는 불가능하고 (DatabaseReader, CsvParser)와 (DatabaseReader, JsonParser)가 가능하고,(RedisReader, XmlParser)와 (RedisReader, CsvParser)는 불가능하고 (RedisReader, JsonParser)만 가능하다' 와 같이 특정 조합이 불가능한 경우는 어떻게 컴파일 타임에 가능한 조합으로만 강제할 수 있을지 궁금합니다!

안녕하세요 e2e 테스트는 비용이 많이 들어서 어떻게 관리를 하는지 궁금합니다. - 파이프라인에서 매번 CI 에서 돌리기에는 서버나, 시간이 개발 생산성을 잡아 먹을 것 같은데요. 점점 e2e 테스트가 쌓여 나갈떄 어떤 전략을 취할 수 있는지 궁금해요. GPT로 리서치하니까 보통 2가지를 병행해서 스케줄러 + 온디맨드 실행 같이 관리 한다고 하는데, 실제 현업에서는 어떻게 활용하고 계신지, 제가 리서치한 내용 말고 더 효율적이거나, 추천할만한 전략 , 이외의 고려사항 소개해주실 수 있으면 알려주시면 감사하겠습니다.스케줄 실행 (Nightly/주말 풀스윗)EventBridge → ECS Fargate RunTask(Spot 가능) → Playwright 러너대상: 스테이징(or PR 프리뷰 URL)b. 산출물: 트레이스/비디오/리포트 S3 업로드, Slack에 요약/링크온디맨드 실행 (PR 코멘트/수동 트리거)Bitbucket Pipeline에서 aws ecs run-task 호출(또는 ChatOps 슬래시 커맨드)태그/폴더/샤드 인자 넘김 → 필요한 부분만

챕터 17 nox 테스트 중입니다. 테스트 환경은 윈도우11, 파이썬 3.11버전이고 공유주신 noxfile.py 의 tests 세션을 실행하던 중에 다음 에러가 발생하였습니다.  session.install("-e", ".") 실행중에 에러가 난것으로 보이는데 setup.py 나 pyproject.toml 이 없다고 나오는데 공유주신 자료에는 안보여서요.현재 프로젝트 파일 구조는 my_pytest / mycalc/my_pytest / tests /my_pytest / noxfile.pymy_pytest / requirements-dev.txt 로 되어 있습니다.  

class Controller, class Service, Interface Repository, class RepositoryImpl, Interface JpaRepository의 그림에서 Interface Repository 가 Persistence 가 아닌 Business 계층으로 분리하신 이유가 궁금합니다!

DTO의 검증 필드마다 테스트코드를 작성하는게 실무에서 일반적인가요? 이렇게 되면 DTO가 커질 수록 DTO 한개당 테스트 함수가 10~11개 이렇게 필드개수 만큼 나오게 될텐데 실제로 모두 테스트코드로 검증하나요?

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요. Business Layer 테스트(1)의 13:32초 즈음에서 OrderCreateRequest가 Product의 id값이 아니라 productNumber를 요청 dto로 받았는데 그 이유가 있나요? 저라면 id를 받도록 설계할거같은데 이유가 궁금합니다. 실무에서는 보통 저렇게하나요? 

6-2. 명령 쿼리 분리 원칙으로 부수효과 관리하기에 관해 궁금한 점이 있어 질문드립니다! 명령과 쿼리 분리하기 14:43 ~해당 부분에서 Player의 move 메서드를 canMove라는 쿼리와 move라는 명령으로 분리했는데, 여기서 궁금한 점이 있습니다. Player는 이동 가능 여부에 대해 스스로 판단하고 그 결과에 따라 상태를 스스로 변경하는데, Game의 tryMove에서 성공과 실패에 대해 try-catch 구문을 사용하지 않고 if 분기를 사용하는 이유가 무엇인가요?저는 tryMove에서 canMove 쿼리 호출 없이 move 명령을 호출하고, 성공/실패에 대한 처리는 try-catch에서 예외처리하는 것이 더 간단하다 생각했습니다.이번 강의인 6-2의 Player와 8-2 아이템 이동 로직 개선 강의의 Transfer 객체 둘 다 동일한 구조로 코드가 짜여져있어 if 분기를 사용한 이유가 궁금합니다!현재 구조에서 Player의 move 메서드에 예외를 던지는 if 분기가 없다면 Game이 Player의 이동에 관련된 모든 것을 결정하며 TDA를 위반하는 코드라 생각합니다.그렇다면 if 분기는 TDA를 위반하지 않기 위해 넣은 것인가요? 아니면 Player 와 협력하는 다른 클라이언트가 canMove 호출 없이 move를 호출할 경우를 대비해 넣은 것인가요? 후자라고 생각하기에는 1번 질문처럼 Player가 스스로 판단할텐데 try-catch 대신 if 분기를 넣은게 잘 와닿지 않아 질문드립니다!