Q&A
우선 얼마나 정합성이 필요한지가 핵심이라고 생각합니다! 만약 해당 로직 비슷한 부분이 중요한 개념에 대해서 조회하는 것 이라면 findByCategory에 해당하는 함수를 한 트랜잭션으로 묶어야한다고 생각합니다 (read-only를 보냐는 다른 상황의 문제) 다만 현재 기준으론 데이터 소스가 하나기에 애초에 read-only를 쓰건 안쓰건 큰 차이가 없다고 보기도합니다 그치만 실무에서는 보통 마스터 디비와 읽기 복제본들이 존재하고 어디를 읽을지에 따라 데이터 정합성이 깨질 가능성이 존재하기 때문에 그런 부분은 유의해야한다고 생각합니다 여러 얘기를 적었지만 read-only를 쓰는 경우는 요구사항/트래픽/인프라/비즈니스 등 여러가지 상황에 따라 맞춰서 쓴다고 봐주시면 좋을 것 같습니다!
Q&A
프로젝트 도메인 마다 다르겠지만 일반적으론 test api로 구현해도 충분하다고 생각합니다
Q&A
안녕하세요 질문 감사드립니다 해당 부분은 개념들의 전파 기준을 어디까지 가져갈지 + 로직 응집에 대한 전략 결정이 필요한 부분입니다. ReviewPolicyValidator 에 이미지 삭제에 대한 로직이 들어가게 되면 imageHandle이 전달되어야합니다 그리고 자연스레 reviewImageRepository 에 대해서도 알아야하겠죠, 이런 부분을 어디까지 통제할 것 인가에 대한 결정이 필요한 것입니다 더 나아가서 지금은 ReviewService 에 reviewPolicyValidator -> reviewManager 흐름이지만 장기적으로 중간에 어떠한 로직이 추가 될 수 있을텐데요, 이때 imageHandle 이 오염될 가능성도 있을 것 같습니다 (일반적인 경우는 아닐 것 같습니다만, 신고 리뷰, 제제 리뷰 등등.. 삭제 불가한 경우라던가에 대한 상상입니다) 그럴 경우 validate 와 update 사이가 점점 멀어지게 되고, 그러다보면 검증과 실행이 차이가 있는 문제가 생길 수도 있을 것 같습니다 그치만 그것 때문에 manager에 검증 로직이 있는게 타당해지지는 않습니다. 결론적으로는 우리가 개념들을 어떻게 핸들링하고 어떻게 경계를 지을지가 핵심이라고 생각합니다 그런 의미에서 지금 기준으론 reviewPolicyValidator에 있어도 무방하다고 생각합니다 지금 Manager에 해당 예외처리가 남아있는 이유는 실제 행위 로직과의 응집도 를 지키지 위함이라고 이해해주시면 좋을 것 같습니다. 추가로 ReviewPolicyValidator.validateUpdate 의 역할은 정의 된 리뷰 업데이트 정책을 준수 했는지 검증 하는 것 입니다 그 관점에서 이미에 대한 것은 리뷰 업데이트 정책 보다는 리뷰 업데이트 중 발생하는 상태 에 가까운 것 같다는 생각도 듭니다 그래서 정답은 없으니 여러 방향으로 고민해보시면서 개념과 컴포넌트들의 형태를 고민해보시면 좋을 것 같습니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q&A
안녕하세요 질문 감사드립니다 해당 부분에 대한 느낌들은 이력서 강의와 포트폴리오 강의에서 다루고있지만 간략하게 답변드리면 이력서는 나의 경험과 이력을 함축해서 담은 문서라고 생각합니다, 그래서 너무 길면 안된다고 생각하구요 디테일한 설명 보다는 나를 보여줄 수 있고, 검토자들이 혹 할 수 있는 항목과 요소를 넣는 것이 중요하다고 생각합니다. 경력기술서(포트폴리오)의 경우는 이력서에 적힌 내용에서 좀 더 상세하게 적혀있어도 된다고 생각합니다 다만 제 경험에도 그렇고 평균적으로 검토자들이 이력서가 별로라면 경력기술서를 깊게 보지 않는 경우가 많은 것 같습니다, 그래서 이력서가 가장 중요한 문서라고 생각 됩니다 추가적으로는 이력서의 내용과 경력기술서의 내용이 너무 중복되지 않게 하는게 중요하다고 생각합니다. 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q&A
안녕하세요 질문 감사드립니다 해당 내용 앞 부분에 말씀드렸는데 빠르게 지나가서 설명이 좀 부족한 부분이 있네요! 지금 코드 기준으로는 프레젠테이션 레이어에 클라이언트를 위한 로직들 이있고 그 코드들을 백엔드가 직접적으로 알고 있는 형태 입니다 만약 시스템 설계적으로 프론트단에 SSR서버가 있거나, BFF 서버 같은 것이 존재한다면, 지금 현재 우리 코드가 가지고 있는 클라이언트를 위한 로직을 그 쪽 서버로 옮겨놓을 수 있다는 의미였습니다 그렇게 되면 백엔드 API자체는 외부 UI/UX 변화에 직접적인 영향을 훨씬 적게 받는 구조가 될 수 있고 그 만큼 순수함을 가지고 있을 수 있는 구조가 되는 것 입니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q&A
안녕하세요 질문 감사드립니다 우선 2년 정도 지난 상황이면 검토자 입장에서 경력이 완전히 살아있는 것 처럼 보여지지는 않습니다 다만 3년이 넘어가면 아예 시간적인 거리가 길어보이는데 2년은 그래도 가까운 편으로 보여지기 때문에 이력서 자체에는 적절히 넣는게 좋을 것 같구요 다만 기간을 떠나서 업무 경력에 대해서 보여주실게 없는 상황이라면, 최대한 추출을 해보는게 우선이겠고 그럼에도 정말 업무 내용이 없는 수준이라면 개인 프로젝트에 힘을 주는 것도 좋은 전략이 될 수 있을 것 같습니다. 일단 적어주신 것만봐서는 회사 경력이 2곳정도인데 다 6개월씩만 다닌 상태에, 마지막 회사에서 퇴사한지 2년 정도 된 상태라면 유효한 경력으로 보여지기 어려울 수 있을 것 같습니다 그치만 만약 퇴사 후 2년의 시간 동안 구직을 못한 배경이나 상황 등이 있고, 근거가 존재한다면 어느 정도 납득은 시킬 수 있지 않을까 싶습니다, 그 부분도 체크해보시면 좋을 것 같습니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q&A
안녕하세요 질문 감사드립니다! 단순히 적어주신 문장만으로는 상황이 전체가 그려지지 않고 어필이 되기 어렵다고 생각합니다, 걱정하시는 부분 처럼 비춰질 가능성도 있어보이구요 결국 저 내용을 어필하고자 한다면 혼자 몇 시간을 헤맸을 때 왜 시간을 혼자 써서 헤맸는지, 의도가 있었던건지, 상황이 있었던건지, 또 그 과정 속에서 내가 깨달은 것, 고민했던 것 이런 내용들이 들어가야한다고 생각합니다 핵심은 내가 어필 하고자 하는 내용을 추출해내서 강조하는 것 이라고 생각합니다 그 관점으로 적으시려했던 경험을 곱씹어보시길 추천드립니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q&A
안녕하세요 질문 감사드립니다! 일단 면접관들은 이력서를 적든 많든 무조건 보고옵니다, 그 상황에서 면접에서 자기소개를 해달라했을때에 이력서를 읽는 수준의 자기소개라면 마이너스까진 아니더라도 궁금증이나 추가적인 포인트 점수는 "0" 이라고 생각합니다 그래서 저는 멘토링이나 일반적으로 말씀을드릴때에는 자기소개를 기존 이력서에 있는 내용을 확장한 버전 (그러니까.. 대략 이력서 자기소개랑 뉘앙스는 어느정도 맞으면서 더 풍부하고 궁금증을 만들 수 있는 내용을 첨가한버전)을 준비하는 것을 권장드립니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q&A
덕분에 출간 소식을 알게되었습니다 감사합니다!ㅎㅎ
Q&A
엥??? 저도 아직 나왔단거 못 들었는데 어디서 보셨을까요!?😳ㅋㅋㅋㅌ 감사합니다!
