안녕하세요 제미니님 오랜만에 댓글 남겨봅니다. 제가 비전공자 출신이다보니 CS에 대해서 얄팍하게 알고 있습니다. 제미니님 경험에서 보았을때 CS의 학습 정도에 따라서 역량에도 반영이 되는 지 궁금합니다. 제미니님은 어떻게 CS를 학습하셨는지 궁금하고 비전공자가 그래도 CS를 공부했다는 걸 어떻게 어필하는 게 좋을지도 궁금합니다. 이력서에 쓰여질만큼의 업무가 있다면 문제가 없겠지만 그런 업무가 없을 수도 있을 거 같아서요!
오랜만에 댓글 주셨네요! 제가 관련해서 어떤 영상에선가 말했던 것 같은데 영상 제목을 못 찾겠네요 ㅠㅠ 뜨문뜨문 말했지만 한번 얘기해보면 좋은 주제인 것 같아서, 추후 영상으로 답변 드려보겠습니다! ----- 많이 고민 되실 수 있으니 간단하게만 적어보면,, - CS 학습이 역량에 영향을 주지만 전부는 아니라고 봅니다. (특수 시스템이 아닌, 일반 서비스 개발 기준) - 저 같은 경우는 업무를 하면서 학습한게 전부 같습니다 (첫 회사가 펌웨어 개발이라 더욱 접점이 컸음) - CS 어필은 결국 기술적 사고력과 이어지지 않을까 싶습니다, 업무가 CS 밀접하지 않아도 대화를 하다보면 알 수 있는 것 같아요
파사드 패턴 형식으로 여러 레포지토리를 참조 하여 일을 하는 Service 레이어 라고 생각하면 될까요 ?! 위 글이 맞다면 서비스 코드가 많아지면, 분할을 어느정도까지 해야할지 기준이 혹시 있으신가요 ? (예) 하나의 서비스에 기능이 10개 이상이면 나누는것을 생각해봐야 한다 ?
제 경우 Service는 클래스의 postfix이고 레이어로 말하면 비즈니스 레이어라고 보셔야합니다 비즈니스 레이어는 repository들을 참조하기 보다는 구현체 클래스들을 참조하는게 조금 더 바람직 하다고 봅니다, 말씀하신 수치로 나누는것을 정하기는 약간 애매한 부분이 많습니다 고정적 숫자보다는 책임이 과하거나 역할이 꼬여있다는 것들이 기준이 되면 좋을 것 같습니다
와 영상 감사합니다!
구현 레이어 컴포넌트들의 이름에 어떤 정해진 규칙이 있는게아니라 해당 컴포넌트의 책임에 가장 자연스러운(?) 이름을 지으면 되는군요!
제가 제미니님의 코드를 완전히 따라하려고 너무 얽매여있던건 아닌가하는 생각이드네요 ㅋㅋ 깨달음 감사합니다
맞습니다! 역할과 책임 기준으로 지으면 됩니다!
말씀해주신 것 처럼 제 코드를 따라하시면 안되고 생각하는 느낌을 잘 느껴보셔야합니다! 도움이 되었다니 다행이네요!😁
@@geminikims일단, 선좋아요!
안녕하세요! 당연할 수 있겠지만.. 팀원들과 같이 개발하는 프로젝트의 경우 예시로 보여주신 finder, reader 등을 컨벤션으로 역할을 정해놓고 개발을 해야할까요??
컨벤션으로 정하시는 것은 선택입니다!
결국 적절한 역할과 책임을 잘 나타내냐가 핵심일 것 같아요, 다만 익숙하지 않은 분들이 많거나, 통일성을 더 강조하고 싶다면 몇개의 네이밍 규칙을 정하는 것은 괜찮을 것 같습니다!
안녕하세요 제미니님
오랜만에 댓글 남겨봅니다.
제가 비전공자 출신이다보니 CS에 대해서 얄팍하게 알고 있습니다.
제미니님 경험에서 보았을때 CS의 학습 정도에 따라서
역량에도 반영이 되는 지 궁금합니다.
제미니님은 어떻게 CS를 학습하셨는지 궁금하고
비전공자가 그래도 CS를 공부했다는 걸 어떻게 어필하는 게 좋을지도 궁금합니다.
이력서에 쓰여질만큼의 업무가 있다면 문제가 없겠지만
그런 업무가 없을 수도 있을 거 같아서요!
오랜만에 댓글 주셨네요! 제가 관련해서 어떤 영상에선가 말했던 것 같은데 영상 제목을 못 찾겠네요 ㅠㅠ
뜨문뜨문 말했지만 한번 얘기해보면 좋은 주제인 것 같아서, 추후 영상으로 답변 드려보겠습니다!
-----
많이 고민 되실 수 있으니 간단하게만 적어보면,,
- CS 학습이 역량에 영향을 주지만 전부는 아니라고 봅니다. (특수 시스템이 아닌, 일반 서비스 개발 기준)
- 저 같은 경우는 업무를 하면서 학습한게 전부 같습니다 (첫 회사가 펌웨어 개발이라 더욱 접점이 컸음)
- CS 어필은 결국 기술적 사고력과 이어지지 않을까 싶습니다, 업무가 CS 밀접하지 않아도 대화를 하다보면 알 수 있는 것 같아요
@@geminikims 답변 감사합니다! 영상 기대하겠습니다 :)
파사드 패턴 형식으로 여러 레포지토리를 참조 하여 일을 하는 Service 레이어 라고 생각하면 될까요 ?!
위 글이 맞다면
서비스 코드가 많아지면, 분할을 어느정도까지 해야할지 기준이 혹시 있으신가요 ? (예) 하나의 서비스에 기능이 10개 이상이면 나누는것을 생각해봐야 한다 ?
제 경우 Service는 클래스의 postfix이고 레이어로 말하면 비즈니스 레이어라고 보셔야합니다
비즈니스 레이어는 repository들을 참조하기 보다는 구현체 클래스들을 참조하는게 조금 더 바람직 하다고 봅니다, 말씀하신 수치로 나누는것을 정하기는 약간 애매한 부분이 많습니다
고정적 숫자보다는 책임이 과하거나 역할이 꼬여있다는 것들이 기준이 되면 좋을 것 같습니다
@@geminikims 아하 클래스에 기능이 점점 많아지면 책임을 분리해야 할 수 있겠구나 하면서 점진적으로 개선을 하는거군요 ?!
네넵 항상 고정적인 것 보단 코드와 상태를 관망하면서 점진 개선이 좋은 것 같습니다
@@geminikims 항상 좋은 말씀 감사합니다 :) !!