173만명의 커뮤니티!! 함께 토론해봐요.
미해결
따라하며 배우는 리액트 A-Z[19버전 반영]
npx create-react-app 이렇게 만들면 src폴더 없이 만들어지더라구요 그래서 그냥 npx 없이 만드니까 정상적으로 잘 만들어지는데 npx가 있는거와 없는거의 차이점이 뭔지 궁금합니다
미해결
따라하며 배우는 리액트 A-Z[19버전 반영]
useParams를 이용한 영화 상세 페이지 구현 파트 8분 45초에서 css 파일을 불러오지 않고도 modal__poster-img 클래스 이름을 부여하자 스타일이 반영되는 것을 확인할 수 있었습니다 왜 이렇게 되는 걸까요?
미해결
Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트
안녕하세요 ! 도메인과 영속성 객체 구분하기 수업에서 1분 34초에서 UserEntity 에 있는 행을 복사하는데 이 때 나오는 단축키가 궁금합니다.
미해결
Practical Testing: 실용적인 테스트 가이드
안녕하십니까 강사님. 저는 이제 5개월차가 된 신입? 백엔드 개발자 입니다. 다름이 아니라 , 생성과 수정 API에 대한 응답으로 어떤 정보까지 넘기는것이 적합할지 에 대해 고민을 하던 도중 강사님의 생각을 여쭤보고 싶어 질문을 드리게 되었습니다. Q1. 강사님 께서는 생성, 조회 , 수정, 삭제 API의 응답을 각각 어떻게 보내시는지 여쭤보고 싶습니다. 가장 먼저 조회의 경우는 말 그대로 path의 Entity 및 관련된 Entity 정보를 조합하여 응답 DTO로 변환하여 보내고 있습니다. 그런데 나머지 Write Operation에 대한 응답을 어디까지 보내야 하냐가 이슈 입니다. 예를들면 엔티티의 생성의 경우 엔티티의 응답 DTO를 보내면 - 프론트에서 별도의 조회 API 호출 없이 바로 프론트가 화면에 뿌려줄 수 있으니깐 저는 생성의 경우에도 조회와 마찬가지로 Entity의 정보를 조합하여 응답 DTO로 변환하여 보내고 있었습니다. 그런데 이러한 부분이 Command Query Sperate 원칙에 어긋나는것 같아, 강사님께서는 혹시 생성한 Entity의 Key만 보내시는지, 아니면 Entity의 정보를 DTO로 변환하여 보내시는지 궁금합니다. 만약 정보를 다 보내신다면 이후에 별도로 조회API를 호출해야 하고 그 또한 비용일텐데 이러한 부분은 어떻게 하시는지 여쭤보고 싶습니다. 이제 수정 API인데요, 제가 다룬 비즈니스 로직의 경우 수정 비즈니스 로직이 다양하고 , 각 비즈니스 로직의 경우 다뤄지는 Entity의 종류가 다른 경우였습니다. (중심 Entity는 동일하지만, 연관된 Entity를 누구까지 건드리냐의 차이) 그래서 응답으로 보내기 모호한 점이 첫 번째 이유이고, 애초에 수정 후에 프론트 화면에서 그 엔티티의 정보를 보여줄 필요가 없어서 라는 두번째 이유에 의해서 에초에 엔티티의 Id값도 보내지 않고 있었는데요, 이 수정 API의 응답을 성렬님은 어떻게 진행하지는지 그 이유가 궁금합니다. 마지막으로 삭제의 경우는 정말, 프론트에게 보낼 응답이 없어도 되는 경우 라고 생각했는데요, 팀장님의 의견은 만약에 나중에 삭제한 Entity를 복구하는 요구사항이 추가되는것을 고려하여 Id 정도는 넘기자는 의견을 내어주셨습니다. 마찬가지로 삭제의 경우도 어떤식으로 수행하시는지 그 이유가 궁금합니다. Q2. 마지막으로 Entity의 ResponseDto의 필드를 어떤식으로 구성하시는지 궁금합니다 예를들면 저의 경우는 API는 프론트와 서버 간의 스펙이라고 생각하고, Entity의 단건조회의 경우는 단건 조회용 ResponseDto를, 전체조회의 경우는 전체 조회용 SummaryResponseDto를 별도로 만들어서 사용하고 있었습니다. (이런식으로 각 상황별 ResponseDto를 별도로 정의하고, 그 안에 관련된 Entity들의 필드를 직접 풀어넣는 방법) 저희 팀장님 께서는 프론트쪽도 일을 해오시다가 , 백엔드쪽 분야로 전향하신 케이스 인데요, 그렇다 보니 어떻게 해야 프론트의 생산성이 올라가는지를 고려하시는 분 이셨고, 팀장님의 생각은 서버에서 넘겨주는 응답에 일관성이 있어야 그 응답을 사용하는 프론트 측도 학습이 되고 놓치는 부분 없이 생산성이 올라간다는 의견이셨습니다. 그래서 Entity별로 당장 사용하지 않더라도 가능한 모든 필드를 담은 ResponseDto를 하나만 만들고, 해당 ResponseEntity의 조합으로 각 API별 응답 Dto를 만들어서 사용하면 , 프론트 측 에서는 일관성 있는 응답값을 사용할 수 있다는 의견이셨습니다. 물론 이 방법이 네트워크 패킷의 양을 쓸데없이 증가시킨다는 것을 알고 계시면서도, 생산성에 큰 영향을 미치는 부분이라고 생각하셨습니다. 예를들어 다음과 같이 각 Entity의 응답 Dto의 조합별로 API의 ResponseDto를 만들 수 있습니다. ResponseDto{ UserDto{ id : 1, name : “aaa” … // User엔티티의 거의 모든 필드 } ItemDto{ id : 2, name : “bbb”, … // Item엔티티의 거의 모든 필드 } } 저는 이러한 부분에 대해 생각해 본 적이 없이, 그냥 제가 “해당 API를 호출하는 화면에서 필요한 정보들만을 담아 |(혹은 여러 화면에서 쓰인다면 여러개를 고려) ResponseDto를 각각 만들어서” 넘겼는데요 강사님께서는 이러한 ResponseDto를 구성하는 부분에 있어서 상황별로 필드를 재구성 하여 ResponseDto를 정의하여 사용하시는 편 인지 아니면 생산성을 고려하여 각 Entity별 Dto를 만들고, 이들을 조합하여 ReponseDto를 정의하시는 편 이신지 혹은 다른 규칙이 있으신지 궁금합니다. 물론 그렇다고 , 팀장님의 의견에서 전체조회시 사용하는 DTO와 단건조회시 사용하는 DTO가 동일하더라도, 전체조회 후 단건조회를 기존 Front가 가지고 있는 값을 그대로 쓰지 말고., 단건 조회용 API를 다시 호출하자 입니다! 그저 핵심은 프론트가 다루는 ResponseDto의 일관성을 위해서 입니다 (결론은 생산성을 위해) 항상 좋은 강의, 그리고 무엇보다도 강상님의 의견과 고민을 강의에 녹여주셔서 정말 감사할 따름입니다. 덕분에 함께 고민하고 많이 배우는거 같습니다. 긴 글 읽어주셔서 감사합니다!
미해결
Practical Testing: 실용적인 테스트 가이드
안녕하세요. 강의 잘 보고 있습니다. 요청 객체를 테스트(ex. 신규상품을 등록할때 타입은 필수 값이다.) 할 때에 코틀린을 사용하는 경우 productType은 non-nullable 입니다. data class ProductCreateRequest( @field:NotNull(message = "상품 타입을 선택해주세요.") val type: ProductType, @field:NotNull(message = "판매 상태를 선택해주세요.") val sellingStatus: ProductSellingStatus, @field:NotBlank(message = "상품명을 입력해주세요.") val name: String, @field:Positive(message = "상품 가격을 입력해주세요.") val price: Int, ) 이런 경우 enum 타입은 bean Validation에서 NotNull이나 NotBlank에 대한 테스트는 불가능한 상태인데요. 이렇게되면 테스트 가능한 것들만 하는게 맞는건가요?
해결됨
스프링부트 JUnit 테스트 - 시큐리티를 활용한 Bank 애플리케이션
DummyObject 클래스의 newUser와 newMockUser 메서드 용도가 헷갈립니다.. newMockUser 는 테스트할 때 Mock환경에서 User객체를 간편하게 만들기 위해 따로 만든 메서드인가요 ? newUser는 용도를 잘 모르겠어요
해결됨
스프링부트 JUnit 테스트 - 시큐리티를 활용한 Bank 애플리케이션
bank.dto.user 패키지안에 req, resp 패키지를 만들어서 각각 DTO 클래스를 추가하는것과 선생님이 하신 UserReqDto , UserRespDto 에 이너클래스로 추가하는건 무슨차이가 있나요 ???
해결됨
스프링부트 JUnit 테스트 - 시큐리티를 활용한 Bank 애플리케이션
제가 선생님 포토그램 강의를 들을 때는 엔티티클래스 위에 @Builder 어노테이션을 붙혔는데 이번강의에서는 엔티티클래스 내부에 생성자를 만들고 생성자메서드 위에 @Builder 어노테이션을 사용한 이유가 있을까요 ?
미해결
Practical Testing: 실용적인 테스트 가이드
좋은 강의를 찍어주셔서 너무 감사합니다. 덕분에 테스트에 접근하는 방법을 터득할 수 있었습니다! 컨트롤러 테스트는 Validation 역할이 핵심이라고 이해했는데, @Valid 어노테이션을 부착한 DTO 검증만 강의를 통해 배웠습니다. 궁금한게 있습니다. 시큐리티를 적용했을 때 저는 컨트롤러 메서드 매개변수에 Authentication을 이용해서 SecurityContext 값을 사용하는데, 이러한 SecurityContext도 검증을 해야 되는지, PathVariable에 대한 검증도 필요한가요? Param값 검증도 필요한지 궁금합니다. 페이징했을 때 페이징 결과도 검증을 해야 될까요? Validation 영역이 아니라고 판단되어지는데, 강사님의 의견이 궁금합니다! 감사합니다.
미해결
실전! 스프링부트 상품-주문 API 개발로 알아보는 TDD
이 화면에서 단축키 ctrl + esc 만 누르면 시작 화면이 자꾸 떠서 단축키 등록이 안돼요..
미해결
Practical Testing: 실용적인 테스트 가이드
강의에서 RequestDto를 Builder 패턴으로 생성자를 만들어주셨는데 그렇게 생성하신 이유가 있을까요?? 코드에서 확인해보면 이 생성자를 사용하지 않는걸로 확인이 되는데 .. 제가 추측하기로는 그 이후에 확장성을 위해서?,,, 라고 추측을 해봤는데 다른 이유가 있을까요????
미해결
Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트
Domain -> Response 변환 코드를 Domain에 정의해두고 Controller에서 Domain 메서드를 호출해서 Response를 변환하는게 맞나는 건 이해했습니다. 근데 실제 API에 해당 내용을 적용하려고 보니 Domain 단 건 조회보다는 List<Domain>을 반환하는 경우가 훨씬 많았습니다. 따라서 List<Domain>을 List<Response>로 변환해야 하는데 해당 작업을 for문이나 Stream으로 Controller로 처리하려니 Controller 코드도 지저분해지고 Controller가 하는 역할에 부합하지 않게 되는 것 같습니다. List<>를 변환할 때는 어디서 하는게 올바른 것인지 질문드립니다!
미해결
스프링부트 JUnit 테스트 - 시큐리티를 활용한 Bank 애플리케이션
굳이 authenticationEntryPoint 에 들어갈 내용을 CustomREsponseUtil 로 빼는 이유가 무엇인가요 ?? 실무에서는 따로 뺄 만큼 들어가는 내용이 길어지나요 ? ?
미해결
실전! 스프링부트 상품-주문 API 개발로 알아보는 TDD
강사님이 생각하시는 POJO란 어떤 방법론인가요?? 시중에 나와있는 설명으로는 용어가 잘 와닿지 않아서요!!
미해결
따라하며 배우는 리액트 테스트 [2023.11 업데이트]
안녕하세요. 리액트 테스트 관련 좋은 강의를 제공해주셔서 감사합니다. 수업 듣고 테스트 코드를 작성 시에 console.error로 wrapped in act 오류가 표시되어 문의드리게 되었습니다. 여러 질문들도 찾아보고... 구글링도 해보며 방안을 찾아서 테스트코드가 성공하는 것 까지는 봤으나, 로그에 첨부드리는 이미지와 같이 표시되어지고 있습니다... useEffect에서 state변경시에 발생되는 것 같은데.. 이부분은 어떻게 처리해야할가요..?ㅠ 며칠을 찾아보고.. 제공해주신 소스코드도 확인해봤지만... 다른 부분이 없어 문의드립니다. (추가로.. 첨부 주신 코드의 리액트버전을 제가 구성하는 버전으로 구성 후 테스트 진행 시에 저와 동일한 결과가 나오는 것을 확인했습니다.) 감사합니다.
미해결
따라하며 배우는 리액트 A-Z[19버전 반영]
[JSX Key 속성 이해하기] 파트에서는 todoData에 map 메서드를 사용할 때 this.todoData.map((value) => ( <div style={this.getStsyle()} key={value.id}> <input type="checkbox" defaultChecked={false} /> {value.title} <button style={this.btnStyle}>X</button> </div> )) 로 return 없이 사용하셨는데 전 기존에는 this.todoData.map((value) => { return ( <div style={this.getStsyle()} key={value.id}> <input type="checkbox" defaultChecked={false} /> {value.title} <button style={this.btnStyle}>X</button> </div> ) }) 이렇게 사용했습니다 둘다 정상 동작하는데 차이점이 뭔지 궁금합니다
미해결
Practical Testing: 실용적인 테스트 가이드
안녕하세요 우빈님! 빌더 패턴 사용 시 생성자 검증을 어떻게 하는 것이 좋을까에 대한 질문을 드리고 싶습니다..! 변경 가능성이 있는 도메인 검증을 진행 할 때 빌더 패턴이 적용 된 private 생성자에서 검증을 진행하나요? 저 또한 정적 팩토리 메서드를 즐겨썼었는데 Builder를 사용하고나니 어느 위치에서 검증을 하는게 좋을까에 대한 의문이 생기더라구요. 기본적으로는 보통 정적 팩토리 메서드에서 생성자 검증을 진행하게 되면 도메인에서 검증을 위한 private 메서드가 전부 static이 되어야하는데 이게 옳은가? 라는 의문이 들기도 하고 그렇다고 private한 빌더 쪽에 생성자 검증을 하려고 하니 외부 세계에 영향을 받는 가령 클라이언트로 부터 입력받은 시간이 현재 시간 이전 일 수 없습니다. 라는 테스트를 수행해야 할 때 외부로부터 계속해서 LocalDateTime.now () 를 전파받아서 구현을 해야하는데 이 필드를 생성자에 추가하는 것도 아닌 것 같고.. 이러한 고민 속에서 결국 생성자에서 진행됐어야 할 검증을 서비스 로직에서 도메인의 검증 메서드를 따로 호출하였는데 서비스 로직에서 검증 메서드를 호출하는 것 또한 좋은 방법은 아닌 것 같다는 생각이 들었습니다. 이러한 상황에서 우빈님은 보통 어떤 방식을 택하시는지 궁금합니다 ㅎㅎ
미해결
스프링부트 JUnit 테스트 - 시큐리티를 활용한 Bank 애플리케이션
안녕하세요 강사님. 현재 강의를 듣고 로그인과 회원가입은 서버에 구축하는 것으로 이해하였습니다. 혹시 로그아웃의 경우에는 어떻게 처리를 해줘야 하는건지 궁금합니다. 현재 강의에서 쓴 코드를 백엔드로 쓰고, 프론트엔드는 리액트를 한번 사용해서 로그인했을떄 반환하는 토큰을 저장하려고 하는데 로그아웃 버튼을 눌렀을 떄는 어떻게 처리해야하는지 궁금합니다...! 로컬스토리지에서 토큰을 지우는 작업만 하는지, 아니면 서버에서 처리해줘야 하는지와 구현 방식도 혹시 가르쳐주실수 있으면 조언 주시면 너무나 감사하겠습니다.. 좋은하루되세요!!!
미해결
Java/Spring 주니어 개발자를 위한 오답노트
교정하면 Service Class에서 Repository를 이용해서 Member를 가져옵니다. Repository는 MemberEntity를 Member로 변환한 도메인 모델을 반환해야 합니다. 서비스는 MemberEntity를 알지 못해야 합니다. 이렇게 말씀해주셨는데 1 .이렇게 분리하는 이유는 서로의 결합을 낮추기 위해서인가요? 이렇게 분리를하면 어쩔수없이 서비스 메서드 안에 도메인클래스로 변환하는 로직이들어가 오히려 코드가 길어져서 가독성을 해치지는않나요? 현재 저는 서비스에서 레파지토리에서 엔티티를 가져온후 dto 객체로 변환시켜서 (바로 변환을 시키거나 어셈블리라는 클래스를 만들어 여기서 변환 작업을 따로해주는 객체를 만들거나) 컨트롤러로 넘겨줍니다. 보편적으로 이방식을 많이했는대 따로 도메인 클래스를 생성해서 변환해서 비즈니스로직을 처리하고 dto 객체로 넘겨서 컨트롤러로 전달하는지 왜? 이런건지 좀더 자세히 설명해주시면감사하겟습니다 ( 제가 수업을 좀더 열심히듣지않아 질문이 무례한게있음 용서해주세요 ㅠ ㅠ)
해결됨
Practical Testing: 실용적인 테스트 가이드
안녕하세요! 우빈님. 테스트 강의에서 많은 인사이트를 얻고 갑니다! 작은 고민이 하나 있는데요! 우빈님은 어떻게 생각하시는지 궁금하여 여쭈어봅니다! 바로 도메인 객체에서의 null 검증인데요! BeanValidation을 통해서 Presentation에서 검증을 하더라도, 도메인 단에서 또 null 검증을 해주어야 하는가 에 대한 질문입니다. 팀원들과 팀플을 하다보면 @NotNull 을 이용하여 Presentation 단에서 검증이 될텐데, 도메인에서도 null 검증을 해주어야 하는가!? 에 대한 질문을 많이 받습니다. 개인적으로 저는 Presentation 단에서 검증이 되더라도 실제로 객체가 생성될 때 까지의 일련의 과정들 속에서 객체에 온전한 값이 들어가지 않을 것 같아 null 체크 또한 해주는 것이 안정적인 코드를 만들어 줄 수 있다고 생각하는 편인데요! 이러한 작업들이 그래도 비용이 들어가는 측면이라, 개발 속도에 영향을 미쳐서 그런지 선호하지 않는 분들도 종종 만났던 것 같습니다! 혹시 우빈님 생각은 어떤지 의견을 한 번 여쭈어보고 싶습니다
