질문
[개발 관련 질문]
- interface, type들을 어떤 기준으로 나눠서 관리하면 좋을까요?
- 저는 interface를 별도의 폴더를 만들어서 다 모아두고, styleComponents의 type만 해당 파일에서 직접 관리하고 있는데, 내부 파일이 많아지면 원하는 파일을 찾기가 조금 힘들었습니다 ㅠㅠ 동근 멘토님의 방식이 궁금합니다!
참고코드리뷰 시 질문하면 좋을 것 같다고 말씀해주신 부분입니다
동근 멘토님의 답변
꼭 interface, type 끼리 나눌 필요 없음
멘토님은 지역성을 고려한 폴더구조 사용
src/feature/form 이렇게 도메인 별로 묶여 있고, 내부에 api, interface 존재src/shared 에 공통으로 쓰이는 내용 존재웹에 들어가는 앱뷰 같은 경우 복잡도가 높지 않으므로 해당 방식을 사용한다.
이렇게 사용하다가 재사용성 ~ 가독성 문제가 생길 경우 위치를 옮기는 편
정답은 없다.
보통 파일 내부에
위쪽 interface
뭐가 들어갈 예정?중간 컴포넌트 배치
이런 순으로 배치해줘아래쪽 컴포넌트 세부
스타일은 이렇게~- 이해하기 좋은 변수명을 짓는 팁이 있을까요?
- 변수명을 지을 때 참고하시는 자료가 있나요?
- 다른 사람이 쓴 코드를 많이 보면서 익히는 방법이 가장 좋을까요..?
동근 멘토님의 답변
동료와 협의해서, 동료와 규칙을 정해서 팀 끼리 잘 읽을 수 있으면 된다.
서비스 중심으로 사고해서 변수명을 지으면 좋다.
[추천 책]
clean code 1장 - 의미 있는 이름
프로그래머의 뇌 - 명명을 잘하는 방법
- 현 회사에서는 어떤 식으로 디자인 시스템을 사용하는지 궁금합니다!
- 데브코스 중간 프로젝트였던 기동팀-CheQuiz 에서 디자인 시스템을 새로 구현하고 있는데, 팀원마다 emotion 컴포넌트를 각자 만들며 생겼던 중복들을 제거하고자 하는 목적입니다.
- 버튼, 박스, 텍스트, 색 등 아주 기본적인 컴포넌트만 구현했는데, 앞으로 어떤 방향으로 개선해야 할지 고민되어서 동근 멘토님 회사의 방식이 궁금했어요,,!
동근 멘토님의 답변
디자인 시스템을 왜 구현하고 싶은지 이유를 생각해보자.
- 이력서 용이라면, 밑바닥부터 구현보다, 이미 있는 디자인 시스템을 따라 만들어보는게 낫지 않을까?
- 특정 서비스의 개선을 위한 것이라면, 새로 구현하는 것이 나을 수 있다.
그래야 면접에서
왜 구현했어요? 에 대한 답변을 할 수 있다.- 바운더리를 안 깔아놓으면 문제가 생길 수 있다.
- 바운더리를 깔면 ⇒ A~~ B~~ 이런 문제가 있다는 것은 이미 알고 있다. 하지만 이번에 얻고 싶은 경험은 ~~여서 디자인 시스템 개선을 선정하게 되었다.
- 이렇게 말하면 더이상 까지 못한다.
당근마켓에서는…
- 단순히 token 만 만들었다. typography, color, padding 등..
- 개발자의 자율성을 존중해주는 편이다.
뱅크샐러드에서는…
- 아토믹 하지 않고, 컴포넌트 단위로 전체 스타일을 구현했었다.
- 새로운 화면 나올 때마다 건들여야 한다는 단점이 있따.
[취업 관련 질문]
- 포트폴리오/프로젝트를 평가 하실 때, 어떤 면을 특히 주의깊게 보시나요? 이런 특징 / 기능 등이 있다면 특히 좋게 본다 하는 것이 있을까요?
- 이전에, 코딩테스트를 안 보는 회사에 지원하는 방식이 있다고 알려주셨었는데, 이 경우는 과제 테스트가 있거나, 이미 만든 포트폴리오 등을 보는 비중이 높을 것 같다고 생각했습니다.
- 최종 프로젝트에 불참한 지금, 틈틈히 혼자 프로젝트를 진행하려고 해요!
동근 멘토님의 답변
프로젝트 팀을 채용하는 기준은..
- 서비스 지향적인 사람을 추구한다.
- 개발을 잘하는 것은 default!
- 개발을 할 때에도, 왜 이렇게 구현했는지 목적과 고민한 흔적이 명확한 것을 좋아한다.
- 제품 중심으로 생각하는 사람을 좋아한다.
- 왜 이렇게 했어? 가 포인트!
- 특히 사용자 경험 관련 개선 좋아한다.
- 사용자 이탈율이 줄어들었다 ⇒ 이런 거 제일 좋아한다.
- 기술적인 개선도 괜찮다.
- 성능 개선을 해서 bundle 사이즈가 ~~에서 ~~로 줄어들었다. 등
- 자기소개서부터 성향이 보인다.
- 너무 애매한 말을 쓰지 말자. 쓴다면 내 안에서 정의를 내리고 쓰자.
- Restful한 확장성 있는 설계를 했다.
- 어떤 것이 확장성이죠?
- React로 선언형 프로그래밍을 했다,
- 어떤 것이 선언형 이라고 생각하시죠?
- React로 상태 분리했다고 무조건 선언형 아님
- github 코드를 열어보는 편이다.
- 코드에 고민이 들어있고, 가독성이 좋아서 context 몰라도 읽히면 좋다.
- 추출과 추상화는 다르다.
- 내용을 뽑아낼 때, 사용자를 고려해야 한다.
- 비슷한 것 같은데? 하고 뽑아내면 안된다.
- 당근마켓은 채용이 엄격하다.
- 한명만 No 해도 채용하지 않고 있다.
- 코딩테스트는, 경력직이 되면 중요하지 않다.
- 이직하면서, 새 회사에 동료들을 추천해주기도 한다.
- 이 경우 기술면접 부터 봐요~~ 이런 식으로 하기도 한다고.
- 주도적으로 한 사람과, 그냥 한 사람은 다르다.
- 성장 가능성을 블로그로 어필하자.
블로그의 방향?
- 공부했던 것을 나열하는 방향과
- 내 경험과 생각을 쓰는 방향이 있다.
내 경험과 생각을 쓰는 사람을 보면
- 사고를 하고 있으니까, 좋았다 나빴다를 자체적으로 판단한고 있는 지원자니까
- 성장을 할 것이다 라고 판단해서 가점이 있다.
어떻게 하는 것을 추천?
- 둘다 쓰자.
- 평소에는 공부했던 것을 나열하고
- 생가을 쓰고 싶은 토픽이 생기면, 주말에 제대로 쓰자.
TIL에 대해서
맥락이 필요하다.
- 매일 성장하는 개발자라고 하면서 ⇒ 3달 전이 마지막이거나
- 프론트엔드 개발자라고 하면서 → unity, C# 글이 마지막이거나
뭐가 필요한지 모르고 하면 빠르게 성장하기 어렵다.
목표를 정하고 달리자.
[개인적인 질문]
- 직장인이 되고 집에 오니까 너무 힘들어서 공부할 체력이 전혀 없는데, 개발자가 되기 위해서 & 되고 난 후에도 계속 퇴근 후 공부를 해야 한다고 생각합니다! 퇴근 후 공부에 대한 팁이 있으신지 궁금합니다..!
동근 멘토님의 답변
나에게 추천하는 공부 방법
취업이 엄청 급하지 않고, 시간이 별로 없는 직장인 ver.
- 매일 조금씩 TIL을 쓰자.
- 공부한 것도 좋고,
- 개발 관련 글을 읽고 느낀 점도 좋다.
- 직장에서 도움이 되도록 해보자.
- 동근 멘토님 같은 경우, 직장에서 개발할 때 조금씩 챌린지를 했다.
- 마케팅 페이지 만들기
- 그냥 만들기 → 재사용 가능한 컴포넌트 만들어두기 → 마케터가 직접 만들 수 있게 하기
- 나 같은 경우..
- 공익 사람이 엑셀 파일을 파이썬으로 자동화시켜서 30분동안 할 것을 5분 컷 했다고 한다.
- 나도 장학금 파일 관련 자동화? 시각화? 시키면 좋을듯!!
내가 개발자를 해도 될까?
질문 잘 못하는데..
- 자기 객관화가 필요하다.
- 질문 하는 것 자체는 중요하다.
- 하지만 순발력 있게 바로 질문하지 않아도 된다.
- 공유 잘하면 된다 ( 내 상황 공유)
- 아마 일 잘 안될때 끙끙대면서 혼자 붙들지 말라는 거일듯
- 토스 같은 경우 ( 동료개발자)
- 개발 잘해? 아님 공유 잘해? 라고 물어본다고.